Every Software Builder must Learn the New Language of Secure Development to avoid failure.

At the Cyber Security Coalition’s Application Security Experience Sharing Day in Louvain, OWASP ASVS ambassador and contributor Eden Sofia Yardeni introduced the new OWASP Application Security Verification Standard 5.0 to an audience of developers, architects, security professionals and technical managers.

Eden’s message was practical and urgent. Application security is no longer a specialist afterthought. It is becoming a core engineering discipline. As a former full-stack developer who now focuses on making application security standards operational across engineering teams, she speaks the language of both builders and defenders. Her passion lies in turning security from abstract theory into something teams can use in real design decisions, code reviews, CI/CD pipelines, architecture reviews and verification activities.

That is exactly where ASVS 5.0 becomes important.

From Security Checklist to Engineering Language

The OWASP Application Security Verification Standard has always been more than a checklist. It defines what secure applications should achieve. But version 5.0 makes that message easier to adopt, easier to tailor and easier to integrate into the software development lifecycle.

Every software builder should be familiar with ASVS because it gives teams a shared vocabulary. Developers, architects, testers, product owners, security officers and auditors can stop debating vague terms such as “secure enough” and start discussing concrete requirements: authentication, session management, browser security, access control, input validation, API protection, cryptography, logging, configuration and secure deployment.

Better still, every software builder should be trained in this approach. Training changes ASVS from a compliance document into a way of thinking. It helps teams recognise design weaknesses before they become incidents. It gives junior developers a structured entry point into secure coding. It gives architects a reference model for risk-based design. It gives product teams a way to define “done” that includes security, not just functionality.

In many projects, not every ASVS requirement will apply. A machine-to-machine API may not need all browser frontend requirements. An application that does not use GraphQL, WebSockets or SOAP can leave those sections aside. But this flexibility is not a weakness. It is one of the strengths of ASVS 5.0. The secure code checklist becomes a starting point for the SDLC, while the full standard remains available as the organisation matures.

Refactor 1: A Simpler Level Structure

One of the most important improvements in ASVS 5.0 is the clearer level structure: Level 1, Level 2 and Level 3.

Level 1 is the practical starting point. It focuses on the most essential application security requirements and lowers the barrier to adoption. This is important because many organisations fail at application security not because they do not care, but because the first step feels too large. A smaller, more focused Level 1 allows teams to begin.

Level 2 raises the bar for applications with more sensitive data, more complex business logic or higher assurance needs. Level 3 is the target for applications where compromise could have major business, societal, financial or regulatory impact.

The advantage is that ASVS 5.0 supports progressive improvement. Teams do not need to pretend they can reach the highest maturity level on day one. They can start at Level 1, build habits, automate checks, document decisions and then move upwards. This makes ASVS a transformation path rather than a one-time audit exercise.

For software companies, this is powerful. It allows product teams to show customers and regulators that they are not merely reacting to vulnerabilities, but systematically improving their secure development maturity.

Refactor 2: Properties Before Process

Another major shift in ASVS 5.0 is the stronger focus on the security properties of the application.

This matters. Processes are important, but a process does not secure an application by itself. A ticket in Jira, a policy in SharePoint or a signed-off procedure does not stop an attacker. What matters is whether the application actually has the right security properties: whether sessions expire correctly, whether authorisation is enforced at the right layer, whether tokens are validated by trusted backend services, whether sensitive functions are protected from cross-origin abuse, whether cryptographic choices are modern and defensible.

ASVS 5.0 therefore pushes teams to ask better architectural questions. What must this application guarantee? Which trust boundaries exist? Which actions are sensitive? Which tokens can grant access? Which components can influence authorisation? Which browser mechanisms protect the user? Which cryptographic algorithms are still acceptable? Which decisions must be documented because the design depends on them?

This is especially useful in architecture. Instead of starting with a process checklist, teams can start with application properties. The result is more meaningful design verification. Architects and developers can reason about the system itself, not only about whether a process was followed.

Refactor 3: Better Mapping to NIST, CWE and OpenCRE

ASVS 5.0 is also more useful because it fits better into the broader security ecosystem.

Clean mapping to frameworks such as NIST and CWE helps organisations connect engineering-level security requirements with enterprise risk management, vulnerability classification and governance reporting. A developer may work with an ASVS requirement. A security tester may report a CWE weakness. A CISO may report progress against NIST CSF or internal control domains. OpenCRE adds value by linking requirements across standards and guidelines into a common requirements graph.

