The Foundation’s new strategic plan is not a community update. It commits OWASP to setting the technical floor for AI security, secure-development competence, and EU compliance. Three things on it should already be on your roadmap.
Disclosure: The author is a lifetime member of the OWASP Foundation. This article reflects an independent reading of the public strategic plan and does not represent the views of the Foundation.
The OWASP Foundation has spent twenty-five years as the de facto open-source authority on application security (OWASP Foundation, n.d.a). Most CISOs treat the Top 10 as a baseline assumption, the way they treat TLS or DNS. ASVS sits inside more procurement contracts than anyone has counted. SAMM quietly underwrites a generation of secure-development programmes.
So when the Foundation publishes a strategic plan that opens by admitting it has been “merely present” rather than “transformative” (OWASP Foundation, 2025), that is worth reading carefully.
The plan sets a deliberately absolutist vision: a world with no more insecure software. Five pillars carry the weight: sustainable funding, global community, education, policy and regulation, and continuous open-source innovation (OWASP Foundation, 2025). The detail is more interesting than the slogans.
We have read the plan. We have mapped it against the regulatory wave already cresting in the EU and the United States. Three shifts inside the document will change how secure software is built, hired for, and bought, inside the next twenty-four months. If you run a security programme, those three are where to look.
Shift one: AISVS is becoming the technical floor for AI security
OWASP is building out the Artificial Intelligence Security Verification Standard (AISVS) alongside its established ASVS programme. AISVS is currently an Incubator project at Version 0.1, structured as fourteen control categories with three verification levels modelled directly on ASVS (OWASP Foundation, n.d.b). Critically for anyone running agentic systems, those categories include Autonomous Orchestration and Agentic Action Security, MCP Security, and Memory, Embeddings and Vector Database Security (OWASP Foundation, n.d.b). The Foundation now intends to offer professional assessments against AISVS through a new wholly-owned commercial entity (OWASP Foundation, 2025).
The regulatory market currently has no agreed technical baseline for “secure AI.” The EU AI Act sets risk tiers and obligations (European Parliament and Council, 2024a). The US National Institute of Standards and Technology publishes a Generative AI Profile of its AI Risk Management Framework (NIST, 2024). Neither tells you what good looks like at the verification layer. AISVS is a serious attempt to close that gap.
The reality on the ground: most enterprise AI deployments today rely on bolted-on guardrails, vendor reassurance, and the hope that prompt injection turns out to be manageable. That is not an architecture. That is a posture. A real verification standard, applied consistently, is what moves AI security from posture to engineering.
The honest caveat: AISVS is still in Phase 2 of a five-phase roadmap, with beta release and pilot testing ahead of a 1.0 publication (OWASP Foundation, n.d.b). That is a feature, not a bug. The teams who engage with the requirements now, while they are still being refined with community input, will be the ones who shape the procurement clauses everyone else inherits.
Speed is the only perimeter. The teams who internalise AISVS as a verification target now, before procurement and audit start asking for it, will not be the ones scrambling in 2027.
What to do about it: AISVS is the most operationally important thing in the OWASP plan. Treat it as the verification standard for agentic systems, MCP integrations, and vector-database workloads, the same way you treat ASVS for traditional applications. Build it into delivery pipelines as enforced controls, and into procurement clauses as a verifiable supplier requirement, not as an audit artefact retrofitted at the end.
Shift two: certification is about to redefine the floor of hireable competence
OWASP is launching two flagship credentials: Certified Secure Software Developer and Certified Secure Software Architect (OWASP Foundation, 2025). Both are explicitly designed to validate practical application of OWASP frameworks rather than memorised theory.
The Foundation is vendor-neutral. (ISC)² has CSSLP. SANS has GIAC. Both serve their constituencies, but neither has the open-source legitimacy that OWASP carries with developers. A developer-led, vendor-neutral credential anchored in ASVS, AISVS, threat modelling, and SAMM is a different animal.
That difference matters operationally. Existing security credentials are largely built and graded by security professionals for security professionals. The OWASP credentials are being built by the same community that writes the projects engineering teams already use every day. A developer who studies for the Certified Secure Software Developer is studying the same cheat sheets, ASVS controls, and threat modelling guidance their team is already pulling from at code-review time. That alignment is what makes the credential more likely to be respected by the engineering teams who actually have to do the wiring, rather than tolerated as another HR checkbox.
The Architect credential is the one that matters most. It targets the gap most organisations are silently failing on. Most security failures are not coding bugs. They are architectural decisions made years earlier by people who did not know they were making security decisions. Validating that senior engineers can lead threat modelling, evaluate trade-offs, and apply SAMM to organisational context closes a credentialing gap that has been open for a decade.
Within eighteen to twenty-four months, expect to see these certifications in CV filters, on RFP requirements, and inside enterprise hiring matrices. Programmes that ignore them will end up paying a premium for the same talent later.
The operator’s read: Track the certification syllabus as it emerges. The Architect credential in particular is going to define what “competent” means for senior secure-development hires in the second half of this decade. Build internal training pathways now, before the cost of catching up is set by the market.
Shift three: OWASP is entering the regulatory arena, on purpose
The Foundation’s policy strategy names the EU Cyber Resilience Act, the EU AI Act, and the NIST Secure Software Development Framework as priority engagement areas, alongside standards bodies including ECMA International, ISO/IEC, and CEN-CENELEC (OWASP Foundation, 2025).
This is new. Historically OWASP has been content to publish frameworks and let regulators reference them. The new posture is active: vendor-neutral technical input, sustained relationships with policymakers, and engagement designed to prevent what the plan bluntly calls “compliance theatre”.
The Cyber Resilience Act applies to products with digital elements placed on the EU market and brings reporting obligations from 11 September 2026, with full requirements from 11 December 2027 (European Parliament and Council, 2024b). It will reshape how software is built, supported, and disclosed for any organisation shipping into Europe. The AI Act phases in obligations through 2026 and 2027, with high-risk system requirements landing hardest on enterprise deployers (European Parliament and Council, 2024a).
Policymakers writing implementation guidance under both regimes are short on technical depth. OWASP entering that space as a credible vendor-neutral voice will shape what “state of the art” actually means inside the implementing acts and harmonised standards. The firms that read OWASP’s policy submissions early will see the operational requirements before they harden into audit checklists.
Where this points: Watch OWASP’s policy output the way you would watch ENISA guidance or NIST drafts. It is becoming a leading indicator for what regulators in two of the most important jurisdictions on earth are about to require.
What this plan does not change
Three things, briefly, because operational realism matters:
- The OWASP top ten is still a top ten. It is a useful awareness tool, not a security programme. ASVS, SAMM, and now AISVS are where the engineering work actually lives.
- Open-source frameworks do not secure software. Architecture does. The verification standards are excellent maps. They are not the territory. Adoption inside delivery pipelines as enforced controls is what matters, and that is integration work, not procurement work.
- Vendor-neutral does not mean unbiased. The Foundation has a clear point of view about what good looks like. Read the plan as a serious institutional position, not a settled industry consensus.
The Sakura position
The OWASP plan is the most consequential strategic document the application-security community has published in a decade. Not because it announces a new tool, but because it commits the Foundation to operating across funding, certification, regulation, and assessment at industrial scale.
Three things to put on the roadmap before they put themselves there:
- Treat AISVS as the verification target for AI systems, not the LLM-vendor’s marketing page.
- Track the OWASP Certified Secure Software Architect syllabus as it emerges and build internal pathways toward it before the talent market does.
- Read OWASP’s submissions to the Cyber Resilience Act and AI Act implementing acts as leading indicators of where European regulation actually lands.
The teams who do this work in 2026 will not be the ones explaining themselves to auditors in 2027. Frameworks make excellent diagrams, but they do not run at 3 a.m. - the work is in the wiring.
If you want a structured read on how AISVS, the CRA, and the AI Act intersect with your current architecture, that is the kind of conversation we have most weeks. If you want to see how we have already mapped these primitives into a working operating model, download our Trustworthy Agentic AI Blueprint. Either way, get in touch.
References
European Parliament and Council, 2024a. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence and amending Regulations (EC) No 300/2008, (EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU) 2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU, (EU) 2016/797 and (EU) 2020/1828 (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689, 12 July. Available at: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [Accessed 7 May 2026].
European Parliament and Council, 2024b. Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act). Official Journal of the European Union, L 2024/2847, 20 November. Available at: https://eur-lex.europa.eu/eli/reg/2024/2847/oj [Accessed 7 May 2026].
National Institute of Standards and Technology (NIST), 2024. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Gaithersburg, MD: U.S. Department of Commerce. Available at: https://doi.org/10.6028/NIST.AI.600-1 [Accessed 7 May 2026].
OWASP Foundation, n.d.a. About the OWASP Foundation. Available at: https://owasp.org/about/ [Accessed 7 May 2026].
OWASP Foundation, n.d.b. OWASP Artificial Intelligence Security Verification Standard (AISVS), Version 0.1 (Incubator). Available at: https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/ [Accessed 7 May 2026]. Source repository available at: https://github.com/OWASP/AISVS [Accessed 7 May 2026].
OWASP Foundation, 2025. OWASP Foundation’s Strategic Plan. Wakefield, MA: OWASP Foundation. Available at: https://owasp.org/ [Accessed 7 May 2026].
