Security requirements management

Most security issues aren't coding mistakes — they're missing requirements. Nobody specified that the password reset flow should expire tokens. Nobody documented that API endpoints need rate limiting. The developer built what was asked for. Security wasn't asked for.

Security requirements turn implicit assumptions into explicit, testable specifications. When "the user should be authenticated" becomes "authentication must use bcrypt with cost factor 12, sessions must expire after 30 minutes of inactivity, and failed login attempts must be rate-limited to 5 per hour" — you can actually verify the implementation.

This chapter covers how to define security requirements using industry standards, integrate them into your development workflow, and verify they're implemented correctly.

Why security requirements matter

Without explicit requirements:

Developers make their own security decisions (inconsistently)
Security reviews find issues late, when fixes are expensive
Testing doesn't cover security because there's nothing to test against
Compliance audits require reverse-engineering what was actually built

With explicit requirements:

Security decisions are made once, documented, and reused
Developers know exactly what's expected
QA can test security like any other feature
Compliance is demonstrable

The cost of fixing a security issue increases dramatically the later it's found. A requirement caught in design costs almost nothing to fix. The same issue found in production might require emergency patches, customer notification, and weeks of remediation.

OWASP Application Security Verification Standard (ASVS)

The OWASP ASVS is a comprehensive catalog of security requirements for web applications. Instead of inventing your own requirements, use ASVS as a baseline.

ASVS structure

ASVS organizes requirements into chapters:

Chapter	Topic	Example requirements
V1	Architecture	Threat modeling, secure design patterns
V2	Authentication	Password policies, MFA, credential storage
V3	Session management	Session tokens, timeouts, logout
V4	Access control	Role-based access, object-level authorization
V5	Validation	Input validation, output encoding
V6	Cryptography	Algorithm selection, key management
V7	Error handling	Logging, error messages
V8	Data protection	Data classification, PII handling
V9	Communication	TLS configuration, certificate validation
V10	Malicious code	Dependency integrity, code review
V11	Business logic	Abuse cases, workflow security
V12	Files	File upload, path traversal
V13	API	REST security, GraphQL, WebSocket
V14	Configuration	Security headers, build hardening

ASVS levels

ASVS defines three verification levels:

Level 1 — Minimum baseline Basic security for all applications. Covers the most common vulnerabilities (OWASP Top 10). Can be verified through automated testing.

Level 2 — Standard Recommended for most applications, especially those handling sensitive data. Requires some manual review.

Level 3 — Advanced For high-security applications (banking, healthcare, critical infrastructure). Requires thorough review and advanced testing.

For most small companies: start with Level 1, expand to Level 2 for sensitive features.

Example ASVS requirements

From authentication (V2):

V2.1.1: Verify that user set passwords are at least 12 characters in length.

V2.1.5: Verify users can change their password.

V2.1.7: Verify that passwords submitted during account registration, 
        login, and password change are checked against a set of breached 
        passwords either locally or using an external API.

V2.2.1: Verify that anti-automation controls are effective at mitigating 
        breached credential testing, brute force, and account lockout attacks.

Each requirement has:

Unique identifier (e.g., V2.1.1)
Clear, testable statement
Applicable ASVS level

OWASP Cheat Sheet Series

The OWASP Cheat Sheet Series provides implementation guidance for security topics. While ASVS tells you what to do, cheat sheets explain how to do it.

Useful cheat sheets for developers:

Topic	Cheat sheet
Authentication	Authentication Cheat Sheet
Password storage	Password Storage Cheat Sheet
Session management	Session Management Cheat Sheet
Input validation	Input Validation Cheat Sheet
SQL injection	Query Parameterization Cheat Sheet
XSS prevention	Cross Site Scripting Prevention Cheat Sheet
CSRF	Cross-Site Request Forgery Prevention Cheat Sheet
JWT	JSON Web Token Cheat Sheet
File upload	File Upload Cheat Sheet
API security	REST Security Cheat Sheet
Cryptography	Cryptographic Storage Cheat Sheet
Error handling	Error Handling Cheat Sheet
Logging	Logging Cheat Sheet

Link relevant cheat sheets to your requirements — they become implementation guides for developers.

Other OWASP resources

Resource	Purpose
OWASP Top 10	Most critical web application security risks
OWASP Testing Guide	Manual testing methodology
OWASP SAMM	Software Assurance Maturity Model
OWASP Security Knowledge Framework	Training and requirements platform
OWASP Proactive Controls	Top 10 security techniques for developers