This matters because modern cybersecurity is not one framework. It is an operating model. Organisations must connect secure coding, vulnerability management, risk management, compliance, supplier assurance, customer trust and regulatory reporting. ASVS 5.0 helps bridge that gap. It gives engineering teams practical requirements while still enabling traceability to governance and assurance.

For NIS2, DORA, CRA and ISO-driven organisations, this traceability is essential. Regulators and customers increasingly expect evidence that security is built into the lifecycle. ASVS gives teams a credible, open and actionable foundation for that evidence.

Actionable, Forkable and Flexible

A strong advantage of ASVS 5.0 is that it is actionable. Requirements are written so they can be discussed, implemented, tested and reviewed. They can feed secure coding standards, architecture patterns, pull request templates, threat modelling workshops, automated unit tests, integration tests, penetration testing scopes and supplier questionnaires.

It is also forkable. Organisations are encouraged to create a tailored version that fits their domain, risk profile and technology stack, while preserving traceability to the original ASVS requirements. This is important because a SaaS provider, a bank, a health platform, a public sector portal and an internal workflow tool do not all need the same control depth.

It is flexible. Teams can omit irrelevant technology sections, add organisation-specific guidance, define approved libraries and map ASVS requirements to internal secure-by-design patterns. This flexibility makes ASVS useful in real companies rather than only in theoretical security programmes.

The uplift for software builders is clear. By embedding ASVS into the SDLC, companies can reduce avoidable vulnerabilities, improve consistency across teams and provide stronger assurance to the organisations relying on their software.

Browser Origin Separation: A Small Detail with Large Impact

ASVS 5.0 gives important attention to browser origin separation. This is the security logic that prevents one website, script or origin from freely interacting with another. It includes concepts such as Same Origin Policy, SameSite cookies, CORS preflight behaviour, origin validation, anti-forgery controls and the safe use of browser headers.

The added value is simple: many modern attacks do not begin with breaking encryption or exploiting exotic memory corruption. They begin by abusing how browsers send requests, share cookies, load resources or process cross-origin interactions.

A weak CORS configuration, missing CSRF protection, unsafe use of GET requests for sensitive actions, poor postMessage validation or incorrect origin separation can allow attackers to make a victim’s browser perform actions the user never intended.

For modern applications, especially SaaS and identity-heavy platforms, browser origin separation is not optional. It is part of the trust boundary.

SSO and the Signature Verification Problem

Single Sign-On has become a critical part of modern software. But SSO also concentrates risk. If an application accepts a signed assertion, token or identity claim without properly verifying its presence, integrity, issuer, audience, expiry and context, the login boundary becomes fragile.

ASVS 5.0 rightly emphasises that digital signatures on authentication assertions, such as JWTs or SAML assertions, must be validated and unsigned or invalid assertions must be rejected.

This is not a theoretical issue. In token-based architectures, the token often becomes the key. If the token is stolen, forged, replayed or accepted in the wrong context, the attacker may bypass passwords and MFA entirely.

A Short Story: The Grey Zone in Login and User Management

Imagine a pre-ASVS 5.0 application with a simple registration flow.

A new user creates an account. During registration, the frontend sends several user properties to the backend: name, email, company, department and preferred role. The developer assumes the frontend will only allow normal users to register. The backend stores the submitted object without strict field-level validation. The user management screen later reads the same object and uses the role field to determine access.

A malicious user notices that the registration API accepts more fields than the interface displays. They register with an extra parameter: role=admin.

The system does not immediately show admin rights, because another process must first mark the account as verified. But after email verification, a background job synchronises user properties. It trusts the stored role field and activates admin capabilities.

Nobody “hacked” the password. Nobody broke encryption. Nobody exploited a server zero-day. The attacker simply registered on the site and used a grey zone between registration, verification, synchronisation and authorisation.

This is exactly the kind of weakness ASVS helps expose. It pushes teams to ask whether mass assignment is prevented, whether authorisation depends on trusted server-side decisions, whether user-controllable fields are separated from privileged attributes, whether workflow state changes are atomic and whether identity data from registration is treated as untrusted until validated.

OAuth, Tokens and the Real-World Warning

Eden’s warning about token-based sessions in OAuth is well placed.

OAuth and OpenID Connect are powerful, but they are often misunderstood. Access tokens, refresh tokens, ID tokens, session cookies, device codes and federated assertions each have different meanings. When teams blur these concepts, danger follows.

Published incidents have shown what can happen when tokens become skeleton keys. Stolen OAuth tokens have been used to access private repositories. Forged authentication tokens have been used to access email accounts across organisations. Session tokens stolen from support artefacts or browser traces can bypass MFA because they represent an already authenticated session.

