Closing module 3 left us with an uncomfortable idea: the OWASP Top Ten is an excellent map of the most frequent risks, but that is all it is, the "ten most frequent". It is not an exhaustive checklist, nor something a tester can verify requirement by requirement and sign off as "met". BazarNube needs to take the next step: to move from "we know the big risks" to "we can verify, systematically and by levels, that the application meets a complete catalogue of security requirements". That standard exists and it is called ASVS. In this lesson we will look at what it is, how it is structured, who it serves and why it is different from (and complementary to) the Top Ten.

1. What the ASVS is and what it is for
2. The key difference: verifiable requirements vs. risks
3. Structure of the standard: chapters V1–V14
4. Anatomy of an ASVS requirement
5. Who it serves: developers, testers and buyers
6. How BazarNube decides to adopt ASVS

ASVS stands for Application Security Verification Standard. It is a flagship OWASP project that offers an open, community-driven list of verifiable security requirements for web applications and services.

Its purpose is to answer a very specific question that the Top Ten does not answer well:

"What exactly must my application meet to be considered reasonably secure, and how do I check, one by one, that it meets it?"

The ASVS provides that "what" in the form of hundreds of checkable statements. Each requirement is worded so it can be answered with a yes / no / not applicable after a code review, a penetration test or a design check. It serves three fundamental purposes:

• As a metric: it measures how secure a product is on a defined scale.
• As a guide: it tells developers which controls to build.
• As a basis for contracts: it lets you require a specific level of security from a supplier or auditor.

In module 2 we already introduced the ASVS at a high level and defined it as the standard of verifiable requirements with three levels (L1–L3). Now we open it up in depth. The classic reference version is v4.0.3; the community has worked on a v5.0 that reorganizes and modernizes the chapters, but the concepts we will cover (levels, thematic chapters, atomic requirements) are stable across versions. We will use the V1–V14 numbering of the v4.x family as it is the most widely used.

This distinction is the heart of the module, so it is worth nailing it down.

An example makes it clear. In the Top Ten, A07 – Identification and Authentication Failures is a risk category: "authentication may be done poorly". The ASVS breaks that same territory down into dozens of concrete, checkable requirements:

The Top Ten tells you where to look; the ASVS tells you what to require and how to check it. They do not compete: the Top Ten is the didactic entry point and the ASVS is the rigorous verification instrument.

The ASVS groups its requirements into thematic chapters, each identified with a V (for Verification) and a number. Knowing the full map lets you find your way quickly when looking for a requirement.

Each chapter is subdivided into sections (for example V2.1 "Password requirements") and each section contains individual requirements (V2.1.1, V2.1.2...). Version v5.0 reorganizes some of these chapters and renumbers them, but the thematic logic remains: you will always find authentication, sessions, access control, validation, cryptography, logging, etc. as recognizable blocks.

Every requirement shares a common structure. Seeing it in detail will help us read them fluently in the coming lessons.

Notice three properties that make a requirement "verifiable":

• It is a checkable statement: it begins with "Verify that..." and describes a state that can be confirmed or refuted.
• It is mapped to levels: each requirement indicates whether it applies in L1, L2, L3 or several (we will see this in lesson 04-02).
• It usually references a CWE: it links to the standard taxonomy of weaknesses, useful for traceability and for tooling.

This atomic wording is what makes it possible to turn the standard into a real checklist, into acceptance criteria and into audit evidence.

The ASVS is designed to serve three audiences, and understanding each one helps BazarNube decide how to use it:

• Developers (like Lucía and Marc): they use it as a build guide. Before writing the login module, they consult V2 and know which controls they must implement. The standard becomes a catalogue of "what I must build to be sound".
• Testers and auditors (the verification side): they use it as a test script. Each requirement is a test case; the outcome of the audit is a percentage of compliance per level, not a vague opinion.
• Buyers and stakeholders (product owners, clients, management): they use it as a contract clause. Instead of asking for "a secure application" (undefinable), they ask for "ASVS Level 2 compliance verified by a third party", which is measurable and enforceable.

This triple usefulness —build, verify and contract over the same vocabulary— is what turns the ASVS into a common language between teams that previously talked about security in fuzzy terms.

