2.1 — Security Requirements Engineering

Figure: Design & Architecture Overview — Track 2 coverage of security requirements, threat modeling, and secure design

1. Why Security Requirements Matter

The Cost Multiplier

Every defect has a discovery cost curve. Research from NIST, IBM Systems Sciences Institute, and decades of software engineering practice converge on the same conclusion: the cost of fixing a defect increases by 10-100x for each phase it escapes through. A missing authentication requirement caught during requirements review costs a conversation. The same gap discovered in production costs an incident response, a patch cycle, potential regulatory notification, and reputational damage.

Security requirements sit at the origin of this cost curve. They are the cheapest defect class to identify and the most expensive to miss.

CIS Control 16.1 — Establish and Maintain a Secure Application Development Process

CIS 16.1 mandates that organizations “establish and maintain a documented secure application development process” that addresses, among other things, security requirements as a foundational input. This is not optional guidance — it is a baseline control that auditors and assessors expect to see implemented with evidence.

CIS Control 16.10 — Apply Secure Design Principles in Application Architectures

CIS 16.10 requires that secure design principles — least privilege, complete mediation, never trusting user input, explicit error checking, and attack surface minimization — are applied during design. But these principles cannot be applied to a design that lacks security requirements. Requirements are the specification that design implements. Without them, “secure design” becomes ad hoc opinion rather than traceable engineering.

The Requirements Gap in Practice

Most organizations do not have a security requirements problem. They have a security requirements absence problem. Functional requirements get written. Performance requirements get documented. Security requirements get assumed. The assumption typically sounds like “we’ll add security later” or “the framework handles that.” Neither statement survives contact with a real attacker.

---

2. Types of Security Requirements

Security requirements divide into two categories, both of which must be explicitly documented.

2.1 Functional Security Requirements

Functional security requirements describe what the system must do to enforce security policy. These are features — implementable, testable, demonstrable.

Category	Example Requirements
Authentication	The system shall support multi-factor authentication for all user accounts. The system shall lock accounts after 5 consecutive failed login attempts for 30 minutes. The system shall enforce minimum password length of 12 characters.
Access Control	The system shall enforce role-based access control (RBAC) with least-privilege defaults. No user shall access resources outside their assigned role without explicit elevation. Administrative functions shall require separate authentication.
Encryption	The system shall encrypt all data at rest using AES-256-GCM. The system shall enforce TLS 1.2 or higher for all data in transit. The system shall never store plaintext passwords.
Session Management	The system shall expire inactive sessions after 15 minutes. The system shall generate new session identifiers upon authentication. The system shall invalidate all sessions upon password change.
Input Validation	The system shall validate all input on the server side regardless of client-side validation. The system shall reject input exceeding defined length limits. The system shall encode all output to prevent injection attacks.
Audit Logging	The system shall log all authentication events (success and failure). The system shall log all authorization decisions. Logs shall be tamper-evident and retained for 90 days minimum.

2.2 Non-Functional Security Requirements

Non-functional security requirements describe how the system must behave under adversarial conditions. These are quality attributes — measurable, testable, but not features in the traditional sense.

Category	Example Requirements
Performance Under Attack	The system shall maintain 95% of normal response time under volumetric DDoS conditions up to 10 Gbps. Rate limiting shall activate before application-layer degradation occurs.
Availability	The system shall achieve 99.9% availability as measured monthly. Failover to secondary systems shall complete within 60 seconds. No single point of failure shall exist in the authentication path.
Resilience	The system shall continue operating in degraded mode if any single dependency fails. The system shall automatically recover from transient failures without manual intervention.
Compliance	The system shall meet PCI DSS v4.0 requirements for cardholder data handling. The system shall comply with GDPR Article 25 (Data Protection by Design).
Audit & Forensics	The system shall support forensic analysis by maintaining immutable audit logs. Log entries shall include timestamp, actor, action, resource, and result. Clock synchronization shall be maintained within 1 second across all system components.
Scalability Under Load	Authentication infrastructure shall scale horizontally to handle 10x normal peak load. Rate limiting shall not create a bottleneck that attackers can exploit as a denial-of-service vector.

