We reach the lesson that closes the module. We already have the standard (ASVS), the target level (L2) and a checklist mapped from BazarNube's Top Ten findings. None of that is worth anything if it stays in a document. In this lesson we will see how to integrate the ASVS into the real lifecycle of a project: using the checklist as acceptance criteria and definition of done, deciding what is verified manually and what automatically, leaving traceable evidence, and taking the ASVS into contracts and pentests. We will finish with a practical step-by-step plan for BazarNube's backlog and with the connection to module 5.

1. From checklist to process: where ASVS fits in the SDLC
2. ASVS as acceptance criteria and definition of done
3. Manual vs. automated verification
4. Evidence and traceability
5. ASVS in contracts and pentests
6. Practical step-by-step plan for BazarNube
7. From project to organization: bridge to SAMM

The most common mistake is treating the ASVS as a last-minute audit. Its real value appears when it is distributed across the development lifecycle: the requirements guide the design, shape the implementation and are verified continuously, not just at the end.

The idea: each ASVS requirement relevant to a feature is selected in design, implemented as a control, verified before the task is considered done and leaves a piece of evidence. Compliance accumulates release by release until the target level (L2) is reached.

The most effective way to "embed" the ASVS in an agile team's day-to-day is to turn the requirements into acceptance criteria of the user stories and into part of the Definition of Done (DoD).

Example applied to a BazarNube story:

And a Definition of Done reinforced with ASVS for the whole team:

• The code passes the tests, including the security tests of the associated ASVS requirements.
• The L2 requirements applicable to the feature are verified and have evidence.
• No secrets are introduced into the repository (V6.4.1) — checked by the CI scanner.

This way, security stops being a separate phase and becomes a condition for considering any task done.

Not all requirements are checked the same way. A mature strategy combines both approaches and knows which one fits each requirement.

Practical rules:

• Automate the mechanical: vulnerable dependencies (SCA), secrets in the repo (secret scanning), TLS and header configuration, injection patterns (SAST). It runs on every commit/CI.
• Reserve manual verification for what requires judgment: object-level authorization in complex flows, threat modeling, business-logic abuse. Here code review and targeted testing are irreplaceable.
• The ZAP tool (which we will see in module 6) helps automate part of the dynamic verification; here it is enough to know that it exists and that it fits into this flow. We are not using it yet.

An anti-pattern: believing that a scanner "verifies the ASVS". Scanners cover a subset of objective requirements; the rest requires human judgment. ASVS L2 is not reached with tools alone.

A "verified" requirement with no evidence is worthless to an auditor. Each result must be traceable: who verified it, how, when and with what proof. A simple and sufficient format:

This table, maintained per requirement, is the compliance artifact: it shows the compliance percentage per level and serves directly as an audit deliverable. It is a good idea to version it alongside the code so it evolves with the product and always reflects the real state.

The ASVS shines as a common language between parties:

• In contracts: instead of requiring "a secure application", you specify "verified compliance with OWASP ASVS Level 2 (v4.0.3), with per-requirement evidence and verification by a third party". It is measurable, enforceable and auditable —exactly what BazarNube's enterprise client asks for.
• In pentests: instead of a pentest with a fuzzy scope, you commission "ASVS L2 compliance verification". The pentester uses the requirement list as a script; the report is structured by requirement (pass/fail) instead of by loose findings. The results can be compared across audits and over time.
• As a supplier acceptance criterion: if BazarNube integrates a third-party service, it can require an ASVS level of it and ask for its evidence table.

This closes the module's loop: the ASVS not only improves the app, it also professionalizes how security is contracted, audited and demonstrated.

Let us bring everything together into an actionable plan that BazarNube can execute over its backlog:

1. Set the target: ASVS L2 for the whole application; consider L3-level demands only for the payment subsystem (decided in 04-02).
2. Start from the mapping: take the "Top Ten findings → ASVS requirements" table from lesson 04-03 as the initial checklist by chapters.
3. Prioritize: order by risk and by effort. First the requirements that cover already-exploitable findings (IDOR V4.2.1, injection V5.3.4, secrets V6.4.1).
4. Turn it into work: each pending requirement enters as an acceptance criterion of a story and becomes part of the Definition of Done.
5. Automate the mechanical: set up in CI the SCA (V14.2.1), the secret scanner (V6.4.1) and the TLS/header checks (V9.1.1, V14.4.1).
6. Verify manually what requires judgment: code review for authorization (V4), checkout threat modeling (V1), business-logic abuse (V11).
7. Record evidence: maintain the per-requirement traceability table, versioned with the repo.
8. Measure progress: calculate the L2 compliance percentage in each release; the goal of the deployment gate is not to regress.
9. Prepare the external audit: hand the evidence table to the pentester/client as the basis for the contracted L2 verification.

