Security requirements

Do this

1. Pick an ASVS level for the application

   Record one OWASP ASVS 5.0.0 level per application. Level 1 holds about 20% of the requirements, meeting level 2 means about 70% of them, and ASVS says most applications should strive for level 2. Revisit the level when the data or the exposure changes; data classification (Data classification) tells you when.

2. Select the requirements the feature touches

   Map what the feature does to ASVS chapters: records read by ID to V8 Authorization, sign-in to V6 Authentication and V7 Session Management, uploads to V5 File Handling. Keep the requirements at or below your level and cite them with the version, such as v5.0.0-8.2.2, because IDs can change between versions.

3. Add requirements from abuse cases, threats and obligations

   A checklist misses the feature's own logic. Add a requirement for each abuse case you decide to address (Abuse cases), each threat you mitigate (Threat modeling), and each law, contract or past finding that applies. Record which source produced each requirement, so a reviewer can see why it exists.

4. Write outcomes, not mechanisms

   Give each requirement a subject, an outcome and a boundary: "the tenant comes from the session", not "use middleware X". OWASP SAMM gives the same advice: a requirement states the objective, such as transferring and storing registration data securely, not a measure such as a TLS version. It also warns that "protect against the OWASP Top 10" is too general to be useful.

5. Write acceptance criteria with the refused case

   Use the format the team already uses, such as Given/When/Then. Include the case that must be refused and what the caller can observe: a status, a body or a log entry. For example: a request for another tenant's invoice returns the same 404 as a missing invoice, so IDs cannot be probed.

6. Trace each requirement to a test or evidence

   Keep the requirements in a version-controlled file with the ID, text, source, ASVS IDs and verification method. Automate the tests so that removing the control fails the build; for manual checks, name the evidence. NIST SSDF task PW.1.2 asks you to track and maintain the software's security requirements, risks and design decisions.

7. Add a short security Definition of Done

   Make every item a yes/no check, such as "each requirement in scope has a passing test or dated evidence" and "no new SAST finding at blocking severity". Say which changes need a security review (Security design review), for example anything that changes authentication, authorization or tenant rules.

Common mistakes

• Copying the whole ASVS into every story. A 300-line checklist gets ticked, not read; select by feature and level instead.
• Writing mechanisms instead of outcomes. "Use the auth middleware" still passes when a new route forgets it; "every route under /invoices checks the tenant" fails.
• Testing only the happy path. Most security requirements say what must not happen, so the refused case is the test that matters.
• Accepting "security reviewed" as evidence. Without a named reviewer, a date and what was checked, nobody can later tell whether the requirement ever held.
• Keeping requirements in a document away from the code. They drift from what was built; keep them in the repository and review changes to them like code.

Vague requirement or testable one?

A requirement is testable when someone other than its author can decide, from the running system or its records, whether it holds. The thresholds below are examples; set your own.

Tools and guides

• Tool: ASVS 5.0 checklist export
• Workflow: Secure a feature
• Write testable security requirements and a security Definition of Done

  Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done.

• Abuse case library: tests and controls by feature

  Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC.

Standards

NIST SSDF 1.1

PO.1 Define Security Requirements for Software DevelopmentPW.1 Design Software to Meet Security Requirements and Mitigate Security Risks

OWASP SAMM 2

Security RequirementsRequirements-driven Testing

Sources

1. OWASP ASVS 5.0.0: What is the ASVS? (levels and requirement identifiers). Version 5.0.0.
2. OWASP ASVS 5.0.0: V8 Authorization. Version 5.0.0.
3. OWASP ASVS 5.0.0: V16 Security Logging and Error Handling. Version 5.0.0.
4. OWASP SAMM: Security Requirements, stream A (Software Requirements)
5. OWASP SAMM: Requirements-driven Testing
6. NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. February 2022.