ASVS and compliance frameworks

ASVS requirements map to common compliance standards. If you're pursuing certification, ASVS gives you a head start:

Compliance	Relevant ASVS chapters	Notes
SOC 2	V2, V3, V4, V7, V8, V14	Access control, logging, data protection
PCI-DSS	V2, V3, V4, V6, V7, V8, V9	Strong auth, encryption, logging
GDPR	V8, V7, V6	Data protection, breach logging, encryption
HIPAA	V2, V3, V6, V7, V8	Access control, audit trails, encryption
ISO 27001	All chapters	Comprehensive overlap

How this helps:

When auditors ask "how do you ensure secure authentication?", you point to V2 requirements and evidence
Customer security questionnaires often map directly to ASVS requirements
Compliance becomes verification of existing requirements, not a separate project

ASVS tools and platforms

Don't reinvent the wheel — tools exist to help manage ASVS requirements:

Free tools

Tool	Description	Link
OWASP ASVS Checklist	Interactive checklist	GitHub
ASVS Excel/CSV	Downloadable spreadsheet	ASVS GitHub
Security Knowledge Framework	Training + requirements mapping	SKF
OWASP Cornucopia	Threat modeling card game	Cornucopia

Commercial platforms with ASVS support

Tool	ASVS features
IriusRisk	Automatic ASVS requirements from threat models
SD Elements	Requirements library includes ASVS
Jira with Security Requirements Plugin	ASVS tracking in Jira
DefectDojo	Open source, tracks findings against ASVS

Selecting requirements for your project

You don't need to implement all 286 ASVS requirements on day one. Start with what matters for your application.

Quick start: essential requirements

For a typical web application with user accounts, start with these 25 requirements:

Authentication (V2)

V2.1.1: Passwords minimum 12 characters
V2.1.7: Check passwords against breach lists
V2.2.1: Rate limiting on login
V2.4.1: Passwords hashed with bcrypt/argon2

Session management (V3)

V3.2.1: Session tokens generated with secure random
V3.3.1: Session invalidated on logout
V3.7.1: Session timeout implemented

Access control (V4)

V4.1.1: Access control enforced on server
V4.1.2: Deny by default
V4.2.1: Protect against IDOR

Validation (V5)

V5.1.1: Server-side input validation
V5.2.1: Sanitize HTML input
V5.3.1: Output encoding for XSS prevention
V5.3.4: Context-aware output encoding

Cryptography (V6)

V6.2.1: Strong encryption algorithms only
V6.4.1: Secrets not hardcoded

Logging (V7)

V7.1.1: Log authentication events
V7.1.2: Log access control failures
V7.2.1: No sensitive data in logs

Data protection (V8)

V8.3.1: Sensitive data encrypted at rest
V8.3.4: Sensitive data encrypted in transit

Communication (V9)

V9.1.1: TLS for all connections
V9.1.2: Strong TLS configuration

Configuration (V14)

V14.4.1: Security headers configured
V14.4.3: Content-Security-Policy header
V14.4.5: Strict-Transport-Security header

Implement these 25 first. They cover the most common attack vectors and take a small team 2-4 weeks.

Prioritizing requirements by risk

Not all requirements are equally important. Use a simple risk scoring:

Impact (if requirement is missing):

Critical (4): Direct data breach, full system compromise, regulatory violation
High (3): Significant data exposure, account takeover
Medium (2): Limited exposure, requires other vulnerabilities
Low (1): Minimal impact, defense in depth

Likelihood (of exploitation):

High (3): Common attack vector, easy to exploit
Medium (2): Requires some skill or specific conditions
Low (1): Rare attack, requires significant effort

Risk Score = Impact × Likelihood

Score	Priority	Action
9-12	Critical	Implement immediately
5-8	High	Implement in current sprint
3-4	Medium	Plan for next quarter
1-2	Low	Backlog

Example prioritization:

Requirement	Impact	Likelihood	Score	Priority
V2.4.1 Password hashing	4 (breach)	3 (common attack)	12	Critical
V5.3.1 XSS prevention	3 (takeover)	3 (common)	9	Critical
V4.1.1 Server-side access control	4 (breach)	2 (requires auth)	8	High
V14.4.5 HSTS header	2 (MITM risk)	2 (targeted attack)	4	Medium

Step 1: Classify your application

What data do you handle?

Public data only → Lower requirements
User PII → V8 (Data Protection) is critical
Financial data → V6 (Cryptography), V2 (Authentication) are critical
Health data → Full V8, V2, V3, plus regulatory requirements