Writing Testable Requirements

Every security requirement must be testable. The formulation matters. Compare:

• Bad: “The system shall be secure.” (Untestable. What does “secure” mean?)
• Bad: “The system should use strong encryption.” (Vague. “Should” is not “shall.” “Strong” is undefined.)
• Good: “The system shall encrypt all PII at rest using AES-256-GCM with keys stored in AWS KMS. Verification: Decrypt attempt with unauthorized key shall fail. Database inspection shall show no plaintext PII.”

The pattern is: The system shall [action] [object] [constraint]. Verification: [test method].

---

3. Security Requirements Elicitation Techniques

Standard requirements elicitation (interviews, workshops, document analysis) captures what the system should do for legitimate users. Security requirements elicitation captures what the system should do against illegitimate users. This requires different techniques.

3.1 Misuse Cases

Misuse cases are the inverse of use cases. Where a use case describes a legitimate actor achieving a legitimate goal, a misuse case describes a hostile actor achieving a hostile goal.

Standard Use Case: “Customer logs in to view account balance.” Misuse Case: “Attacker performs credential stuffing using breached password lists to gain unauthorized access to customer accounts.”

The misuse case drives security requirements:

• The system shall implement rate limiting on login endpoints (max 10 attempts per minute per IP).
• The system shall detect and block credential stuffing patterns using behavioral analysis.
• The system shall notify account holders of login attempts from unrecognized devices.

Process: For each use case, ask “What could go wrong? Who would want to abuse this? How would they do it?” Document the misuse case and derive requirements from it.

3.2 Abuse Cases

Abuse cases extend misuse cases by considering legitimate users abusing legitimate functionality for unintended purposes.

Example: A customer support representative has access to view customer records to resolve support tickets. The abuse case: “Support representative exports all customer records to a personal device for sale on the dark web.”

Derived requirements:

• The system shall log all bulk data access operations.
• The system shall alert on data export volumes exceeding threshold (e.g., more than 50 records in a session).
• The system shall enforce data loss prevention controls on all export functions.

3.3 Security User Stories

Security user stories follow the standard user story format but center on security outcomes.

Format: “As a [role], I want [security capability] so that [security benefit].”

Examples:

• “As a system administrator, I want to enforce MFA for all users so that compromised passwords alone cannot grant access.”
• “As a compliance officer, I want immutable audit logs so that I can demonstrate regulatory compliance during audits.”
• “As a customer, I want to be notified of suspicious login activity so that I can respond to account compromise quickly.”

3.4 Evil User Stories

Evil user stories adopt the attacker’s perspective explicitly.

Format: “As a [attacker type], I want to [attack action] so that [attacker goal].”

Examples:

• “As an external attacker, I want to inject SQL into the search field so that I can extract the user database.”
• “As a disgruntled employee, I want to escalate my privileges so that I can access payroll data for all employees.”
• “As a competitor, I want to scrape the pricing API so that I can undercut pricing in real time.”

Each evil user story generates one or more security requirements as countermeasures. The evil user story becomes the test case — if the attack succeeds, the requirement has not been met.

3.5 Structured Brainstorming with STRIDE

The STRIDE threat categories (covered in depth in Module 2.3) provide a systematic framework for elicitation. For each component of the system, ask:

• Spoofing: Can an attacker impersonate a legitimate user or component?
• Tampering: Can an attacker modify data in transit or at rest?
• Repudiation: Can a user deny performing an action?
• Information Disclosure: Can an attacker access data they should not see?
• Denial of Service: Can an attacker degrade or prevent legitimate use?
• Elevation of Privilege: Can an attacker gain higher access than authorized?

Each “yes” answer becomes a security requirement.

---

4. OWASP ASVS as a Requirements Standard

