The previous lesson ended with an uncomfortable question: the Top Ten raises awareness of which risks exist, but it doesn't help prove that an application is secure. When Lucía has to answer a corporate client who demands "security guarantees" in BazarNube's contract, or when she wants to give a pentester a clear list of what to check, the Top Ten falls short. She needs something different: not a list of dangers, but a list of verifiable requirements. That is the second tool in our box: OWASP ASVS, the Application Security Verification Standard. In this lesson we present it at a high level; the detail — levels, concrete requirements, how to implement it — is the content of module 4.

1. What ASVS is
2. ASVS versus the Top Ten: requirements vs risks
3. The three verification levels (overview)
4. Use cases: checklist, contracts, and pentests
5. How the BazarNube team would use ASVS

The OWASP ASVS (Application Security Verification Standard) is a standard of verifiable security requirements for web applications. Put simply: it is an organized list of "things the application must meet", worded so that they can be checked one by one (verifying whether they are met or not).

Its essential traits:

• It is a standard, not an awareness document. Whereas the Top Ten says "watch out for injection", ASVS says something checkable such as "every database query must use parameterized queries".
• It is organized into thematic chapters (authentication, access control, input validation, cryptography, session management, and so on), not by "top of risks".
• Each requirement is a verifiable statement, designed to be answered with a yes/no and evidence. This makes it ideal for audits, checklists, and contracts.
• It is structured into levels (L1, L2, L3) according to how much security the application needs.

The word that sums up ASVS is verification. It doesn't ask "do you know this risk?", but "can you prove you've mitigated it?".

This is the key point of the lesson. The Top Ten and ASVS don't compete: they are complementary and operate on different planes. Confusing them is a common mistake.

An intuitive way to see it:

A useful analogy: the Top Ten is like the brochure of "the ten most common household accidents"; ASVS is like the technical inspection with its list of points to check (is the electrical installation compliant? is there a smoke detector? has the gas been inspected?). The first raises your awareness; the second lets you sign off that the house is fit to live in.

Not every application needs the same degree of security: a personal blog is not the same as BazarNube's payment gateway. That's why ASVS defines three levels of increasing demand. Here we only introduce them; module 4 explains which concrete requirements go into each one.

Ideas worth fixing now, without going into detail:

• The levels are cumulative: L2 includes everything in L1, and L3 includes everything in L2.
• The level is chosen according to the business risk and the data the application handles, not on a whim.
• For a marketplace that processes payments and personal data like BazarNube, the reasonable target is usually L2. L3 is reserved for the most critical cases.

What is ASVS for in day-to-day work? Its three most common uses:

1. As a security verification checklist. The team goes through the applicable requirements and marks which ones BazarNube meets, which it doesn't, and which don't apply. The result is an objective inventory of the security posture, far more useful than "we think we're fine".
2. As a basis for contracts and requirements. When BazarNube contracts external development, or when a client demands guarantees, you can write into the contract "the application will comply with ASVS level 2". That turns a vague demand ("make it secure") into a measurable, auditable commitment.
3. As a script for pentests and audits. Instead of each pentester improvising, ASVS provides a common scope: "verify these requirements from the authentication and access control chapter". Reports come out structured and comparable across audits.

Let's apply it. The findings backlog we started labeling with the Top Ten is good for detecting problems, but not for proving that we're complete. This is where ASVS comes in. The team would take these steps (which module 4 develops):

1. Choose the target level. Since BazarNube handles payments and personal data, they set ASVS L2 as the goal. They record it as an architecture decision.
2. Turn requirements into verifiable tasks. Each applicable ASVS requirement becomes a concrete check on the app. Let's see, in simplified form, what that translation looks like:

Notice the power of this format compared to the Top Ten:

• Each line is a checkable statement with a verdict (PASS / FAIL / REVIEW).
• Each failure links to a finding in the backlog, which in turn carries its Top Ten label (A01, A03, A07...). This way, Top Ten and ASVS reinforce each other: the Top Ten names the risk, ASVS verifies it.
• The whole gives an objective, presentable snapshot for management or a client: "we meet 82% of the L2 requirements; these are the pending ones".

3. Use the checklist as a bridge to the pentest. When they contract a pentest or use ZAP (lesson 02-04), the scope is already defined by the ASVS requirements marked "REVIEW" or "FAIL".

In short: ASVS gives BazarNube the language to move from "we know the risks" to "we can prove, requirement by requirement, where we stand".

• Confusing ASVS with the Top Ten. They are not interchangeable: the Top Ten raises awareness (risks), ASVS verifies (requirements). They are used together, not one instead of the other.
• Choosing L3 "because it's the most secure". Aiming for a level higher than you need generates enormous cost and requirements that add nothing to your real risk. Choose the level by the value of the data, not by perfectionism. For BazarNube, L2 is the sensible goal.
• Treating ASVS as all-or-nothing. You don't need to meet 100% at once. The checklist exists precisely to measure progress and prioritize.
• Verifying only in the interface. Many requirements (especially L2/L3) require looking at the code and the design, not just testing the app from the outside. Verifying only the UI gives false reassurance.
• Tip: start with the access control and authentication chapters. They tend to be where the most failures appear and where fixing them has the greatest impact.

Exercise 1. For each sentence, indicate whether it corresponds to the Top Ten or to ASVS: (a) "The system must invalidate the session on the server side upon logout"; (b) "One of the most critical risks is broken access control"; (c) "The application will comply with level L2 according to an external audit".

Exercise 2. BazarNube handles payments and personal data, but it is not a bank. Argue in 3–4 lines which ASVS level would be the reasonable target and why not L1 or L3.

Exercise 3. Explain how the Top Ten and ASVS complement each other in BazarNube's workflow, using a concrete example of a finding that passes through both.

Solution 1. (a) ASVS (it's a verifiable, concrete, checkable requirement); (b) Top Ten (it's an awareness statement about a risk, corresponding to A01); (c) ASVS (it talks about meeting a verification level, which is characteristic of the standard).

Solution 2. The reasonable target is L2. L1 is a minimum intended for low-risk apps, insufficient for someone who processes payments and personal data (exposure to GDPR/PCI-DSS). L3 is reserved for systems of extreme value (central banking, critical infrastructure, healthcare) and entails a disproportionate verification cost for a young marketplace. L2 covers BazarNube's real risk without overloading the team.

Solution 3. Example: during the ASVS self-assessment, the requirement "every endpoint verifies authorization on the server" comes up as FAIL. That failure is recorded in the backlog as a finding and is labeled with the Top Ten as A01 (Broken Access Control). This way, the Top Ten provides the name and category of the risk (communication and prioritization), while ASVS provides the verifiable requirement and the evidence that it was not met (audit and proof). One raises awareness, the other verifies; together they close the loop.

You have met the second tool in the OWASP box: ASVS, a standard of verifiable requirements that answers what the Top Ten cannot: to prove the security state of an application. You know that it differs from the Top Ten in plane (requirements vs risks), that it defines three levels (L1, L2, L3) according to the value of the application, and that it is used as a checklist, a contractual basis, and a pentest script. And you have seen how BazarNube would aim for L2, turning its backlog into a verifiable checklist linked to the Top Ten labels.

With the Top Ten and ASVS we have tools focused on the application: its risks and its requirements. But a higher-level question arises: is the BazarNube organization ready, as a team and as a process, to produce secure software in a sustained way? That is no longer measured on an app, but on the organization itself. That is the terrain of the next tool: in lesson 02-03 we present OWASP SAMM, the maturity model for the security program.