What's your attack surface?

Internal tool → Lower external threat profile
Public API → V13 (API) is critical
File processing → V12 (Files) is critical
E-commerce → V11 (Business Logic) is critical

Step 2: Start with Level 1 essentials

For any web application, start with these ASVS chapters at Level 1:

V2 Authentication — Password handling, lockout
V3 Session Management — Token security, expiration
V4 Access Control — Authorization checks
V5 Validation — Input validation, output encoding
V14 Configuration — Security headers, HTTPS

This covers the most common vulnerabilities with reasonable effort.

Step 3: Add feature-specific requirements

When building new features, identify relevant ASVS sections:

Feature	Relevant ASVS sections
User registration	V2.1 (Password Security)
Login / SSO	V2.2 (Authentication), V3 (Sessions)
File upload	V12.1 (File Upload)
API endpoints	V13 (API), V4 (Access Control)
Payment processing	V6 (Cryptography), V8 (Data Protection)
Password reset	V2.5 (Credential Recovery)
Admin panel	V4 (Access Control), V7 (Logging)
Search functionality	V5.3 (Output Encoding)

Step 4: Document your baseline

Create a document listing which ASVS requirements apply to your project:

# Security Requirements Baseline

## Scope
This document defines security requirements for [Project Name].

## ASVS Level
Level 1 for all features, Level 2 for authentication and payment.

## Applicable Chapters
- V2 Authentication: Full
- V3 Session Management: Full
- V4 Access Control: Full
- V5 Validation: 5.1, 5.2, 5.3 only
- V7 Error Handling: 7.1 only
- V8 Data Protection: 8.1, 8.3
- V13 API Security: Full
- V14 Configuration: Full

## Excluded (with justification)
- V12 Files: No file upload functionality
- V11 Business Logic: Simple CRUD, no complex workflows

Last reviewed: [Date]

Threat modeling and requirements

Threat modeling identifies what could go wrong. ASVS requirements specify how to prevent it. They work together.

Simple threat modeling for features

Before adding ASVS requirements to a feature, ask these questions:

STRIDE for each component:

Threat	Question	Example requirement
Spoofing	Can someone pretend to be another user?	V2, V3 (auth, sessions)
Tampering	Can someone modify data they shouldn't?	V4, V5 (access control, validation)
Repudiation	Can someone deny their actions?	V7 (logging)
Information disclosure	Can someone access data they shouldn't?	V4, V8 (access, data protection)
Denial of service	Can someone break availability?	V2.2 (rate limiting)
Elevation of privilege	Can someone gain unauthorized access?	V4 (access control)

For each identified threat:

Find the relevant ASVS section
Add those requirements to the feature
Verify they're tested

Quick threat modeling template

## Threat Model: [Feature Name]

### Assets
What are we protecting?
- [ ] User credentials
- [ ] User PII
- [ ] Financial data
- [ ] Business logic
- [ ] Other: ___

### Entry points
How do users interact with this feature?
- [ ] Web form
- [ ] API endpoint
- [ ] File upload
- [ ] Webhook
- [ ] Other: ___

### Trust boundaries crossed
- [ ] Internet → Web server
- [ ] Web server → Database
- [ ] Web server → External API
- [ ] User role → Admin role

### Threats identified
| Threat | Category | Mitigation | ASVS requirement |
|--------|----------|------------|------------------|
| | | | |

### Security requirements
Based on threats, apply these ASVS requirements: [List]

Tracking requirements in your workflow

Security requirements need to be tracked like any other work item. Use your existing tools.

Using Jira (or similar)

Create a custom issue type "Security Requirement" with fields:

Field	Options
ASVS ID	V2.1.1, V2.1.2, etc.
Status	Not Applicable, Not Implemented, In Progress, Implemented, Verified
Priority	Critical, High, Medium, Low
Applicable Features	List of features this requirement affects
Verification Method	Automated Test, Code Review, Penetration Test, Manual Check
Last Verified	Date
Evidence	Link to test results or review notes

Status workflow:

┌─────────────────┐
│ Not Applicable  │ ← Requirement doesn't apply to this project
└────────┬────────┘
         │ (applies)
         ▼
┌─────────────────┐
│ Not Implemented │ ← Requirement applies but isn't done
└────────┬────────┘
         │ (work started)
         ▼
┌─────────────────┐
│   In Progress   │ ← Implementation underway
└────────┬────────┘
         │ (code complete)
         ▼