The lesson is not “do not use OAuth.” The lesson is: use OAuth properly.

Teams should align with current OAuth security best practices, move towards OAuth 2.1 principles where applicable, avoid deprecated flows, use PKCE, validate redirect URIs strictly, verify issuers and audiences, avoid accepting unsigned tokens, rotate and revoke tokens, protect refresh tokens, and ensure token validation happens in trusted backend services.

A token is not just a string. It is a delegated trust object. Treat it accordingly.

TOCTOU: The Time-of-Check to Time-of-Use Trap

ASVS 5.0 also gives attention to safe concurrency and TOCTOU vulnerabilities: time-of-check to time-of-use.

This occurs when an application checks a condition and later acts on that condition, but the state changes in between. For example, the application checks whether a user has permission to access a file, but before the file is opened, the target changes. Or the system checks whether a discount code is valid, but multiple parallel requests use it before the state is updated. Or the application checks whether a user is still a normal user, but a privilege change, session update or workflow race condition creates a gap before enforcement.

TOCTOU is especially relevant in cloud-native, distributed and API-driven systems. Microservices, queues, caches, asynchronous jobs and concurrent requests can all widen the gap between decision and action.

The ASVS message is clear: security-sensitive checks and the actions that depend on them should be atomic where possible. Authorisation decisions must be enforced at the point of use, not only at the point of entry.

ASVS for AI Agents

A new and inspiring use case is the integration of ASVS into dedicated AI agents that safeguard software delivery.

Imagine an internal secure development agent trained to support developers during design and coding. It can read a pull request and map changed functionality to relevant ASVS requirements. It can warn when a new endpoint performs a state-changing action using an unsafe method. It can detect when authentication logic lacks backend token validation. It can remind developers to document session lifetime decisions. It can help generate unit tests for abuse cases. It can suggest approved cryptographic patterns instead of allowing ad hoc decisions.

This does not replace human security expertise. It scales it.

ASVS provides the structured requirements language. AI agents can help apply that language continuously across code, architecture, documentation and testing. This is a natural next step: secure-by-design assisted by intelligent, requirement-aware tooling.

For organisations moving toward Zero Trust, this is essential. Trust must be continuously verified, not assumed at release time.

Appendix C: Cryptography Becomes More Concrete

Appendix C of ASVS 5.0 is particularly useful because cryptography is one of the areas where developers are often told what not to do, but not always given enough practical direction.

The appendix distinguishes approved, legacy and deprecated mechanisms. It gives teams a clearer basis for decisions around algorithms, key sizes, random values, cipher modes, message authentication codes, digital signatures and post-quantum considerations.

This is important because cryptographic debt is silent. Weak algorithms, outdated signing schemes, poor random generation or long-lived secrets may not break today, but they create future exposure. Appendix C helps teams make cryptography visible, reviewable and upgradeable.

Appendix D: Recommendations as a Roadmap

Appendix D is also valuable because not everything useful can be mandatory. Some practices are highly recommended but may not fit every application as strict requirements.

This is where ASVS 5.0 becomes pragmatic. It preserves good ideas without overloading the core requirement set. For teams, Appendix D can be used as a backlog of maturity improvements. It can inspire security champions, architecture boards and product teams to go beyond the minimum.

The best organisations will not ask, “What is the least we must do?” They will ask, “Which recommended practices reduce our real risk and strengthen customer trust?”

The HarmonyQ Way: From Best Practice to Continuous Transformation

The danger of not following best practices is not abstract. It is the grey zone in login logic that gives a normal user admin rights. It is the forgotten token that opens private source code. It is the unsigned assertion that becomes a false identity. It is the race condition that turns a correct check into an invalid action. It is the outdated cryptographic choice that becomes tomorrow’s breach.

ASVS 5.0 offers a better path.

It gives builders a structured, open and actionable way to secure applications. It allows organisations to start small, tailor intelligently and mature continuously. It connects secure coding with architecture, testing, governance and assurance. It helps transform application security from a late-stage control into an engineering habit.

That is also the HarmonyQ way: continuously transform, continuously verify and continuously level up towards ZT9.

Zero Trust is not achieved by declaring trust impossible. It is achieved by designing systems where trust is explicit, tested, limited, monitored and improved. ASVS 5.0 gives software teams one of the clearest practical routes to do exactly that.

For every software builder, the message is simple: learn ASVS, train your teams in it, fork it to your reality, and use it as a living checklist for secure software. The organisations using your software are depending on it.