With this plan, BazarNube's backlog stops being a list of fears and becomes a measurable verification program, with a known and demonstrable state in every release.

We have achieved something important: BazarNube now knows how to verify its application against a complete catalogue of requirements, by levels, with evidence. But notice one underlying limitation. Everything we have done answers the question "is this application secure?". There remains a bigger question unanswered:

"Is our organization capable of producing secure applications repeatably, and of improving that capability over time?"

The ASVS verifies the product; it does not measure whether the team has good processes for training, supplier management, incident response or continuous improvement. A company could pass an L2 audit today and, with no process maturity behind it, accumulate security debt again in the next project. Verifying the app is necessary but not sufficient: it also takes maturing the organization's security program.

That is exactly the leap of the next module. In module 5, OWASP SAMM (Software Assurance Maturity Model), we will stop looking at the application and look at the organization: how to assess the maturity of security practices by domain, how to place yourself on a scale and how to design a continuous-improvement plan. We move from "I know how to verify my app by levels" (ASVS) to "I know how to measure and grow my team's security capability" (SAMM).

• Verifying the ASVS only at the end. Applying it as a late audit drives up the cost of fixes; its value lies in distributing it across the SDLC as acceptance criteria.
• Believing that a scanner "meets the ASVS". Tools cover an objective subset; requirements around design, complex authorization and business logic demand manual verification.
• Marking requirements as "pass" without evidence. Without traceability (method, proof, date, owner) there is no demonstrable compliance for an auditor.
• Treating the ASVS as a one-off exam. It is a state maintained release by release; without a gate that prevents regressions, compliance erodes.
• Confusing verifying the app with maturing the organization. The ASVS measures the product; process maturity is SAMM territory (module 5).
• Tip: start small and visible. Automate three or four mechanical requirements in CI and show the evidence table; the initial momentum makes it easier to adopt the rest.

Exercise 1. Classify these requirements as "automatable verification in CI" or "manual verification" and justify: (a) V14.2.1 dependencies with CVE, (b) V4.2.1 resource ownership in a complex refunds flow, (c) V6.4.1 secrets in the repository, (d) V1.1.x existence of threat modeling.

Exercise 2. Write a security acceptance criterion, ASVS L2 style, for the BazarNube story "As a user I want to change my password". Include at least two requirements with their identifier.

Exercise 3. The enterprise client asks for "proof that BazarNube is compliant with ASVS L2". List three concrete artifacts you would hand over and explain what each one demonstrates.

Solution 1. (a) Automatable: an SCA in CI detects dependencies with CVE objectively and repeatably. (b) Manual: even though the ownership check is objective, a complex refunds flow has branches and states that demand code review and targeted testing; a scanner does not understand the business logic. (c) Automatable: a secret scanner in CI finds secrets by pattern with no human intervention. (d) Manual: the existence and quality of a threat model is a design artifact reviewed by hand; there is no tool that "detects" it.

Solution 2. "Acceptance criteria (security, ASVS L2): [V2.1.1] the new password is at least 12 characters long; [V2.1.7] it is rejected if it appears in lists of breached passwords; [V3.3.1] after the change, the user's other active sessions are invalidated. Verified with tests covering a short password, a breached password and continuity of the old session." (Including two is enough; three are shown here to illustrate.)

Solution 3. (1) Per-requirement evidence table (status, method, proof, date, owner): demonstrates the L2 compliance percentage and how each requirement was verified. (2) A pentest/external-verification report structured by ASVS L2 requirements: provides independent validation that the controls work. (3) CI outputs of the automated checks (SCA with no CVE, secret scanning at zero, TLS and header checks): demonstrate that the mechanical requirements are checked continuously and not just once. Together they cover internal evidence, external validation and continuous control.

Implementing the ASVS means integrating it into the lifecycle, not auditing it at the end: the requirements become acceptance criteria and part of the Definition of Done, they are verified by combining automation (dependencies, secrets, TLS, headers) and manual review (complex authorization, threat modeling, business logic), and each result leaves a traceable piece of evidence. That body of evidence is what makes it possible to take the ASVS into contracts and pentests with a measurable language. With the step-by-step plan, BazarNube's backlog is transformed into a demonstrable L2 verification program, release by release.

With this we close module 4: BazarNube now knows how to verify its application against a complete catalogue of requirements, by levels and with evidence. But verifying the product does not guarantee that the organization knows how to produce secure software repeatably and improve over time. That is the leap of module 5, OWASP SAMM: moving from verifying the application to measuring and maturing the organization's security program by domains and maturity levels. See you there.