┌─────────────────┐
│   Implemented   │ ← Code done, needs verification
└────────┬────────┘
         │ (tested/reviewed)
         ▼
┌─────────────────┐
│    Verified     │ ← Confirmed working
└─────────────────┘

Creating requirement tickets

For each applicable ASVS requirement, create a ticket:

Title: [V2.1.1] Minimum password length of 12 characters

Description:
ASVS Requirement: V2.1.1
Level: 1

Requirement text:
"Verify that user set passwords are at least 12 characters in length."

Implementation notes:
- Update password validation in registration and password change flows
- Update user-facing error messages
- See: OWASP Password Storage Cheat Sheet

Acceptance criteria:
- [ ] Registration rejects passwords under 12 characters
- [ ] Password change rejects passwords under 12 characters
- [ ] Error message explains minimum length
- [ ] Automated test covers both flows

Verification method: Automated Test

Linking requirements to features

When planning a new feature, link relevant security requirements:

Feature: User Registration

Security requirements:
- V2.1.1: Password minimum 12 characters
- V2.1.5: Users can change password
- V2.1.7: Check passwords against breach list
- V2.1.9: No password composition rules (just length)
- V2.4.1: Bcrypt for password storage
- V5.1.1: Server-side input validation
- V7.1.1: Log authentication events

Definition of Done:
- [ ] All linked security requirements verified

Specialized security requirements tools

For larger teams or compliance-heavy environments, specialized tools help:

GRC and compliance platforms

Tool	Description	Best for
Drata	SOC 2, ISO 27001 compliance automation	Startups pursuing SOC 2
Vanta	Continuous security monitoring + compliance	Similar to Drata
Secureframe	Compliance automation	SOC 2, HIPAA, PCI
Tugboat Logic	Security assurance platform	Growing companies
Hyperproof	Compliance operations	Enterprise compliance
OneTrust	GRC platform	Large enterprises

Threat modeling and requirements

Tool	Description	Best for
OWASP Threat Dragon	Open source threat modeling	Free, developer-friendly
Microsoft Threat Modeling Tool	Desktop threat modeling	Microsoft stack
IriusRisk	Threat modeling + requirements	Enterprise DevSecOps
SD Elements	Security requirements from design	Enterprise SDLC
Foreseeti	Attack simulation	Advanced threat modeling

Security testing platforms

Tool	Description	Best for
Snyk	Developer security platform	DevSecOps, SCA
Checkmarx	SAST + requirements tracking	Enterprise
Veracode	Security testing + policy	Enterprise
Contrast Security	IAST + RASP	Runtime protection
StackHawk	DAST for developers	API security testing

Simple approaches for small teams

Spreadsheet: Export ASVS to CSV (available on GitHub), filter to applicable requirements, track status in columns.

GitHub Issues: Create issues for each requirement, use labels for status, link to PRs that implement them.

Notion/Confluence: Database of requirements with status, linked to feature documentation.

For most small teams, Jira + a spreadsheet baseline works fine. Move to specialized tools when you have compliance requirements or security staff.

Ready-to-use templates

GitHub Issue Template (.github/ISSUE_TEMPLATE/security-requirement.md):

---
name: Security Requirement
about: Track ASVS security requirement implementation
title: '[ASVS] '
labels: security, requirement
assignees: ''
---

## ASVS Requirement

**ID:** V0.0.0
**Level:** 1 / 2 / 3
**Chapter:** 

## Requirement Text

> [Paste requirement text from ASVS]

## Implementation Notes

- Where does this apply in our codebase?
- What changes are needed?
- Related cheat sheet: [link]

## Acceptance Criteria

- [ ] Requirement implemented
- [ ] Automated test written
- [ ] Code reviewed
- [ ] Verified in staging

## Verification Method

- [ ] Automated test
- [ ] Code review
- [ ] Manual testing
- [ ] Penetration test

## Evidence

[Link to test results / review / audit]

PR Template addition (.github/pull_request_template.md):

## Security Checklist

- [ ] No secrets in code
- [ ] Input validation added for new inputs
- [ ] Output encoding for new outputs
- [ ] Access control checks in place
- [ ] Logging added for security events
- [ ] Security requirements linked: #

### Security Champion Review
- [ ] Required for: auth changes, access control, crypto, data handling
- [ ] Reviewer: @security-champion

Customer security questionnaires

When customers or partners send security questionnaires, ASVS makes answering easier.

Common questions and ASVS mapping

