Use this when you're working on a high-risk feature (auth, payments, user data, compliance) and want to systematically identify abuse scenarios, missing rate limits, data exposure risks, and auth gaps before engineering begins.
Origin: This skill operationalizes the attacker story framework Kate co-presented at SpringOne 2020 with Eleftheria Stein (VMware). Recording: https://www.youtube.com/watch?v=_RTmgkHp2_U
Related skills: Use
/threat-modelfor system-level threat analysis across an entire architecture (this skill focuses on individual features). Use/compliance-mapto map findings to compliance framework requirements. Use/incident-response-planto plan what happens when defenses fail.
Process
Step 1: Gather the feature
Ask the user to provide:
- The user story or feature description — what the feature does and for whom. Acceptance criteria if available.
- The domain — what area does this touch? (e.g., authentication, payments, user profile, admin tooling, data export)
- Compliance frameworks in scope (optional) — SOC 2, HIPAA, GDPR, PCI-DSS, ISO 27001. If provided, Step 4 will map attacker stories to relevant compliance controls.
- Organization security policies (optional) — any internal security policies or standards that apply.
If the domain doesn't seem high-risk (UI layout, marketing content, navigation), mention that security thinking is optional for low-risk features and ask if they want to proceed anyway.
Step 2: Write attacker stories
For each user story or feature, generate attacker stories using the format:
As a (malicious actor type), I want to (abuse action) so that (malicious goal).
Generate attacker stories for these threat categories as relevant:
| Category | What to consider |
|---|---|
| Unauthorized access | Can someone access this without proper authentication? Can they escalate privileges? |
| Data exposure | Does this feature reveal data it shouldn't? In error messages, URLs, logs, API responses? |
| Abuse at scale | What happens if someone hits this endpoint 10,000 times? Are there rate limits? |
| Input manipulation | Can malformed, oversized, or malicious input cause harm? (SQL injection, XSS, command injection) |
| State manipulation | Can someone tamper with request parameters, tokens, or session data to change outcomes? |
| Social engineering | Can this feature be used to phish, impersonate, or trick other users? |
| AI/automation poisoning | Can an attacker manipulate inputs to an AI system to skew its behavioral baselines, trigger false positives to mask real attacks, or exploit AI confidence to evade detection? |
Step 3: Derive security acceptance criteria
For each attacker story, generate specific acceptance criteria in Gherkin format that prevent the attack:
# Security: (threat category)
Given (attack setup)
When (attack action)
Then (defensive outcome — the attack is blocked/limited/logged)
Group the criteria by category.
Step 4: Generate the security review
Output in this format:
Security Review: (feature name)
Risk assessment
Domain: (e.g., Authentication) Risk level: High / Medium / Low Rationale: (why this risk level)
Attacker stories
1. (Attacker story title)
As a (malicious actor), I want to (action) so that (goal).
Impact: (what happens if this attack succeeds) Likelihood: High / Medium / Low
2. (Next attacker story) ...
Security acceptance criteria
Unauthorized access
Given (setup)
When (action)
Then (defensive outcome)
Abuse at scale
Given (setup)
When (action)
Then (defensive outcome)
(Continue for each relevant category)
Recommended mitigations
- (Specific technical mitigation — e.g., "Add rate limiting of 5 requests/minute per IP on the password reset endpoint")
- (Next mitigation)
What to monitor
- (Logging and alerting recommendations -- what should trigger an alert)
AI analysis readiness: For each monitoring signal above, note whether it is:
- Machine-analyzable -- structured log, consistent format, tagged with source identity, suitable for automated behavioral analysis (UEBA, anomaly detection)
- Human-review-only -- unstructured, requires manual interpretation, not suitable for automated baseline building
If the organization uses AI-powered security tools, signals marked "human-review-only" represent blind spots for automated threat detection. Flag these as candidates for log enrichment via /telemetry-readiness-audit.
Compliance implications (include when compliance frameworks are provided in Step 1)
| Attacker story | Framework | Control | Impact if exploited |
|---|---|---|---|
| (story title) | (e.g., SOC 2) | (e.g., CC6.1 - Logical access controls) | (e.g., Audit finding, potential certification risk) |
| (story title) | (e.g., GDPR) | (e.g., Art. 32 - Security of processing) | (e.g., Reportable breach, regulatory fine risk) |
For each attacker story, identify which compliance controls would be violated if the attack succeeds. This connects feature-level security work to organizational compliance posture. Use /compliance-map for a full framework mapping beyond individual features.
Step 5: Generate security test plan
Map each attacker story to concrete test scenarios in Gherkin format:
Security test plan
| Attacker story | Test scenario | Test type | Automated? |
|---|---|---|---|
| {{story_title}} | {{Gherkin scenario summary}} | Integration / E2e | Yes / Manual |
For each high-priority attacker story, the corresponding security AC from Step 3 becomes a test scenario. Feed these to /test-strategy to place them at the right test level, or to /api-test-plan for API-specific security testing.
Step 6: Integration
Ask the user:
- Want me to add these security criteria to the original story?
- Want me to generate test cases from the security criteria (using /tdd-tests)?
- Want me to feed the security test plan to
/api-test-planfor API endpoints? - Any attack vectors you want explored more deeply?
Output location
Present the security review as formatted text in the conversation. If the user asks, merge security acceptance criteria into the original story.
Example Output
Input
- Feature: "As a healthcare provider, I want to export a patient's full medical record as a PDF so that I can share it with referring specialists."
- Domain: Data export / patient health records
- Compliance frameworks: HIPAA, SOC 2 Type II
- Organization security policies: All PHI access must be logged to SIEM within 5 seconds; exports are limited to patients within the provider's active care panel
Output (abbreviated)
Security Review: Patient Medical Record PDF Export
Risk assessment
Domain: Data export — Protected Health Information (PHI) Risk level: High Rationale: Feature exposes full patient records in a portable, unencrypted format. A single misconfigured authorization check could result in mass PHI disclosure, HIPAA breach notification obligations, and OCR investigation. Export functionality is a frequent target for insider abuse and credential compromise.
Attacker stories
1. Unauthorized cross-patient record access
As a curious or malicious provider, I want to modify the patient ID parameter in the export request so that I can download records for patients outside my care panel.
Impact: Bulk PHI exfiltration; HIPAA breach affecting thousands of patients Likelihood: High
2. Credential-compromised bulk export
As an external attacker with a stolen provider session token, I want to script repeated export requests across sequential patient IDs so that I can harvest a large volume of patient records before the session expires.
Impact: Mass data breach; regulatory penalties; reputational damage Likelihood: Medium
3. Export link interception
As a network attacker or malicious intermediary, I want to intercept or reuse the generated PDF download URL so that I can retrieve a patient record without authenticating as the provider.
Impact: PHI exposure to unauthorized party; breach notification trigger Likelihood: Medium
4. Audit log suppression via error flooding
As a malicious insider, I want to generate a high volume of export errors to flood the SIEM so that my actual unauthorized exports are buried and go unreviewed.
Impact: Compliance failure; attacker evades detection during active exfiltration Likelihood: Low
5. PDF metadata leakage
As a passive attacker receiving a forwarded PDF, I want to inspect PDF metadata fields so that I can harvest internal system details (server name, author field, software version) to aid further attacks.
Impact: Infrastructure reconnaissance; increases likelihood of targeted follow-on attack Likelihood: Medium
Security acceptance criteria
Unauthorized access
# Security: Cross-patient authorization bypass
Given a provider is authenticated with an active session
And patient ID "P-00291" is NOT in the provider's active care panel
When the provider requests a PDF export for patient ID "P-00291"
Then the system returns HTTP 403
And the response contains no patient data
And a WARN-level access-denied event is written to the SIEM within 5 seconds
Abuse at scale
# Security: Bulk scripted export
Given a provider session token is active
When more than 10 PDF export requests are made within a 60-second window from the same session
Then subsequent requests are rate-limited with HTTP 429
And the session is flagged for anomaly review
And a HIGH-severity alert fires in the SIEM
State manipulation
# Security: Pre-signed URL reuse
Given a PDF export has been generated and a download URL issued
When the same download URL is accessed a second time
Or the URL is accessed more than 15 minutes after issuance
Then the system returns HTTP 410 (Gone)
And no file content is returned
Data exposure
# Security: PDF metadata leakage
Given a PDF export is generated for any patient record
When the file is inspected for document metadata
Then the Author, Creator, and Producer fields contain no internal hostnames, usernames, or software version strings
Recommended mitigations
- Enforce care-panel scoping at the data layer — authorization checks must join against the provider's active care panel in the database query, not in application logic alone. IDOR prevention requires server-side enforcement.
- Issue single-use, time-limited pre-signed URLs for PDF downloads (15-minute TTL, one-use token). Do not return the PDF as a direct HTTP response body.
- Rate limit export endpoint to 10 requests per session per 60 seconds; apply a secondary limit of 50 requests per provider per 24-hour period.
- Strip PDF metadata at generation time — use a post-processing step (e.g., ExifTool or iText metadata clearing) before serving the file.
- Emit structured, tamper-evident audit log entries for every export attempt (success and failure) including: provider ID, patient ID, timestamp, IP, outcome, and session ID. Forward to SIEM within SLA.
- Alert on anomalous export volume — define a behavioral baseline per provider role; alert when daily export count exceeds 2 standard deviations above the 30-day rolling mean.
What to monitor
| Signal | Description | AI Analysis Readiness |
|---|---|---|
| Export attempts for out-of-panel patients | WARN event per attempt, tagged with provider ID + patient ID | Machine-analyzable — structured, consistent schema, suitable for UEBA |
| Rate limit triggers | HTTP 429 events with session and IP | Machine-analyzable — structured log, automatable threshold alerting |
| Bulk export volume per provider per day | Aggregate count by provider ID | Machine-analyzable — quantitative signal, baseline-ready for anomaly detection |
| Download URL reuse attempts | HTTP 410 events with token ID | Machine-analyzable — structured, tagged |
| PDF metadata content inspection failures | Logged at PDF generation pipeline | Human-review-only — output varies by generation library; requires manual audit until log schema is standardized. ⚠️ Flag for /telemetry-readiness-audit |
| SIEM log delivery latency (>5s SLA breach) | Infrastructure-level monitoring gap | Human-review-only — requires correlation across infra and app layers; not yet suitable for automated detection |
Compliance implications
| Attacker story | Framework | Control | Impact if exploited |
|---|---|---|---|
| Cross-patient record access | HIPAA | §164.312(a)(1) — Access control; Minimum Necessary standard | Reportable breach; OCR investigation; potential civil monetary penalty |
| Cross-patient record access | SOC 2 | CC6.3 — Role-based access control | Audit finding; certification risk at next assessment |
| Bulk scripted export | HIPAA | §164.312(b) — Audit controls | Breach notification obligation if >500 patients affected |
| Bulk scripted export | SOC 2 | CC7.2 — Anomaly and threat detection | Control deficiency finding |
| Export URL interception | HIPAA | §164.312(e)(1) — Transmission security | Reportable disclosure to unauthorized party |
| Audit log suppression | HIPAA | §164.312(b) — Audit controls | Demonstrates lack of reasonable safeguards; aggravating factor in enforcement |
| PDF metadata leakage | SOC 2 | CC6.1 — Logical access and data classification | Informational finding; escalates if leads to further compromise |
Security test plan
| Attacker story | Test scenario | Test type | Automated? |
|---|---|---|---|
| Cross-patient record access | Provider requests export with out-of-panel patient ID → expect 403 + SIEM event | Integration | Yes |
| Bulk scripted export | 11 sequential export requests within 60s → expect 429 on request 11 | Integration | Yes |
| Export URL reuse | Reuse download URL after first access → expect 410 | E2E | Yes |
| Export URL expiry | Access download URL after 16 minutes → expect 410 | Integration | Yes |
| PDF metadata leakage | Parse generated PDF metadata fields → assert no internal identifiers present | Integration | Yes |
| Audit log suppression via error flooding | Generate 500 4xx errors; verify legit export still appears in SIEM within SLA | E2E | Manual |
Next steps — want me to:
- Merge these security criteria into the original provider story?
- Generate