# Security Requirements and Abuse Cases — DevSecOps

Source: https://www.skillbyai.com/en/devsecops/dso-security-requirements

> Turn vague goals into testable security requirements using abuse cases and a verification standard such as OWASP ASVS.

## Making security testable

'The app must be secure' cannot be tested. A **security requirement** must be specific and verifiable, for example: *passwords are hashed with a slow, salted algorithm such as Argon2id or bcrypt*, or *every API endpoint except `/health` requires a valid access token*. A good source is the **OWASP Application Security Verification Standard (ASVS)**, a catalogue of requirements grouped by area (authentication, session management, access control, input handling and more) and by level, from basic hygiene to high-assurance systems. Teams pick a level and turn relevant items into acceptance criteria. Alongside user stories, write **abuse cases**: *As an attacker, I want to reuse a stolen session cookie so that I can act as another user.* Each abuse case suggests a control and a test. Requirements written this way flow naturally into automated tests that run in CI, which is exactly where DevSecOps wants them.

## An abuse case becomes a test

A minimal check that a protected handler rejects missing and wrong tokens. In a real project this lives in your test suite and runs on every pull request.

```python
def get_invoice(headers):
    token = headers.get("Authorization", "")
    if token != "Bearer valid-token":
        return 401
    return 200

cases = {"no token": {}, "wrong token": {"Authorization": "Bearer stolen"},
         "valid": {"Authorization": "Bearer valid-token"}}
for name, h in cases.items():
    print(f"{name:<12} -> {get_invoice(h)}")
```

Output:

```
no token     -> 401
wrong token  -> 401
valid        -> 200
```

## Write the negative test

Most test suites check that the right user *can* do something. Security bugs hide in the missing test that the wrong user *cannot*. Add one negative test per authorisation rule.

**Quiz:** Which of these is a well-formed security requirement?

- [ ] The system should be very secure
- [ ] We will follow best practices
- [ ] Hackers must not get in
- [x] All endpoints except /health reject requests without a valid access token with HTTP 401

*Answer:* All endpoints except /health reject requests without a valid access token with HTTP 401. A good requirement is specific and testable; the last option can be verified with an automated test.