Question category	ASVS evidence
"How do you handle authentication?"	V2 requirements + verification
"How are passwords stored?"	V2.4 + bcrypt implementation
"Do you encrypt data at rest?"	V6, V8.3 + encryption details
"Do you have audit logging?"	V7 + log samples
"How do you handle session management?"	V3 requirements
"What security testing do you perform?"	ASVS verification records
"Do you follow secure coding practices?"	V5, V10 + SAST results

Preparing for questionnaires

Create an evidence library:
- For each major ASVS section, prepare a summary document
- Include: requirement ID, implementation status, evidence link

Standard response templates:

**Authentication Security**

We follow OWASP ASVS Level 2 for authentication (V2). 
Specific controls include:
- Password minimum 12 characters (V2.1.1)
- Passwords checked against breach databases (V2.1.7)
- Bcrypt with cost factor 12 for storage (V2.4.1)
- Rate limiting on login attempts (V2.2.1)
- MFA available for all users (V2.8)

Evidence: [Link to ASVS verification records]

Keep verification current:
- Questionnaires ask about current state
- Monthly reviews ensure your answers stay accurate

Questionnaire response workflow

Receive questionnaire
Map questions to ASVS sections
Check current verification status
Write response with evidence links
Security Champion reviews before submission
Track in CRM/deal system

Integrating into development workflow

Security requirements only work if they're part of how you build software.

The Security Champion's role

The Security Champion should be involved at these stages:

1. Feature design (before coding)

Review feature spec for security implications
Identify applicable ASVS requirements
Add security requirements to the feature ticket
Flag features needing threat modeling

2. Sprint planning

Ensure security requirements are included in estimates
Identify features that need security review before merge

3. Code review

Verify security requirements are implemented
Check for common vulnerabilities

4. Testing

Verify security tests exist and pass
Review test coverage for security requirements

Feature planning checklist

Before a feature enters development:

## Security Review Checklist

Feature: [Name]
Security Champion: [Name]
Date: [Date]

### Data handling
- [ ] What user data does this feature process?
- [ ] Does it introduce new PII fields?
- [ ] Does it involve file uploads?
- [ ] Does it expose data via API?

### Authentication/Authorization
- [ ] Does it require authentication?
- [ ] What authorization checks are needed?
- [ ] Does it change authentication flows?

### Applicable ASVS requirements
[List requirements with IDs]

### Threat considerations
- [ ] How could this feature be abused?
- [ ] What's the worst-case impact?

### Testing requirements
- [ ] What security tests are needed?
- [ ] Can they be automated?

### Notes
[Any special considerations]

Adding security to user stories

Include security in the definition of done:

As a user, I want to upload a profile picture.

Acceptance criteria:
- [ ] Only JPEG, PNG, GIF allowed (V12.1.1)
- [ ] Maximum file size 5MB (V12.1.2)
- [ ] File type validated by content, not extension (V12.1.3)
- [ ] Files stored outside web root (V12.4.1)
- [ ] Filename sanitized (V12.3.1)

Security requirements: V12.1.1, V12.1.2, V12.1.3, V12.3.1, V12.4.1

Security in CI/CD

Automate what you can:

# .github/workflows/security.yml
name: Security Checks

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      
      # Dependency scanning (V10.3)
      - name: Run Snyk
        uses: snyk/actions/node@master
        
      # SAST scanning (V10.2)
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        
      # Secrets detection (V6.4)
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        
      # Security headers check (V14)
      - name: Check security headers
        run: |
          # Custom script to verify headers in test environment

Tracking requirement coverage

Maintain visibility into your security posture:

Metric	What it measures
% requirements verified	Progress toward baseline
Days since last verification	Staleness of security checks
Requirements per feature	Security debt in planning
Test coverage of requirements	Automation level
Open security requirements	Current gap

Testing security requirements

Requirements aren't done until they're verified.

Verification methods

Different requirements need different verification:

Method	When to use	Examples
Automated tests	Repeatable checks	Password length, input validation, security headers
Code review	Logic and implementation	Access control, cryptographic usage
SAST/DAST	Broad vulnerability scanning	SQL injection, XSS, misconfigurations
Manual testing	Complex scenarios	Business logic abuse, authentication bypass
Penetration testing	Comprehensive assessment	All of the above + unknown issues

Writing security tests

Password policy (V2.1.1):

def test_password_minimum_length():
    # Too short - should fail
    response = client.post('/register', data={
        'email': '[email protected]',
        'password': 'short123'  # 8 chars
    })
    assert response.status_code == 400
    assert 'password' in response.json['errors']
    
    # Minimum length - should pass
    response = client.post('/register', data={
        'email': '[email protected]',
        'password': 'validpassword1'  # 14 chars
    })
    assert response.status_code == 201

