OWASP
The Top 10 is the way in, and the ASVS, the application security verification standard, is what turns a generic request for a security test into a verifiable requirement with a verdict per item. Buy testing without naming that yardstick in the contract and you get reports that do not compare across suppliers, with no way of telling which one tested more.
OWASP, the Open Worldwide Application Security Project, is a non-profit foundation, and all of its material is open and free. DM11 uses that material as the methodological base for application testing, writes the security requirement that goes into your contract with the software supplier, and measures the development process against SAMM. Where a certification is the destination, the evidence produced here carries into that project intact, and the page for the standard you choose explains the rest of the route.
Who runs the testing
CEH, Certified Ethical Hacker from EC-Council
CPTE, Certified Penetration Testing Expert from AcadiTI
SYCP and SYES, pentesting and evasion from Solyd
17 years of governance, risk and compliance
WHAT IT IS
OWASP publishes the most widely used application security references in the world, all of them free. The best known is the web application Top 10, currently in its 2025 edition, the first revision since 2021. Alongside it sit the ASVS, which is the list of verifiable requirements, the API Security Top 10, covering the interfaces your systems talk to each other through, MAS for mobile application security, the Top 10 for applications built on language models, and SAMM, which measures the maturity of the development process. The Top 10 is where nearly everyone comes in, and on its own it does not answer whether an application passed.
Broken access control stays in first place, as it was in 2021. Security misconfiguration climbed from fifth to second. Two categories are new: software supply chain failures, which widens what in 2021 covered only vulnerable and outdated components, and mishandling of exceptional conditions, which covers poor error handling and controls that fail open rather than closed. The edition analysed 589 CWEs, the public catalogue of software weakness categories, over data from more than 2.8 million applications and with thirteen contributing organisations: eight categories came from the data and two from the community survey.
The Application Security Verification Standard reached version 5.0 in May 2025, with around 350 requirements across 17 chapters and three verification levels, L1 to L3. The practical difference is the form: every requirement has to end in pass or fail, which is why it fits inside a contract, an acceptance criterion and a test report. It answers the question the Top 10 leaves open, which is what exactly your application must meet before anyone can say it has been verified.
Worth settling the expectation early, because it shapes the plan. What the work produces is a verification report with a declared scope, the intended ASVS level, a verdict per requirement and the evidence attached, including the requirements that do not apply to your case and why. The foundation itself is explicit about this in the ASVS text: it does not certify suppliers, verifiers or software, and it advises caution with third-party marks presented as official OWASP certification. Where your customer needs a document issued by an accredited body, ISO 27001 or SOC 2 is what answers that, and the testing done here goes into that project as technical evidence.
The API Top 10, in its 2023 edition, deals with what the web list does not reach, such as object and property level authorisation, unrestricted resource consumption and endpoint inventory. MAS, Mobile Application Security, covers mobile with two documents that work together: MASVS at version 2.1.0, with eight domains running from storage and cryptography through to privacy and resilience against reverse engineering, and MASTG at version 2.0.0, with the tests matching each domain. The Top 10 for applications built on language models, 2025 edition, is today's reference for generative AI security, with prompt injection in first place. And SAMM, the Software Assurance Maturity Model, at version 2, measures the process across five business functions and fifteen practices, with three maturity levels in each.
WHO USUALLY NEEDS IT
In none of them is anyone demanding a certificate. What is at stake is being able to compare suppliers, answer a customer with method, or test a surface that conventional testing does not reach.
Development is outsourced, the contract covers deadlines, functional scope and warranty, and the word security appears once, in a generic paragraph. With no requirement written down, chasing a fix afterwards becomes a commercial negotiation rather than the enforcement of a contract. The ASVS solves that because every requirement carries a verdict, and an annex with a declared level is enforceable.
Anyone selling software receives due diligence with direct questions about the Top 10, about application testing and about how findings get fixed. Answering from memory costs credibility the moment evidence is requested. A verification report with a declared scope and level answers most of the questionnaire, and answers it the same way for the next customer who asks.
The company put an assistant built on a language model in front of customers or on top of an internal knowledge base, and conventional testing still looks only at the application around it. Prompt injection, system prompt leakage and excessive tool agency fall outside that scope, and they are exactly the items the Top 10 for applications built on language models organises.
STORIES
We change our clients' names with the same confidentiality that will protect your company later. The names change; the pattern of the problems repeats. Where a client agrees, we give named references in a conversation.
Software as a service
There was an annual web application test, with a clean report, and the team trusted it. The mobile app talked to an API that had never appeared in any scope, because the historical request said only test the website. The product had grown through mobile, and most of the traffic already went that way.
We rebuilt the scope from the application inventory, setting aside the wording of the old request, and brought in the API and the app. We tested the API against the API Top 10 and verified the ASVS authorisation requirements using credentials from two separate customers, which is what exposes object level authorisation problems.
Changing the identifier of a resource returned another customer's data, with no ownership check at all. The fix was cheap because the authorisation already existed in the web layer and was missing in the API. The lasting change was procedural: scope now comes from the application inventory, reviewed every quarter.
Retail and e-commerce
Development was entirely outsourced and the contract carried no security requirement. Every test finding opened a discussion about who paid for the fix, and the internal team spent more time negotiating than remediating. No delivery had an acceptance criterion tied to security.
We set ASVS level 2 as the target, selected the requirements applicable to that type of application and wrote them into a contract annex, including the demand for evidence per requirement. We agreed with legal what happens when a requirement fails, and with the technical team what goes into a retest.
The argument about who pays ended, because the requirement became part of what had been bought. The side effect was larger than expected: the supplier started delivering already fixed ahead of acceptance, once failing began to cost them rework.
Insurance
An assistant built on a language model served policyholders and had access to an internal document base, plus permission to query systems through tools. The previous security assessment had looked at the server and at authentication, and not at the behaviour of the model.
We tested against the Top 10 for applications built on language models, starting with direct prompt injection and with indirect injection, which arrives hidden inside a document the system itself reads. We reviewed the permissions of the tools available to the assistant and how output was handled before it reached the policyholder.
A document uploaded into the base could change the assistant's behaviour for later conversations, and one of the tools held write permission it did not need. We cut the permission to the minimum, separated content from instruction and started validating output, which closed both routes.
HOW WE RUN IT
The yardstick is chosen before the testing, and in writing. With no declared ASVS level and no closed scope, the report becomes a list of loose findings that presents well and never supports a statement about whether the application meets the bar.
We map what exists in terms of applications, APIs, mobile apps and generative AI components, with a defined owner for each item. From there we choose the lists that apply to each asset and the target ASVS level, together with whoever answers for the product.
An inventory of applications, APIs and apps, with an owner per item
The applicable reference set per asset, from the web Top 10 to the language model one
The target ASVS level agreed with the product team
Rules of engagement, environment and testing window in writing
Delivery milestoneScope and ASVS level approved before any testing begins.
The two activities sit side by side and play different parts. The Top 10 guides the hunt for what tends to break first, and the ASVS delivers the verdict requirement by requirement. We work with access to documentation and source wherever possible, because that is the approach the standard itself recommends and the only one that reaches authorisation and business logic.
A verdict per requirement, with evidence attached
Findings prioritised by real risk, with the exploitation path described
Non-applicable requirements identified, each with its rationale
An executive report kept separate from the technical one
Delivery milestoneReport delivered with scope, level and every requirement verified declared.
We sit with the developers to turn findings into tasks with an owner and a date. Where development is outsourced, the same content becomes contract wording, with the ASVS level declared and the evidence demanded per item, so the next delivery is born inside the yardstick.
A remediation plan with an owner and a date per finding
Security requirement wording for the contract with the supplier
Acceptance criteria tied to verifiable requirements
A retest of the closed items, with before and after evidence
Delivery milestoneThe highest-risk findings fixed and confirmed in a retest.
Testing measures the product at a moment in time, and SAMM measures the process that produces it. We assess the fifteen practices across the five business functions, set the target level for each with technology leadership, and agree the verification cadence that keeps the result standing over time.
A SAMM score per practice, with the current and the target level
A process improvement plan, prioritised by what slows delivery most
Verification built into the pipeline, wherever automation fits
A retest and scope review routine defined, with who does it and when
Delivery milestoneCurrent and target level set per practice, with the plan approved by technology leadership.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline turns into a promise. What moves the clock here is almost always the real scope, which tends to be larger than the initial request describes. These are the three factors that weigh most, and the first conversation already shows which one your company is in.
A web application with an API and a mobile app adds up to three separate testing surfaces. Third-party integrations, an authenticated area with different profiles and a generative AI component all add paths that have to be walked with separate credentials before an authorisation problem shows itself.
Level 1 is the first step and closes the most basic layer of defence. Level 2 is what most business applications should be aiming at, and level 3 is for what carries high risk. The higher the level, the more the work depends on access to source, to documentation and to the people who built the thing.
With an internal team, remediation and retesting move at the pace of their calendar. With a software house, the fix depends on the contract, and sometimes changing the contract is the slowest step in the whole project. That conversation starts early, alongside setting the target level.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
The question comes up often and the answer saves money. The foundation certifies no vendor, no verifier and no software, and says so in the text of the ASVS, its application security verification standard. It goes further and advises caution over third-party seals presenting themselves as official OWASP certification, because those exist in the market and carry no backing. What the OWASP material gives you serves your case better than a seal: a public yardstick your customer and your penetration tester both recognise, with a verdict per requirement. And where the requirement really is a document issued by an accredited body, ISO 27001 or SOC 2 is what answers it.
With scope and ASVS level declared, the report starts telling you whether the application meets the bar, and quotes from different suppliers become comparable. It serves the company that has to answer a customer as much as the one about to put the requirement into the next delivery contract.
Comparisons on this subject
See all 13 comparisons