The OWASP Application Security Verification Standard (ASVS) provides a pre-built catalog of security requirements organized by security domain. Rather than inventing requirements from scratch, teams can adopt ASVS as their baseline and customize.

4.1 The Three Verification Levels

Level	Target	Threat Profile	Typical Use
L1 — Opportunistic	All applications	Automated attacks, opportunistic attackers	Minimum baseline. Applications with no sensitive data. Internal tools.
L2 — Standard	Most applications	Skilled motivated attackers, targeted attacks	Applications handling sensitive data, PII, financial transactions. Most commercial software.
L3 — Advanced	Critical applications	Nation-state level, advanced persistent threats	Healthcare, financial infrastructure, military, critical infrastructure.

4.2 ASVS Requirement Categories

ASVS v4.0 contains 14 chapters of requirements:

1. V1 — Architecture, Design, and Threat Modeling: Application architecture documentation, threat modeling requirements
2. V2 — Authentication: Password requirements, MFA, credential recovery, lookup secrets
3. V3 — Session Management: Session binding, timeout, token management
4. V4 — Access Control: General access control design, operation-level, data-level, field-level
5. V5 — Validation, Sanitization, and Encoding: Input validation, sanitization, output encoding
6. V6 — Stored Cryptography: Data classification, algorithms, random values
7. V7 — Error Handling and Logging: Log content, log processing, error handling
8. V8 — Data Protection: General data protection, client-side, sensitive private data
9. V9 — Communication: Client communication, server communication
10. V10 — Malicious Code: Code integrity, malicious code search, deployed application integrity
11. V11 — Business Logic: Business logic security
12. V12 — Files and Resources: File upload, file execution, file storage
13. V13 — API and Web Service: Generic web service, RESTful, SOAP, GraphQL
14. V14 — Configuration: Build, dependency, unintended security disclosure, HTTP security headers

4.3 Using ASVS in Practice

Step 1: Determine your verification level based on data sensitivity and threat profile. Step 2: Extract all requirements for that level from each ASVS chapter. Step 3: Customize — add domain-specific requirements, remove inapplicable ones (with documented rationale). Step 4: Map each requirement to your application components. Step 5: Integrate into your requirements management tool with traceability.

Example ASVS requirement at L2:

V2.1.1: Verify that user-set passwords are at least 12 characters in length. V2.1.2: Verify that passwords of at least 64 characters are permitted. V2.1.7: Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords.

These translate directly into implementation requirements with clear test criteria.

---

5. Bidirectional Traceability

5.1 What Traceability Means

Bidirectional traceability means every security requirement can be traced forward to the design decisions, code modules, tests, and deployment configurations that implement it, and every implementation artifact can be traced backward to the requirement that justifies it.

Requirement → Design Decision → Code Module → Test Case → Deployment Config
     ↑              ↑               ↑             ↑              ↑
     └──────────────┴───────────────┴─────────────┴──────────────┘
                    (backward traceability)

5.2 Why Traceability Matters

• Completeness verification: Can you prove every security requirement is implemented and tested?
• Impact analysis: When a requirement changes, what code and tests are affected?
• Audit evidence: Regulators and assessors want proof that controls are implemented, not just documented.
• Incident response: When a vulnerability is found, which requirements failed? Which tests missed it?
• Change management: When code changes, which requirements might be affected?

5.3 Traceability Matrix

A traceability matrix maps requirements to their downstream artifacts:

Req ID	Requirement	Design Ref	Code Module	Test Case	Deployment Config	Status
SR-001	MFA for all users	DD-014	auth/mfa.py	TC-041, TC-042	TOTP_ENABLED=true	Implemented
SR-002	AES-256-GCM at rest	DD-007	crypto/encrypt.py	TC-015	KMS_KEY_ID=xxx	Implemented
SR-003	Session timeout 15min	DD-022	session/manager.py	TC-033	SESSION_TTL=900	Implemented
SR-004	Rate limit login 10/min	DD-009	middleware/rate_limit.py	TC-055	RATE_LIMIT_LOGIN=10	In Review