Authorization check (V4.1.1):

def test_user_cannot_access_other_user_data():
    # Create two users
    user1 = create_user('[email protected]')
    user2 = create_user('[email protected]')
    
    # Login as user1
    token = login('[email protected]')
    
    # Try to access user2's data
    response = client.get(
        f'/api/users/{user2.id}/profile',
        headers={'Authorization': f'Bearer {token}'}
    )
    
    # Should be forbidden
    assert response.status_code == 403

Rate limiting (V2.2.1):

def test_login_rate_limiting():
    # Make 5 failed login attempts
    for i in range(5):
        response = client.post('/login', data={
            'email': '[email protected]',
            'password': 'wrongpassword'
        })
    
    # 6th attempt should be blocked
    response = client.post('/login', data={
        'email': '[email protected]',
        'password': 'wrongpassword'
    })
    assert response.status_code == 429  # Too Many Requests

Security headers (V14.4):

def test_security_headers():
    response = client.get('/')
    
    assert response.headers.get('X-Content-Type-Options') == 'nosniff'
    assert response.headers.get('X-Frame-Options') == 'DENY'
    assert 'max-age=' in response.headers.get('Strict-Transport-Security', '')
    assert response.headers.get('Content-Security-Policy') is not None

ASVS testing checklist

For each implemented requirement, verify:

## Requirement: V2.1.1 - Password minimum length

### Test coverage
- [ ] Unit test for validation function
- [ ] Integration test for registration endpoint
- [ ] Integration test for password change endpoint
- [ ] UI test for error message display

### Test cases
- [ ] Password exactly 11 characters → rejected
- [ ] Password exactly 12 characters → accepted
- [ ] Password 50+ characters → accepted
- [ ] Password with only spaces → rejected
- [ ] Unicode password → handled correctly

### Verification date
Last verified: [Date]
Verified by: [Name]
Evidence: [Link to test run]

Periodic verification

Security requirements can regress. Schedule regular checks:

Weekly (automated):

CI/CD security scans
Dependency vulnerability checks
Security header verification

Monthly (Security Champion):

Review new features for security requirement coverage
Check for requirement drift
Update requirement status

Quarterly (team review):

Full ASVS baseline review
Verify sample of "Verified" requirements still pass
Update excluded requirements list

Annually (external):

Penetration test against ASVS requirements
Compliance audit if applicable
Full requirements refresh

Workshop: set up security requirements tracking

Block 3-4 hours.

Part 1: Create your baseline (60 minutes)

Download ASVS 4.0.3 CSV from GitHub
Open in spreadsheet
For each requirement, mark:
- Applicable / Not Applicable
- Current Status
- Priority
Save as your project baseline

Deliverable: Spreadsheet with applicable requirements marked

Part 2: Set up tracking (45 minutes)

In Jira (or your issue tracker):

Create "Security Requirement" issue type
Add custom fields (ASVS ID, Status, Verification Method)
Create issues for top 20 priority requirements
Link to existing features where applicable

Deliverable: Tracking system configured, initial requirements entered

Part 3: Create verification tests (60 minutes)

Pick 5 requirements that are "Implemented" and write tests:

Write automated test
Add to test suite
Verify test catches violations
Update requirement status to "Verified"

Deliverable: 5 security requirements with automated tests

Part 4: Integrate into workflow (30 minutes)

Create feature planning checklist template
Add security review step to your PR template
Schedule monthly security requirements review
Document the process

Deliverable: Updated workflow documentation

Workshop checklist

ASVS baseline created
Tracking system set up
Top 20 requirements in tracker
At least 5 requirements have automated tests
Feature planning template includes security
PR template includes security review
Monthly review scheduled

Practical tips

Dealing with "Not Applicable" requirements

When marking a requirement as "Not Applicable", always document why:

## V12.1.1 - File Upload Validation

Status: Not Applicable

Justification: Application does not accept file uploads. 
Verified by: [Name]
Date: [Date]
Review trigger: If file upload feature is added, this requirement becomes applicable.

Review "Not Applicable" requirements quarterly — features change, and previously excluded requirements might now apply.

Making requirements visible

Slack/Teams integration:

Post weekly security requirements status
Alert on requirements stuck in "In Progress" for over 2 weeks
Celebrate when requirements move to "Verified"