After module 3, BazarNube's security backlog has dozens of entries: hardened access control, encryption of payment data, security headers, input validation, logging, SSRF mitigation... Lucía frames the problem in the retrospective:

"We've fixed a lot of things, but we have no way of saying how secure we are or of proving it to an enterprise client who is going to audit us. We need a verification framework, not another list of fears."

The SRE adds that the new corporate client contractually requires "demonstrable compliance with a recognized standard". The Top Ten cannot underpin that signature; the ASVS can. The team makes three decisions that will guide the rest of the module:

1. Adopt ASVS as the reference catalogue of verifiable requirements.
2. Choose a target level matching its criticality (we will decide this in 04-02).
3. Map the current backlog from the Top Ten to concrete ASVS requirements, so as not to start from scratch (we will do this in 04-03).

With that roadmap, BazarNube stops "firefighting" and starts "verifying against a catalogue".

• Confusing ASVS with the Top Ten. They are neither the same nor substitutes: the Top Ten is risk awareness; the ASVS is requirement verification. They are used together.
• Trying to meet "the whole ASVS" at once. The standard is designed to be applied by levels; without choosing a level, the list is overwhelming and demotivating.
• Reading a requirement as a fuzzy recommendation. Each requirement is a statement with a binary answer; if you cannot answer yes/no/not applicable, you have not yet understood or tested it.
• Ignoring the chapter number. V2, V3, V4... are a very powerful mental index; memorizing the V1–V14 map hugely speeds up the work.
• Tip: always start by locating the thematic chapter (is this authentication? → V2), then the section, and only then the specific requirement. Going from the general to the specific stops you from getting lost.

Exercise 1. Explain in your own words the difference between "A07 – Authentication Failures" from the Top Ten and the requirement "V2.1.1 – Verify that passwords are at least 12 characters long" from the ASVS. Why do we say one is a risk and the other a verifiable requirement?

Exercise 2. BazarNube has "harden access control because we had IDOR" in its backlog. In which ASVS chapter (V1–V14) would you look for the corresponding requirements, and why?

Exercise 3. A client asks BazarNube to make "the application secure". Rewrite that request as a contract clause using the ASVS vocabulary and explain why your version is verifiable and the original is not.

Solution 1. "A07 – Authentication Failures" is a risk category: it points to an area where problems tend to appear, but it does not say what exactly to check. "V2.1.1" is a verifiable requirement: a concrete statement ("passwords are ≥12 characters") that a tester can confirm or refute with a yes/no. The first raises awareness and prioritizes; the second is checked and signed off. The ASVS breaks the Top Ten's broad risk down into many atomic requirements like this one.

Solution 2. In chapter V4 – Access control. IDOR (Insecure Direct Object Reference) is an authorization flaw: the user accesses an object that does not belong to them. The requirements for authorization, resource ownership checks and prevention of insecure direct references live in V4. (The territory corresponds to A01 in the Top Ten, which in the ASVS is verified from V4.)

Solution 3. ASVS version: "The supplier shall deliver the application with verified compliance to OWASP ASVS Level 2 (v4.0.3), demonstrated through per-requirement evidence of compliance and verification by an independent third party". It is verifiable because it defines a specific standard, a measurable level (L2), a checking method (per-requirement evidence) and external validation. The original request ("make it secure") is not measurable: it does not say against what, to what extent, or how it is checked, so no one can sign off its fulfilment.

The ASVS is OWASP's standard for verifying the security of an application through a complete catalogue of checkable requirements, organized into chapters V1–V14 and worded as statements with a yes/no/not-applicable answer. It differs from the Top Ten in that the latter enumerates frequent risks while the ASVS enumerates verifiable requirements, and the two complement each other. It serves developers (guide), testers (test script) and buyers (contract). BazarNube adopts it to be able to measure and demonstrate its security to a client that requires it by contract.

But we have left one piece pending: the ASVS does not demand the same of a personal blog as of a payment platform. Each requirement is tagged for one or more assurance levels. In the next lesson, 04-02 Verification Levels, we will see what L1, L2 and L3 require, how to choose the right level based on the criticality and the data the application handles, and we will decide which target level makes sense for BazarNube.