Security Requirements and Abuse Cases Guide: Building Security into Design

"The application must be secure" is not a requirement anyone can build, test or accept, yet it is still what many projects start from. Security defects that trace back to design, such as missing object-level authorisation, unlimited business flows or forgotten administrative paths, are almost never caught by scanners because nobody wrote down what the system should refuse to do. Security requirements state what the software must do to protect itself and its data; abuse cases state how a feature could be used in ways the designers did not intend. Together they turn threat modelling into backlog items, acceptance criteria and tests. This guide covers sources of requirements, how to write testable ones, how to run abuse case workshops, how to carry requirements through delivery and supplier contracts, and how to measure the result. It is for product security leads, architects, business analysts and engineering managers. The surrounding lifecycle is covered in the Secure Software Development Lifecycle (SSDLC) Guide.

Key takeaways

• Requirements are an SSDF practice, not an extra. NIST SP 800-218 task PO.1.2 asks organisations to document and maintain security requirements for the software they build, and PW.1.2 to track requirements, risks and design decisions.
• Start from a catalogue, then add context. OWASP ASVS 5.0 gives about 345 verifiable requirements across three levels; abuse cases add the business-specific requirements no catalogue can know.
• Every requirement needs a test. If a requirement cannot be verified by a unit test, an integration test, a review or a penetration test, rewrite it until it can.
• Abuse cases come from people who think like attackers. The OWASP approach puts business analysts, testers, technical leads and penetration testers in one workshop per feature set, producing rated abuse cases and countermeasures.
• Suppliers inherit your requirements. SSDF PO.1.3 and the OWASP SAMM Supplier Security stream both expect requirements to reach contracts and outsourced development, not stop at your own teams.

Types of security requirement

Functional requirements are easy to express as user stories. Non-functional and negative requirements are where projects fail, because they do not appear in demos and nobody owns them unless they are written down with an owner and a test. Persistent requirements, the ones that apply to every story (authentication on every endpoint, output encoding, logging), are best kept as a definition of done or a baseline rather than repeated in each ticket.

Where requirements come from

• OWASP ASVS 5.0: the stable release (5.0.0, May 2025) is designed as a source of requirements for development, testing and procurement. Pick a level per application (Level 1 as a baseline, Level 2 for most applications holding sensitive data, Level 3 for the most critical) and cite requirements with a version prefix such as v5.0.0-1.2.5 because identifiers change between versions. See the OWASP ASVS Guide.
• Documentation requirements inside ASVS: ASVS 5.0 has many "documentation defines" requirements that are themselves security requirements work, for example V2.1.3 (business logic limits per user and globally), V8.1.1 (authorisation rules), V13.1.1 (communication needs and external services) and V16.1.1 (logging inventory).
• Threat models: each threat with a chosen mitigation becomes a requirement. SSDF PW.1.1 asks for risk modelling such as threat modelling or attack surface mapping to assess the software's risk. See the Threat Modelling Guide.
• Abuse cases: business-specific misuse that no generic catalogue covers (covered below).
• Regulation and contracts: sector rules such as PCI DSS, NYDFS Part 500 or health privacy laws, and customer contracts. Translate each obligation into a concrete, testable statement and record its source so the trace survives audits. See the PCI DSS 4.0 Guide and the NYDFS Part 500 Guide.
• Platform and domain baselines: OWASP API Security Top 10 for APIs, OWASP MASVS for mobile apps, cloud provider benchmarks for infrastructure, and the OWASP Top 10 for LLM Applications for AI features.
• Lessons learned: SSDF RV.3 asks teams to find root causes, look for whole classes of vulnerability and update the SDLC to stop recurrence. Each recurring finding should become a requirement or a baseline rule.

Writing testable security requirements

A good security requirement names the actor, the asset, the condition and the expected behaviour, and can be checked by someone who did not write it.