Dashboard:

Create a simple dashboard showing:
- % of requirements verified
- Requirements by status
- Requirements by priority
- Time since last full review

Sprint reviews:

Include security requirements in sprint demos
Show which requirements were verified
Highlight any new requirements added

Handling legacy code

For existing applications without security requirements:

Don't try to fix everything at once — you'll get overwhelmed
Start with new features — apply requirements to new code
Address critical requirements first — V2.4 (password storage), V5.3 (XSS)
Use incidents as triggers — if you find a vulnerability, add the requirement and fix everywhere
Allocate 10-20% of sprint capacity — consistent progress beats heroic efforts

Requirements for third-party integrations

When adding external services, check their security:

## Third-Party Security Checklist

Service: [Name]
Purpose: [What it does]

### Data handling
- [ ] What data do we send to this service?
- [ ] Is data encrypted in transit? (V9.1.1)
- [ ] Is data encrypted at rest? (V8.3.1)
- [ ] Where is data stored geographically?
- [ ] What is their data retention policy?

### Authentication
- [ ] How do we authenticate to the service?
- [ ] API keys stored in Passwork (V6.4.1)
- [ ] Keys rotated periodically (V6.4.2)

### Security posture
- [ ] SOC 2 or equivalent certification?
- [ ] Security contact available?
- [ ] Vulnerability disclosure program?

### Incident response
- [ ] How will they notify us of breaches?
- [ ] What is their SLA for security issues?

Approved by: [Security Champion]
Date: [Date]
Review date: [Annual review]

Using Passwork for requirements management

Security requirements work generates a lot of sensitive artifacts — credentials, keys, reports, audit evidence. Keeping them scattered across Google Drive, email threads, and individual laptops is itself a security requirement failure.

Passwork is a business password and secrets manager that fits naturally into this workflow:

Store sensitive security artifacts:

API keys for security scanning tools (SAST, DAST, SCA) — with expiry tracking and audit log
Credentials for security testing and staging accounts
Access credentials for security dashboards and monitoring tools
Encryption keys for sensitive security data

Organize by access level. Create a dedicated vault for security tools with access limited to the Security Champion and relevant team leads. Passwork's granular permissions let you share specific items without exposing the entire vault — useful when a developer needs temporary access to a test account but not to production secrets.

Attach documentation. Passwork supports secure notes and file attachments, so penetration test reports, audit evidence, and requirement sign-offs can live alongside the credentials they relate to — not in a shared folder with broader access.

Track who accessed what. The audit log records every access, change, and export. If a security requirement involves demonstrating access control to an auditor, Passwork's logs are evidence you can export directly.

Rotate on offboarding. When a developer who had access to security tool credentials leaves, Passwork shows you exactly what they had access to — so you rotate the right credentials immediately, not weeks later when someone notices something's wrong.

Common mistakes

Mistake 1: All requirements, no prioritization

Trying to implement all ASVS requirements at once. Team gets overwhelmed, nothing gets done.

Fix: Start with Level 1 for critical features. Expand gradually. Some requirements matter more than others for your application.

Mistake 2: Requirements without verification

Requirements are documented but never tested. Status says "Implemented" based on someone's memory.

Fix: Every "Verified" status needs evidence — test results, review notes, or audit findings.

Mistake 3: Security after development

Security Champion reviews after the feature is built. Changes are expensive and rushed.

Fix: Include Security Champion in feature design. Add security requirements before coding starts.

Mistake 4: One-time exercise

Requirements baseline created, never updated. New features don't get requirements.

Fix: Requirements review is ongoing. Every feature gets security requirements. Monthly reviews.

Mistake 5: No developer involvement

Security team creates requirements. Developers don't know they exist.

Fix: Developers should help select and implement requirements. They should write security tests. Shared ownership.

Talking to leadership

If someone asks why you're spending time on security requirements:

"We're implementing a structured approach to security using OWASP ASVS — an industry-standard catalog of security requirements. Instead of hoping our code is secure, we're defining exactly what security means for our application and verifying it's implemented. This catches issues during development rather than in production, reduces the cost of security fixes, and gives us evidence for compliance and customer security questionnaires."

Short version: "We're defining security requirements upfront so we build it right the first time instead of fixing it later."

Self-check

Requirements baseline

Downloaded and reviewed OWASP ASVS
Identified applicable requirements for your project
Created baseline document with justifications
Prioritized requirements (critical, high, medium, low)

Tracking

Requirements tracked in issue system
Status workflow defined
Current status known for each requirement