5.4 Tools for Traceability

• Jira/Azure DevOps: Link security requirement tickets to design docs, code commits, and test cases.
• Requirements management tools: Doors, Helix RM, Jama Connect for formal traceability in regulated industries.
• Code annotations: Tags in code comments linking to requirement IDs (e.g., # Implements SR-001).
• Test tagging: Test frameworks support tagging tests with requirement IDs (e.g., @pytest.mark.requirement("SR-001")).

---

6. Using LLMs for Requirements Brainstorming

6.1 Where LLMs Excel

Large language models are breadth machines. They can quickly generate comprehensive initial lists of security requirements based on system descriptions. This is their strength: coverage and speed of initial ideation.

Effective prompt pattern:

You are a security requirements engineer. Given the following system description,
generate a comprehensive list of security requirements organized by ASVS category.
For each requirement, specify:
- Requirement ID
- Requirement text (using "shall" language)
- ASVS reference if applicable
- Verification method
- Priority (Critical/High/Medium/Low)

System description: [paste system description]

Focus areas: authentication, authorization, data protection, input validation,
cryptography, logging, session management, API security.

What you get: A broad initial list that covers common security requirements across multiple domains. This list would take a human security engineer 2-4 hours to produce manually. The LLM produces it in 30 seconds.

What you do with it: Use it as a starting point for human review, not as a finished artifact.

6.2 Practical Workflow

1. System description input: Provide the LLM with architecture diagrams (described textually), technology stack, data classification, user roles, and integration points.
2. Initial generation: LLM generates candidate requirements.
3. Expert review: Security engineer reviews each requirement for accuracy, relevance, completeness, and feasibility.
4. Gap analysis: Security engineer identifies requirements the LLM missed (domain-specific, regulatory, context-specific).
5. Refinement: Iterate with the LLM on specific areas identified as gaps.
6. Finalization: Human engineer finalizes, prioritizes, and approves.

6.3 Compliance Mapping

LLMs can rapidly map requirements to compliance frameworks (PCI DSS, HIPAA, SOC 2, GDPR). This cross-referencing task is tedious for humans but well-suited for LLMs, provided the output is validated. Feed the LLM your requirements list and the target framework, and it will produce a mapping matrix. Validate each mapping — LLMs sometimes map to the wrong control or miss nuances in control applicability.

---

7. Critical Risks of AI in Requirements Engineering

7.1 Hallucinated Requirements

LLMs generate text with high fluency and confidence regardless of factual accuracy. A hallucinated security requirement looks exactly like a legitimate one. There is no visual or syntactic signal that distinguishes a valid requirement from a fabricated one.

Example: An LLM might generate: “The system shall comply with NIST SP 800-204B Section 4.3.2 requirements for service mesh mutual authentication.” This sounds authoritative. But NIST SP 800-204B may not contain a Section 4.3.2, or that section may address something entirely different. The requirement reads as valid, passes casual review, and enters the requirements baseline unchallenged.

Mitigation: Every LLM-generated requirement that references a specific standard, section, or specification must be verified against the source document. No exceptions.

7.2 Cascading Failure from Hallucinated Facts

Security requirements flow downstream. A hallucinated requirement becomes a hallucinated design decision, then hallucinated code implementing a non-existent control, then a hallucinated test validating the non-existent control passes. The entire chain appears internally consistent — every artifact traces to its upstream source — but the foundation is fabricated.

This is the cascading hallucination problem. It is particularly dangerous because traceability (which normally provides assurance) actually reinforces the illusion of correctness.

Mitigation: Validation checkpoints at phase boundaries. Requirements are validated by humans before design begins. Design is validated before coding begins. Do not allow AI-generated content to propagate across phase boundaries without human verification.

7.3 Package Hallucinations (Slopsquatting)

When LLMs generate requirements that reference specific libraries, packages, or tools, they sometimes hallucinate package names that do not exist. Attackers have begun registering these hallucinated package names with malicious payloads — a supply chain attack vector known as slopsquatting.

Example: An LLM recommends using flask-security-enhanced for authentication in a Python application. No such package exists in PyPI. An attacker registers flask-security-enhanced on PyPI with credential-stealing code. A developer, following the AI-generated requirement, installs the malicious package.

Mitigation: Every package, library, or tool referenced in AI-generated requirements must be verified against the authoritative package registry. Pin to specific verified versions.

7.4 Domain Specificity Gaps

LLMs are trained on general web content. They perform well on common security requirements (OWASP Top 10-level threats) but poorly on domain-specific requirements:

• Healthcare: HIPAA-specific requirements for PHI handling, minimum necessary standard, de-identification standards
• Financial services: PCI DSS specific requirements, Regulation E dispute handling, SOX audit trail requirements
• Industrial control systems: IEC 62443 requirements, real-time constraints, safety-critical system requirements
• Government: FedRAMP requirements, FIPS 140-3 cryptographic module requirements, CMMC requirements

For domain-specific requirements, LLMs should be used only as a supplement to subject matter expertise, never as a replacement.

---

8. Human Validation Workflows

8.1 The Division of Labor

The most effective approach uses AI and humans for what each does best:

Task	Best Performer	Rationale
Initial requirements brainstorming	AI	Speed, breadth, coverage of known patterns
Gap identification across ASVS categories	AI	Systematic coverage of large taxonomies
Compliance framework mapping	AI (with validation)	Cross-referencing large documents
Domain-specific requirements	Human	Context, regulatory knowledge, business logic
Requirements validation	Human	Accuracy judgment, feasibility assessment
Requirements prioritization	Human	Business context, risk appetite, resource constraints
Conflict resolution between requirements	Human	Tradeoff judgment, stakeholder negotiation
Novel attack scenario identification	Human	Creative adversarial thinking, system-specific knowledge

8.2 Validation Checklist

For every AI-generated security requirement, the human validator checks:

• Accuracy: Is the requirement factually correct? Do referenced standards/sections exist?
• Relevance: Does the requirement apply to this specific system and its threat profile?
• Completeness: Is the requirement fully specified, or does it assume context the LLM hallucinated?
• Testability: Can this requirement be verified through testing or inspection?
• Feasibility: Can this requirement be implemented within project constraints?
• Non-conflict: Does this requirement conflict with any other requirement?
• Proportionality: Is the security control proportionate to the risk it mitigates?

8.3 Documenting AI vs Human Origin

For traceability and audit purposes, every requirement should carry an origin tag:

• ORIGIN: AI-GENERATED — Generated by LLM, awaiting human validation
• ORIGIN: AI-GENERATED, HUMAN-VALIDATED — Generated by LLM, validated and approved by named human
• ORIGIN: AI-ASSISTED — Human-written with AI assistance (e.g., AI suggested refinement)
• ORIGIN: HUMAN — Written entirely by human without AI assistance

This tagging supports audit requirements and enables measurement of AI contribution quality over time. If a class of AI-generated requirements consistently requires heavy modification, that signals an area where AI assistance is not cost-effective.

---

9. Requirements Management and Traceability

9.1 Requirements Management Process

1. Elicitation: Gather requirements using techniques from Section 3
2. Analysis: Validate requirements for accuracy, consistency, completeness, feasibility
3. Specification: Document requirements in standard format with unique IDs
4. Validation: Stakeholder review and approval
5. Management: Change control, versioning, impact analysis

9.2 Requirements Attributes

Each security requirement should carry these attributes:

Attribute	Description	Example
ID	Unique identifier	SR-042
Title	Short descriptive name	Session Timeout Enforcement
Description	Full requirement text	The system shall terminate…
Type	Functional / Non-functional	Functional
Source	Origin of requirement	OWASP ASVS V3.3.1
Origin	AI-generated / Human / AI-assisted	AI-GENERATED, HUMAN-VALIDATED
Priority	Critical / High / Medium / Low	High
ASVS Reference	Mapping to ASVS	V3.3.1
CIS Reference	Mapping to CIS Controls	16.10
Verification Method	How to test	Automated security test
Status	Draft / Approved / Implemented / Verified	Approved
Owner	Responsible individual	J. Smith
Version	Requirement version	1.2

9.3 Change Control

Security requirements must be under change control. Any modification requires:

• Impact analysis (what design, code, and tests are affected?)
• Security review (does the change weaken security posture?)
• Approval (by requirement owner and security lead)
• Downstream update (design, code, tests updated to match)
• Re-verification (tests re-run to confirm compliance)

---

10. Integration with Threat Modeling

Security requirements engineering and threat modeling (Module 2.3) are mutually reinforcing activities.

Requirements inform threat modeling: Security requirements define the security objectives that the threat model evaluates. If a requirement states “the system shall authenticate all API requests,” the threat model examines how authentication could be bypassed.

Threat modeling informs requirements: Threat modeling discovers threats that were not anticipated during requirements elicitation. Each unmitigated threat generates new security requirements.

Iteration: Requirements and threat models should be developed iteratively. Initial requirements feed the first threat model. Threat model findings generate new requirements. Updated requirements feed a refined threat model. This cycle stabilizes when all identified threats have corresponding requirements and mitigations.

---

11. Practical Examples

11.1 Web Application (E-Commerce)

Category	Example Requirements
Authentication	SR-001: MFA for all customer accounts. SR-002: Account lockout after 5 failures. SR-003: Breached password detection.
Payment	SR-010: PCI DSS v4.0 compliance for card handling. SR-011: Tokenization of stored card data. SR-012: 3D Secure for all transactions over $100.
Data Protection	SR-020: Encryption at rest for all PII (AES-256-GCM). SR-021: TLS 1.3 for all external communications. SR-022: Data masking in non-production environments.
Logging	SR-030: Log all authentication events. SR-031: Log all payment transactions. SR-032: Tamper-evident log storage with 1-year retention.

11.2 REST API (Internal Microservice)

Category	Example Requirements
Authentication	SR-101: mTLS between all services. SR-102: JWT validation on every request. SR-103: Token expiry maximum 15 minutes.
Authorization	SR-110: Scope-based access control per endpoint. SR-111: No implicit trust between services. SR-112: Service identity verification on every request.
Rate Limiting	SR-120: Per-client rate limiting (100 req/min default). SR-121: Adaptive rate limiting under load. SR-122: Circuit breaker pattern for downstream failures.
Input Validation	SR-130: Schema validation on all request bodies. SR-131: Maximum request size 1MB. SR-132: Content-type enforcement.

11.3 Mobile Application

Category	Example Requirements
Local Storage	SR-201: No sensitive data in local storage. SR-202: Biometric authentication for local data access. SR-203: Certificate pinning for all API endpoints.
Transport	SR-210: TLS 1.2+ with no fallback. SR-211: No data transmission over insecure networks without VPN.
Binary Protection	SR-220: Code obfuscation for release builds. SR-221: Root/jailbreak detection. SR-222: Tamper detection for application binary.

---

12. NIST SSDF Alignment

This module aligns with NIST Secure Software Development Framework (SSDF) practices:

• PW.1: Design Software to Meet Security Requirements and Mitigate Security Risks
  • PW.1.1: Use forms of risk modeling to identify and evaluate security risks
  • PW.1.2: Track and maintain security requirements
• PO.1: Define Security Requirements for Software Development
  • PO.1.1: Identify and document security requirements for the software
  • PO.1.2: Communicate requirements to all parties

---

Summary

Security requirements engineering is the foundation of the SSDLC. It is the activity with the highest leverage and the lowest cost. Every dollar spent on security requirements saves ten to a hundred dollars in downstream defect remediation.

Key takeaways:

1. Security requirements must be explicit, testable, and traceable — never assumed.
2. Use multiple elicitation techniques (misuse cases, abuse cases, evil user stories) to achieve breadth.
3. OWASP ASVS provides a pre-built, peer-reviewed requirements catalog — use it as your baseline.
4. Bidirectional traceability ensures every requirement is implemented, tested, and verifiable.
5. LLMs are excellent breadth tools for initial requirements generation but produce hallucinations that are difficult to detect.
6. Human validation is mandatory — every AI-generated requirement must be verified before it enters the requirements baseline.
7. Tag the origin of every requirement for audit trail integrity.
8. Requirements engineering and threat modeling are mutually reinforcing — iterate between them.

---

References

• OWASP Application Security Verification Standard (ASVS) v4.0
• OWASP Security Requirements Guide
• CIS Controls v8, Control 16 (Application Software Security)
• NIST SP 800-160 Vol. 1: Systems Security Engineering
• NIST Secure Software Development Framework (SSDF) v1.1
• IEEE 830-1998: Recommended Practice for Software Requirements Specifications
• Microsoft SDL Practice 2: Define and Update Security Requirements
• Sindre, G. and Opdahl, A.L. “Eliciting Security Requirements with Misuse Cases”

Study Guide

Key Takeaways

1. Security requirements are the highest-leverage SSDLC activity — Cost of fixing defects increases 10-100x per escaped phase; requirements sit at the origin of this cost curve.
2. Requirements must be explicit, testable, and traceable — The pattern is: “The system shall [action] [object] [constraint]. Verification: [test method].”
3. Multiple elicitation techniques are needed — Misuse cases, abuse cases, evil user stories, and STRIDE brainstorming each capture different threat perspectives.
4. OWASP ASVS provides a pre-built requirements catalog — Three levels (L1/L2/L3) across 14 chapters give a peer-reviewed baseline to customize.
5. Bidirectional traceability ensures completeness — Every requirement traces forward to implementation and backward from artifacts to justifying requirements.
6. LLMs are breadth tools, not depth tools — Excellent for initial brainstorming but produce hallucinations that propagate downstream (cascading hallucination problem).
7. Human validation is mandatory — Every AI-generated requirement must carry an origin tag and be verified before entering the requirements baseline.

Important Definitions

Term	Definition
Misuse Case	Describes a hostile actor achieving a hostile goal — the inverse of a use case
Abuse Case	Describes a legitimate user abusing legitimate functionality for unintended purposes
Evil User Story	User story from the attacker’s perspective: “As an attacker, I want to…”
OWASP ASVS	Application Security Verification Standard — pre-built security requirements catalog with three verification levels
Bidirectional Traceability	Every requirement traces forward to implementation and every artifact traces backward to its justifying requirement
Cascading Hallucination	A hallucinated requirement propagating into design, code, and tests — appearing consistent but built on a fabricated foundation
Slopsquatting	AI hallucinating non-existent package names that attackers then register with malicious code
Origin Tag	Metadata indicating whether a requirement is AI-generated, human-validated, AI-assisted, or purely human

Quick Reference

• Framework/Process: Five-step requirements management (Elicitation, Analysis, Specification, Validation, Management); ASVS three levels across 14 chapters; CIS 16.1 and 16.10 alignment
• Key Numbers: 10-100x cost multiplier per escaped phase; 14 ASVS chapters; L1 (all apps), L2 (sensitive data), L3 (critical/nation-state)
• Common Pitfalls: Assuming “the framework handles security”; writing untestable requirements (“the system shall be secure”); skipping human validation of AI-generated requirements; ignoring non-functional security requirements

Review Questions

1. What is the difference between a misuse case and an abuse case, and why do you need both?
2. How does the cascading hallucination problem make AI-assisted requirements engineering particularly dangerous?
3. Which tasks in the human-AI division of labor are best performed by humans, and why?
4. How do security requirements engineering and threat modeling reinforce each other iteratively?
5. Why must every AI-generated requirement that references a specific standard be verified against the source document?