• Use "must" and "must not": keep "should" for guidance, not requirements.
• Give each requirement an ID: link it to its source (ASVS ID, threat, abuse case, regulation clause), its owner and its tests.
• Write acceptance criteria in Given/When/Then form: "Given a user authenticated as customer A, when they request order 1002 belonging to customer B, then the API returns 404 and logs an authorisation failure." This reads as a test case.
• Prefer standard components: SSDF PW.1.3 recommends standardised security features and services over proprietary ones, so a requirement such as "authentication uses the corporate IdP via OIDC" is better than describing a custom login.

Abuse cases: running the workshop

OWASP's Abuse Case Cheat Sheet defines an abuse case as a way to use a feature that the implementer did not expect, allowing an attacker to influence its behaviour or outcome. The cheat sheet is now marked historical because reviewers found abuse cases rarely used in practice, but its workshop method remains a practical way to derive business-specific requirements.

1. Prepare: make sure the business can explain each feature in scope. Create a workbook with three sheets: FEATURES (ID, name, short description), ABUSE CASES and COUNTERMEASURES (optional).
2. Invite the right people: business analysts, a risk analyst, ideally two penetration testers with different backgrounds, technical project leads and QA or functional testers. Application security staff propose countermeasures.
3. Bring attack references: where no penetration tester is available, use OWASP Automated Threats to Web Applications, the OWASP Testing Guide, the Mobile Testing Guide and MITRE CAPEC.
4. Walk each feature: the business explains it, testers propose attacks, AppSec proposes countermeasures, technical staff assess feasibility and risk owners assess likelihood and impact.
5. Rate and decide: record the business risk rating separately from any CVSS score (CVSS measures severity, not business risk, and should not be adjusted to stand in for it). Tag each case as Technical or Business and mark it To Address or Risk Accepted, with a written justification for acceptance. See the Security Exceptions and Risk Acceptance Guide.
6. Feed delivery: abuse cases to address become security requirements (waterfall) or acceptance criteria on user stories (agile). Hold the workshop once features are known, or once stories are planned into a sprint.

The ABUSE CASES sheet fields the cheat sheet lists are: abuse case ID (for example ABUSE_CASE_001), impacted feature ID, attack description, attack reference ID (such as a CAPEC ID), business risk rating, CVSS severity and vector, kind (Technical or Business), countermeasure ID and handling decision.

Example abuse cases

Carrying requirements through delivery

• Traceability: reference requirement and abuse case IDs in design documents, code comments or annotations so reviewers can find where each is handled, as the OWASP cheat sheet recommends.
• Automated verification: security unit and integration tests for each requirement guard against a later change silently removing a protection. Custom SAST and DAST rules can check patterns such as missing authorisation decorators. See the DevSecOps Guide.
• Manual verification: give code reviewers and penetration testers the list of addressed abuse cases so they test those first. SSDF PW.8.2 asks for tests to be scoped, designed, performed and documented, with findings recorded and triaged in the team's workflow. See the Secure Code Review Guide.
• Change triggers: new external interfaces, new data types, new roles, new AI features or new suppliers should trigger a requirements and abuse case review, not just a code review.
• Security champions: champions in each team keep requirements current and run lightweight abuse case sessions during refinement. See the Security Champions Programme Guide.

Supplier and cloud service security requirements

SSDF PO.1.3 asks organisations to communicate requirements to third parties who supply commercial software components. OWASP SAMM's Security Requirements practice has a Supplier Security stream that matures from assessing suppliers against your requirements, to building security terms into agreements, to giving suppliers clear security objectives.

• In contracts: reference an ASVS level, vulnerability remediation times, SBOM delivery, breach notification periods, penetration test evidence and secure handling of any credentials or API keys you issue to the supplier.
• For cloud and SaaS services: require SSO with SCIM, MFA for administrators, audit log export, customer-managed keys where needed and documented data residency.
• For outsourced development: give the supplier the same requirement set, abuse cases and test expectations as internal teams, and verify on delivery.

See the Third-Party Risk Management Guide and the SBOM Guide.

Where identity fits

Many design failures are identity failures that a requirement would have prevented: test and vendor accounts outside SSO, shared service credentials, API keys without owners, and integrations granted more access than their function needs. Add explicit requirements for every non-human identity a design introduces: who owns it, how it authenticates, what it can reach, how its secret is stored and rotated, and how it is decommissioned. See the API Key Management Guide.