Integration

Feature planning includes security requirements
Security Champion reviews features before development
PR template includes security checklist
Security requirements in definition of done

Verification

Automated tests for key requirements
Regular verification schedule
Evidence documented for verified requirements

Check off at least 10 of 13 items before moving on.

What's next

You have a framework for defining and tracking security requirements. Next chapter: secrets management — moving secrets out of code and into proper storage with rotation and access controls.

Why security requirements matter​

OWASP Application Security Verification Standard (ASVS)​

ASVS structure​

ASVS levels​

Example ASVS requirements​

OWASP Cheat Sheet Series​

Other OWASP resources​

ASVS and compliance frameworks​

ASVS tools and platforms​

Free tools​

Commercial platforms with ASVS support​

Selecting requirements for your project​

Quick start: essential requirements​

Prioritizing requirements by risk​

Step 1: Classify your application​

Step 2: Start with Level 1 essentials​

Step 3: Add feature-specific requirements​

Step 4: Document your baseline​

Threat modeling and requirements​

Simple threat modeling for features​

Quick threat modeling template​

Tracking requirements in your workflow​

Using Jira (or similar)​

Creating requirement tickets​

Linking requirements to features​

Specialized security requirements tools​

GRC and compliance platforms​

Threat modeling and requirements​

Security testing platforms​

Simple approaches for small teams​

Ready-to-use templates​

Customer security questionnaires​

Common questions and ASVS mapping​

Preparing for questionnaires​

Questionnaire response workflow​

Integrating into development workflow​

The Security Champion's role​

Feature planning checklist​

Adding security to user stories​

Security in CI/CD​

Tracking requirement coverage​

Testing security requirements​

Verification methods​

Writing security tests​

ASVS testing checklist​

Periodic verification​

Workshop: set up security requirements tracking​

Part 1: Create your baseline (60 minutes)​

Part 2: Set up tracking (45 minutes)​

Part 3: Create verification tests (60 minutes)​

Part 4: Integrate into workflow (30 minutes)​

Workshop checklist​

Practical tips​

Dealing with "Not Applicable" requirements​

Making requirements visible​

Handling legacy code​

Requirements for third-party integrations​

Using Passwork for requirements management​

Common mistakes​

Mistake 1: All requirements, no prioritization​

Mistake 2: Requirements without verification​

Mistake 3: Security after development​

Mistake 4: One-time exercise​

Mistake 5: No developer involvement​

Talking to leadership​

Self-check​

Requirements baseline​

Tracking​

Integration​

Verification​

What's next​

Why security requirements matter

OWASP Application Security Verification Standard (ASVS)

ASVS structure

ASVS levels

Example ASVS requirements

OWASP Cheat Sheet Series

Other OWASP resources

ASVS and compliance frameworks

ASVS tools and platforms

Free tools

Commercial platforms with ASVS support

Selecting requirements for your project

Quick start: essential requirements

Prioritizing requirements by risk

Step 1: Classify your application

Step 2: Start with Level 1 essentials

Step 3: Add feature-specific requirements

Step 4: Document your baseline

Threat modeling and requirements

Simple threat modeling for features

Quick threat modeling template

Tracking requirements in your workflow

Using Jira (or similar)

Creating requirement tickets

Linking requirements to features

Specialized security requirements tools

GRC and compliance platforms

Threat modeling and requirements

Security testing platforms

Simple approaches for small teams

Ready-to-use templates

Customer security questionnaires

Common questions and ASVS mapping

Preparing for questionnaires

Questionnaire response workflow

Integrating into development workflow

The Security Champion's role

Feature planning checklist

Adding security to user stories

Security in CI/CD

Tracking requirement coverage

Testing security requirements

Verification methods

Writing security tests

ASVS testing checklist

Periodic verification

Workshop: set up security requirements tracking

Part 1: Create your baseline (60 minutes)

Part 2: Set up tracking (45 minutes)

Part 3: Create verification tests (60 minutes)

Part 4: Integrate into workflow (30 minutes)

Workshop checklist

Practical tips

Dealing with "Not Applicable" requirements

Making requirements visible

Handling legacy code

Requirements for third-party integrations

Using Passwork for requirements management

Common mistakes

Mistake 1: All requirements, no prioritization

Mistake 2: Requirements without verification

Mistake 3: Security after development

Mistake 4: One-time exercise

Mistake 5: No developer involvement

Talking to leadership

Self-check

Requirements baseline

Tracking

Integration

Verification

What's next