ASVS Verification

// 1) What ASVS is
// • Published by OWASP; current version 4.0.3 (2021) — v5 in draft
// • 14 chapters of CONTROLS, each numbered (V1.1.1, V2.1.5, ...)
// • 3 levels of increasing rigor:
//     L1 — basic security (any app processing minor data)
//     L2 — most apps (handling personal / business data)
//     L3 — high-value / regulated (health, finance, government)
// • Each requirement is a TESTABLE assertion ('The application uses…')

// 2) Chapters at a glance
// V1  Architecture, Design, Threat Modelling
// V2  Authentication
// V3  Session Management
// V4  Access Control
// V5  Validation, Sanitization, Encoding
// V6  Stored Cryptography
// V7  Error Handling, Logging
// V8  Data Protection
// V9  Communication
// V10 Malicious Code
// V11 Business Logic
// V12 Files, Resources
// V13 API + Web Service
// V14 Configuration

// 3) Example requirements (selected)
// V2.1.1   (L1) Verify that user-set passwords are at least 12 characters in length
// V2.1.5   (L2) Verify users can change their password
// V3.2.1   (L1) Verify the application generates a new session token on user authentication
// V4.1.1   (L1) Verify that the application enforces access control rules on a trusted service layer
// V5.1.3   (L1) Verify that all input is validated using positive validation (allowlists)
// V6.2.1   (L1) Verify that all cryptographic modules fail securely
// V7.4.1   (L1) Verify that a generic message is shown when an unexpected or security sensitive error occurs
// V8.3.4   (L1) Verify that sensitive data is sent to the server in the HTTP message body or headers
// V9.1.1   (L1) Verify that secured TLS is used for all client connectivity
// V11.1.1 (L1) Verify the application will only process business logic flows for the same user in sequential step order
// V13.1.4 (L1) Verify that REST services that utilise cookies are protected from Cross-Site Request Forgery
// V14.5.1 (L1) Verify that the application server only accepts the HTTP methods in use by the application or API

// 4) How to use it — different scenarios
//
// (A) Design review
//   Walk through the architecture; mark each requirement as Pass / Fail / N/A.
//   Output: list of gaps + planned remediations.
//
// (B) Penetration test scope
//   The pentester confirms each L2 control. Reports tie findings to V-numbers.
//
// (C) Vendor evaluation
//   Ask suppliers to fill ASVS checklist before procurement.
//
// (D) CI / CD checklist
//   Integrate testable requirements as automated tests (e.g. password length, CSRF, TLS).
//
// (E) Engineering onboarding
//   New devs read the ASVS chapter relevant to their work area.

// 5) Mapping ASVS to your tech
// Example — Node.js + Express + PostgreSQL
//
//   V2.1.1 Password length ≥ 12        → Argon2id + Zod schema in /signup
//   V2.4.1 Rate-limit auth              → express-rate-limit on /login
//   V3.2.1 New session id on login     → req.session.regenerate()
//   V4.1.1 Server-side access control   → centralised policy layer
//   V5.1.4 Output encoding              → templating engine escapes by default
//   V5.3.4 SQL injection                → parameterised queries; no string concat
//   V6.2.5 Key management               → AWS KMS for app keys
//   V7.1.3 Log security events           → structured logs; auth.success, auth.failure events
//   V9.1.1 TLS                          → ALB + ACM cert; HSTS; redirect HTTP→HTTPS
//   V13.1.4 CSRF                        → double-submit token middleware
//   V14.4.1 Security headers            → helmet middleware

// 6) Tracking progress
// • Track in a spreadsheet, Confluence page, or GitHub Issues
// • For each requirement: status (Pass / Fail / N/A / In Progress), evidence link, owner
// • Schedule periodic re-verification (quarterly minimum)
// • Output: % of L2 controls met; bridge to compliance frameworks (ISO 27001, SOC 2)

// 7) Tooling support
// • OWASP ASVS GitHub repo — markdown source, machine-readable JSON
// • SAMM (Software Assurance Maturity Model) — complements ASVS
// • ZAP scan rules tagged with ASVS V-numbers
// • Some commercial DAST/SAST link findings to ASVS

// 8) Choosing a level
// L1: marketing sites, low-value SaaS
// L2: typical apps with user accounts + business data
// L3: critical infrastructure, healthcare, finance, classified
//
// Most teams target L2. Get there first, then add L3 controls where data risk justifies.

// 9) Common adoption patterns
// • Quarterly ASVS audit: review randomly-selected requirements
// • Bug triage: every security finding tied to a V-number
// • Threat modelling: align with V1
// • PR review checklist: paste relevant requirements
// • SLOs: track 'percentage of L2 controls Passing'

// 10) Example: Mapping a single requirement to engineering
// V3.2.1: 'Verify the application generates a new session token on user authentication'
//
// Implementation:
function login(req, res) {
    const user = await auth.verify(req.body.email, req.body.password);
    if (!user) return res.status(401).json({ error: 'invalid' });
    req.session.regenerate((err) => {
        if (err) return next(err);
        req.session.userId = user.id;
        res.json({ ok: true });
    });
}

// Test:
test('login regenerates session id', async () => {
    const r1 = await agent.get('/login');
    const before = sidFromCookie(r1);
    await agent.post('/login').send({ email, password });
    const r2 = await agent.get('/me');
    const after = sidFromCookie(r2);
    expect(after).not.toBe(before);
});

// Result: V3.2.1 marked Pass with link to commit + test.

// 11) Where ASVS overlaps other standards
// • PCI DSS 6.5 → Top 10
// • ISO 27001 A.14 → controls overlap
// • NIST SP 800-53 → broader; ASVS is more developer-friendly
// • GDPR / HIPAA / APP — ASVS is technical; these are legal/operational

// 12) Common bugs / mistakes
// • Treating ASVS as a one-off audit; not embedding in dev cycle
// • Picking only L1 because 'we don't have time' — leaves significant gaps
// • Marking many requirements N/A without justification — auditors will dig
// • Trying to do all of L3 at once — pace yourself, prioritise highest-risk first
// • No evidence behind 'Pass' claims — auditors require artefacts (test, commit, screenshot)
// • Ignoring V11 (business logic) — these are MANUAL; can't be SAST/DAST'd
// • Not training engineers in ASVS — checklist culture without understanding
// • Single annual review only — drift between audits

// 13) Starting point — a one-week plan
// Day 1: download ASVS, pick target level (L2)
// Day 2: walk through V1 + V2; mark Pass/Fail with evidence
// Day 3: V3 + V4 + V5
// Day 4: V6 + V7 + V8
// Day 5: V9-V14
// Output: spreadsheet of all requirements + status + planned remediations
//
// Then schedule remediation work over the next quarter; re-audit quarterly.

// 14) Common bugs to avoid in adoption
// • Spending 6 months on the audit before fixing anything → start fixing in week 2
// • Auditing in a vacuum — bring engineers along; transfer ownership
// • Treating ASVS as the only standard — supplement with threat modelling + pentests + bug bounty
// • Trying to map every commercial scanner finding to ASVS — most are wider than ASVS
// • No exec sponsor — security investment gets cut; tie metrics to compliance + risk

// ASVS = OWASP Application Security Verification Standard.
// 3 levels (1-3). Pick a target level per app and verify each requirement.