Implementing a requirements programme

1. Pick a baseline: choose ASVS levels per application tier and publish the baseline requirement set as a versioned, machine-readable list (ASVS is available as CSV and JSON).
2. Pilot with two teams: one new product and one established service. Run one abuse case workshop each and convert the results into stories.
3. Add requirement IDs to tickets and tests: measure how many requirements have at least one automated test.
4. Extend to all high-risk applications: prioritise internet-facing, data-rich and payment applications first.
5. Bring in suppliers: add requirement schedules to new contracts and renewals.
6. Review and roll back: if a requirement proves unworkable, record a time-limited exception rather than deleting it, and revise it at the next baseline release.

Decision guidance

• Catalogue or bespoke: use ASVS for generic technical requirements and spend workshop time only on business logic, which no catalogue covers.
• Abuse case workshop or threat model: threat modelling works from the architecture (data flows, trust boundaries); abuse cases work from features and business intent. Use threat modelling for new architectures and abuse cases for new features in existing ones. High-risk systems need both.
• Small organisations: adopt ASVS Level 1 as the definition of done, add a one-hour abuse case session per major feature, and put a short security schedule in supplier contracts.
• Large organisations: maintain a central requirements library mapped to ASVS, regulations and internal policy, with tooling that attaches applicable requirements to projects automatically.

Detection and measurement

• Coverage: percentage of in-scope applications with a declared ASVS level and current requirement set.
• Test traceability: percentage of requirements with at least one automated test.
• Abuse case throughput: abuse cases identified per release and the share addressed versus risk accepted.
• Escape rate: penetration test and production findings that map to a missing or untested requirement.
• Recurrence: vulnerability classes that reappear after a root cause review (target falling).
• Supplier coverage: percentage of new and renewed software contracts with a security requirements schedule.

Framework mapping

Common failure patterns

• Requirements that cannot be tested: "secure", "robust" and "industry standard" give developers nothing to build and testers nothing to check.
• Only happy paths specified: without negative requirements, nobody tests what a user must not be able to do. In the McHire default password flaw, a test account with the password 123456 bypassed SSO, and an internal API returned applicant records by sequential ID, putting an estimated 64 million records within reach.
• Business logic limits never written down: the system has no defined ceiling on sign-ups, resets, purchases or exports, so nobody notices when a script uses them at scale. See the Rate Limiting and API Abuse Guide.
• Abuse cases run once and filed: the workshop output never reaches the backlog, so it changes nothing.
• Supplier requirements missing: outsourced code, test accounts and support access are held to no standard, and nobody verifies them on delivery.
• Requirements frozen: a list written for the first release is never updated for new APIs, AI features or integrations.

Practitioner checklist

• Assign an ASVS 5.0 level to every in-scope application and publish the baseline as a versioned list.
• Give every security requirement an ID, a source, an owner and at least one test.
• Write negative requirements for authorisation, business limits and administrative paths.
• Run an abuse case workshop for each new major feature, with testers and the business in the room.
• Record business risk separately from CVSS and justify every accepted abuse case in writing.
• Turn addressed abuse cases into acceptance criteria and automated tests.
• Add requirements for every non-human identity a design introduces.
• Include a security requirements schedule in supplier and cloud service contracts.
• Feed root causes from penetration tests and incidents back into the requirement set.

Standards and references

• NIST: SP 800-218 Secure Software Development Framework (SSDF) Version 1.1
• OWASP: Application Security Verification Standard 5.0
• OWASP: Abuse Case Cheat Sheet
• OWASP SAMM: Security Requirements
• NIST: SP 800-53 Rev. 5
• OWASP: API Security Top 10 2023
• OWASP: Automated Threats to Web Applications

Related NHI Mgmt Group resources: Secure Software Development Lifecycle (SSDLC) Guide · Threat Modelling Guide · OWASP ASVS Guide · Rate Limiting and API Abuse Guide · WebSocket Security Guide