bps-kit 1.0.1 → 1.0.3

package/templates/vault/007/references/incident-playbooks.md

@@ -1,394 +0,0 @@
-# Incident Response Playbooks
-
-> Extended playbooks for common security incidents.
-> Each follows 5 phases: Contain, Assess, Remediate, Prevent, Document.
-> Use with `007 incident` or when responding to any security event.
-
----
-
-## Playbook 1: Data Breach
-
-**Severity:** CRITICAL
-**Response Time:** Immediate (< 15 minutes to begin containment)
-
-### Phase 1: Contain
-- [ ] Identify the source of the breach (compromised credential, vulnerability, insider)
-- [ ] Revoke compromised credentials immediately (API keys, tokens, passwords)
-- [ ] Isolate affected systems from the network
-- [ ] Block the attacker's IP/access path if identifiable
-- [ ] Preserve forensic evidence (do NOT wipe or restart affected systems yet)
-
-### Phase 2: Assess
-- [ ] Determine what data was exposed (PII, financial, credentials, business data)
-- [ ] Determine scope: how many users/records affected
-- [ ] Identify the attack timeline (when it started, when it was detected)
-- [ ] Review access logs to trace the attacker's actions
-- [ ] Assess if data was exfiltrated or only accessed
-
-### Phase 3: Remediate
-- [ ] Patch the vulnerability that was exploited
-- [ ] Force password reset for all affected users
-- [ ] Rotate all potentially compromised secrets (API keys, DB passwords, certificates)
-- [ ] Clean malware/backdoors if installed
-- [ ] Restore from clean backups if data was tampered with
-
-### Phase 4: Prevent
-- [ ] Implement missing access controls identified during the breach
-- [ ] Add monitoring for the attack pattern used
-- [ ] Enable encryption at rest for exposed data stores
-- [ ] Implement DLP (Data Loss Prevention) rules
-- [ ] Review and restrict access permissions (least privilege)
-
-### Phase 5: Document
-- [ ] Complete incident timeline with timestamps
-- [ ] Root cause analysis (RCA)
-- [ ] List of all affected systems and data
-- [ ] Actions taken and by whom
-- [ ] Regulatory notifications (LGPD: 72 hours, GDPR: 72 hours)
-- [ ] User notification if PII was exposed
-- [ ] Lessons learned and process improvements
-
-### Communication Template
-```
-SUBJECT: [CRITICAL] Security Incident - Data Breach Detected
-
-STATUS: Active incident as of {timestamp}
-SEVERITY: CRITICAL
-INCIDENT ID: INC-{YYYY}-{NNN}
-
-SUMMARY:
-A data breach affecting {scope} has been detected. The breach involves
-{type of data} from {source system}.
-
-CURRENT ACTIONS:
-- Compromised access has been revoked
-- Affected systems are isolated
-- Investigation is in progress
-
-AFFECTED DATA:
-- Type: {PII / financial / credentials / business}
-- Records: {approximate count}
-- Users: {approximate count}
-
-NEXT STEPS:
-- Complete forensic analysis by {ETA}
-- Regulatory notification by {deadline}
-- User communication by {deadline}
-
-CONTACT: {incident commander} at {contact info}
-```
-
----
-
-## Playbook 2: DDoS / DoS
-
-**Severity:** HIGH
-**Response Time:** < 5 minutes to begin mitigation
-
-### Phase 1: Contain
-- [ ] Confirm it is an attack (not a legitimate traffic spike)
-- [ ] Activate CDN/WAF DDoS protection (Cloudflare Under Attack Mode, AWS Shield, etc.)
-- [ ] Enable rate limiting emergency mode (aggressive thresholds)
-- [ ] Block obvious attack source IPs/ranges at the edge
-- [ ] Scale infrastructure if possible (auto-scaling groups)
-- [ ] Enable geo-blocking if attack originates from specific regions
-
-### Phase 2: Assess
-- [ ] Identify attack type (volumetric, protocol, application layer)
-- [ ] Identify attack source patterns (IP ranges, user agents, request patterns)
-- [ ] Measure impact on service availability and user experience
-- [ ] Check if DDoS is a distraction for another attack (data breach, etc.)
-- [ ] Review resource utilization (CPU, memory, bandwidth, connections)
-
-### Phase 3: Remediate
-- [ ] Implement targeted blocking rules based on attack patterns
-- [ ] Optimize application to handle increased load (caching, static responses)
-- [ ] Contact ISP/hosting provider for upstream filtering if needed
-- [ ] Move critical services behind additional protection layers
-- [ ] Gradually relax emergency protections as attack subsides
-
-### Phase 4: Prevent
-- [ ] Implement permanent rate limiting with appropriate thresholds
-- [ ] Deploy CDN with DDoS protection for all public endpoints
-- [ ] Set up auto-scaling with cost limits
-- [ ] Create runbooks for common DDoS patterns
-- [ ] Implement challenge-based protection (CAPTCHA) for sensitive endpoints
-
-### Phase 5: Document
-- [ ] Attack timeline, peak traffic volume, duration
-- [ ] Attack type and source characteristics
-- [ ] Service impact (downtime, degraded performance, affected users)
-- [ ] Mitigation actions and effectiveness
-- [ ] Cost impact (infrastructure, lost revenue)
-- [ ] Recommendations for improved resilience
-
----
-
-## Playbook 3: Ransomware
-
-**Severity:** CRITICAL
-**Response Time:** Immediate (< 10 minutes to isolate)
-
-### Phase 1: Contain
-- [ ] IMMEDIATELY disconnect affected systems from network (pull cable, disable WiFi)
-- [ ] Do NOT power off systems (preserves forensic evidence in memory)
-- [ ] Identify patient zero (first infected system)
-- [ ] Block lateral movement (disable SMB, RDP between segments)
-- [ ] Isolate backup systems to prevent encryption
-- [ ] Alert all employees to disconnect suspicious systems
-
-### Phase 2: Assess
-- [ ] Identify the ransomware variant (check ransom note, file extensions)
-- [ ] Determine scope: which systems and data are encrypted
-- [ ] Check if backups are intact and uncompromised
-- [ ] Assess if data was exfiltrated before encryption (double extortion)
-- [ ] Check for decryption tools (NoMoreRansom.org)
-- [ ] Determine entry point (phishing email, RDP brute force, vulnerable software)
-
-### Phase 3: Remediate
-- [ ] If clean backups exist: wipe and restore from backup
-- [ ] If no backups: evaluate decryption options (public tools, negotiation as last resort)
-- [ ] Patch the vulnerability that was exploited
-- [ ] Remove all persistence mechanisms (scheduled tasks, registry keys, services)
-- [ ] Scan all systems for remaining malware before reconnecting
-- [ ] Change ALL passwords (domain admin first, then all users)
-
-### Phase 4: Prevent
-- [ ] Implement network segmentation
-- [ ] Deploy EDR (Endpoint Detection and Response) on all systems
-- [ ] Disable SMB v1, restrict RDP access
-- [ ] Implement 3-2-1 backup strategy (3 copies, 2 media types, 1 offsite)
-- [ ] Air-gapped or immutable backup storage
-- [ ] Regular backup restoration tests
-- [ ] Employee phishing awareness training
-
-### Phase 5: Document
-- [ ] Complete attack timeline
-- [ ] Entry point and propagation method
-- [ ] Data impact (encrypted, exfiltrated, lost)
-- [ ] Recovery method and time to recovery
-- [ ] Financial impact (ransom demand, downtime cost, recovery cost)
-- [ ] Law enforcement report (recommended)
-
----
-
-## Playbook 4: Supply Chain Compromise
-
-**Severity:** CRITICAL
-**Response Time:** < 30 minutes to assess, < 2 hours to contain
-
-### Phase 1: Contain
-- [ ] Identify the compromised dependency/package/vendor
-- [ ] Pin to last known good version immediately
-- [ ] Block outbound connections from affected systems to unknown IPs
-- [ ] Audit all systems using the compromised component
-- [ ] Halt all deployments until assessment is complete
-- [ ] Check if compromised code was executed in production
-
-### Phase 2: Assess
-- [ ] Determine what the malicious code does (data exfiltration, backdoor, crypto-miner)
-- [ ] Identify affected versions and timeline of compromise
-- [ ] Check package manager advisories (npm, PyPI, Maven security advisories)
-- [ ] Review build logs for when compromised version was first introduced
-- [ ] Scan all artifacts built with the compromised dependency
-- [ ] Check if secrets/credentials were exposed to the malicious code
-
-### Phase 3: Remediate
-- [ ] Update to patched version or remove dependency
-- [ ] Rotate all secrets that could have been accessed
-- [ ] Rebuild and redeploy all affected services from clean sources
-- [ ] Scan all systems for backdoors or persistence mechanisms
-- [ ] Audit build pipeline for additional compromises
-
-### Phase 4: Prevent
-- [ ] Implement dependency pinning with lock files
-- [ ] Enable integrity checking (checksums, signatures)
-- [ ] Set up automated vulnerability scanning (Dependabot, Snyk, pip-audit)
-- [ ] Use private package registries with approved packages
-- [ ] Implement SBOM (Software Bill of Materials)
-- [ ] Code review for dependency updates
-- [ ] Monitor for typosquatting attacks on your dependencies
-
-### Phase 5: Document
-- [ ] Compromised component, versions, and timeline
-- [ ] Impact assessment (systems affected, data exposed)
-- [ ] Detection method (how was it discovered)
-- [ ] Remediation actions and verification
-- [ ] Supply chain security improvements implemented
-
----
-
-## Playbook 5: Insider Threat
-
-**Severity:** HIGH to CRITICAL
-**Response Time:** < 1 hour (balance speed with discretion)
-
-### Phase 1: Contain
-- [ ] Do NOT alert the suspected insider yet
-- [ ] Engage HR and legal before technical actions
-- [ ] Increase monitoring on the suspected account (audit logging)
-- [ ] Restrict access to most sensitive systems without raising suspicion
-- [ ] Preserve all evidence (logs, emails, file access records)
-- [ ] Secure backup copies of evidence
-
-### Phase 2: Assess
-- [ ] Review access logs for unusual patterns (off-hours access, bulk downloads)
-- [ ] Check for unauthorized data transfers (USB, email, cloud storage)
-- [ ] Review code changes for backdoors or unauthorized modifications
-- [ ] Assess what data/systems the insider has access to
-- [ ] Determine if the threat is malicious or negligent
-- [ ] Involve digital forensics if warranted
-
-### Phase 3: Remediate
-- [ ] Coordinate with HR/legal for appropriate action
-- [ ] Revoke all access immediately when action is taken
-- [ ] Change shared credentials the insider had access to
-- [ ] Review and revoke any API keys/tokens created by the insider
-- [ ] Audit code changes made by the insider in the last N months
-- [ ] Check for scheduled tasks, cron jobs, or time bombs
-
-### Phase 4: Prevent
-- [ ] Implement Data Loss Prevention (DLP) tools
-- [ ] Enforce least-privilege access across the organization
-- [ ] Regular access reviews (quarterly minimum)
-- [ ] Implement user behavior analytics (UBA)
-- [ ] Offboarding checklist with comprehensive access revocation
-- [ ] Background checks for roles with sensitive access
-
-### Phase 5: Document
-- [ ] Complete timeline of insider actions
-- [ ] Data/systems accessed or compromised
-- [ ] Evidence collected and chain of custody
-- [ ] HR/legal actions taken
-- [ ] Access control improvements implemented
-
----
-
-## Playbook 6: Credential Stuffing
-
-**Severity:** HIGH
-**Response Time:** < 30 minutes to begin mitigation
-
-### Phase 1: Contain
-- [ ] Detect the attack (spike in failed logins, multiple accounts from same IPs)
-- [ ] Enable aggressive rate limiting on login endpoints
-- [ ] Block attacking IP ranges at WAF/CDN level
-- [ ] Enable CAPTCHA on login forms
-- [ ] Temporarily lock accounts with multiple failed attempts
-
-### Phase 2: Assess
-- [ ] Determine how many accounts were successfully compromised
-- [ ] Identify the source of credential lists (check haveibeenpwned.com)
-- [ ] Review compromised accounts for unauthorized actions
-- [ ] Check if attackers accessed sensitive data or made changes
-- [ ] Assess financial impact (fraudulent transactions, data access)
-
-### Phase 3: Remediate
-- [ ] Force password reset on all compromised accounts
-- [ ] Notify affected users with guidance to use unique passwords
-- [ ] Reverse any unauthorized actions (transactions, settings changes)
-- [ ] Block known compromised credential pairs
-- [ ] Invalidate all active sessions for affected accounts
-
-### Phase 4: Prevent
-- [ ] Implement MFA (multi-factor authentication), push to all users
-- [ ] Deploy credential stuffing detection (rate + pattern analysis)
-- [ ] Check passwords against breach databases on registration/change
-- [ ] Implement progressive delays on failed login attempts
-- [ ] Device fingerprinting and anomaly detection
-- [ ] Bot detection on authentication endpoints
-
-### Phase 5: Document
-- [ ] Attack timeline, volume, and success rate
-- [ ] Number of compromised accounts and impact
-- [ ] Source IP analysis
-- [ ] Detection method and time to detection
-- [ ] User communications sent
-- [ ] Authentication security improvements
-
----
-
-## Playbook 7: API Abuse
-
-**Severity:** MEDIUM to HIGH
-**Response Time:** < 1 hour
-
-### Phase 1: Contain
-- [ ] Identify the abusive client (API key, IP, user account)
-- [ ] Rate limit or throttle the abusive client specifically
-- [ ] If data scraping: block the client and return generic errors
-- [ ] If financial abuse: freeze the account pending review
-- [ ] Preserve request logs for analysis
-
-### Phase 2: Assess
-- [ ] Determine the type of abuse (scraping, brute force, fraud, free tier abuse)
-- [ ] Quantify the impact (cost, data exposed, service degradation)
-- [ ] Review if the abuse exploited a legitimate API or a vulnerability
-- [ ] Check ToS violations
-- [ ] Determine if automated (bot) or manual
-
-### Phase 3: Remediate
-- [ ] Revoke the abusive client's API keys
-- [ ] Block abusive patterns (specific endpoints, request signatures)
-- [ ] If vulnerability-based: patch the vulnerability
-- [ ] If scraping: implement anti-bot measures
-- [ ] If fraud: reverse fraudulent transactions, report to legal
-
-### Phase 4: Prevent
-- [ ] Implement per-client rate limiting with appropriate tiers
-- [ ] Add request cost tracking (weighted rate limiting for expensive endpoints)
-- [ ] Deploy bot detection (fingerprinting, behavior analysis)
-- [ ] Implement API usage quotas and billing
-- [ ] Add anomaly detection on API usage patterns
-- [ ] Review API design for abuse vectors (pagination, filtering, bulk endpoints)
-
-### Phase 5: Document
-- [ ] Abuse type, method, and timeline
-- [ ] Impact (financial, data, service)
-- [ ] Client identification and evidence
-- [ ] Actions taken (blocking, revocation)
-- [ ] API security improvements implemented
-
----
-
-## General Communication Template
-
-Use this template for any incident type:
-
-```
-SUBJECT: [{SEVERITY}] Security Incident - {Brief Description}
-
-STATUS: {Active / Contained / Resolved}
-SEVERITY: {CRITICAL / HIGH / MEDIUM / LOW}
-INCIDENT ID: INC-{YYYY}-{NNN}
-DETECTED: {timestamp}
-INCIDENT COMMANDER: {name}
-
-SUMMARY:
-{2-3 sentences describing what happened, what is affected, and current status.}
-
-IMPACT:
-- Systems: {affected systems}
-- Data: {type of data affected, approximate scope}
-- Users: {number of affected users}
-- Business: {business impact description}
-
-CURRENT STATUS:
-- Phase: {Contain / Assess / Remediate / Prevent / Document}
-- Actions completed: {list}
-- Actions in progress: {list}
-
-NEXT UPDATE: {timestamp for next status update}
-CONTACT: {incident commander contact}
-```
-
----
-
-## Severity Classification Reference
-
-| Severity | Examples | Response Time | Escalation |
-|----------|---------|---------------|------------|
-| **CRITICAL** | Data breach, ransomware, active exploitation | < 15 min | Immediate: CEO, CTO, Legal |
-| **HIGH** | DDoS, credential stuffing, supply chain compromise | < 30 min | Within 1 hour: CTO, Engineering Lead |
-| **MEDIUM** | API abuse, single account compromise, non-critical vuln exploited | < 2 hours | Within 4 hours: Engineering Lead |
-| **LOW** | Failed attack attempt, minor misconfiguration found | < 24 hours | Next business day: Team Lead |

package/templates/vault/007/references/owasp-checklists.md

@@ -1,76 +0,0 @@
-# OWASP Top 10 Checklists
-
-> Quick-reference checklists for the three most relevant OWASP Top 10 lists.
-> Use during code reviews, security audits, and threat modeling.
-
----
-
-## OWASP Web Application Top 10 (2021)
-
-| # | Vulnerability | Description | Detection Patterns | Fix |
-|---|--------------|-------------|-------------------|-----|
-| **A01** | **Broken Access Control** | Users can act outside their intended permissions. IDOR, missing authz checks, CORS misconfiguration. | `GET /admin` accessible without admin role; user A accesses user B data via ID manipulation; missing `@require_role` decorators. | Deny by default. Enforce server-side access control. Disable directory listing. Log access failures. Invalidate JWT/sessions on logout. |
-| **A02** | **Cryptographic Failures** | Sensitive data exposed due to weak or missing encryption. Cleartext storage/transmission. | Passwords stored as MD5/SHA1; HTTP endpoints serving sensitive data; hardcoded encryption keys; `TLS 1.0/1.1` in config. | HTTPS everywhere. TLS 1.2+ only. bcrypt/argon2 for passwords. Encrypt data at rest (AES-256). No sensitive data in URLs. |
-| **A03** | **Injection** | Untrusted data sent to interpreter without validation. SQL, NoSQL, OS command, LDAP injection. | String concatenation in queries: `f"SELECT * FROM users WHERE id={input}"`; `os.system(user_input)`; unsanitized template rendering. | Parameterized queries/prepared statements. ORM usage. Input validation (allowlist). Escape output. WAF as defense-in-depth. |
-| **A04** | **Insecure Design** | Missing or ineffective security controls at design level. Threat modeling not performed. | No rate limit on password reset; unlimited free trial creation; business logic allows negative quantities; no fraud detection. | Threat model during design. Secure design patterns. Unit/integration tests for abuse cases. Limit resource consumption by user. |
-| **A05** | **Security Misconfiguration** | Default configs, open cloud storage, unnecessary features enabled, verbose errors. | Default admin credentials; S3 bucket public; stack traces in production; unnecessary HTTP methods enabled; CORS `*`. | Hardened defaults. Remove unused features/frameworks. Automated config scanning. Different credentials per environment. |
-| **A06** | **Vulnerable Components** | Using libraries/frameworks with known vulnerabilities. Outdated dependencies. | `npm audit` / `pip-audit` findings; CVE matches in dependency tree; EOL runtime versions; unpatched OS packages. | Dependency scanning in CI/CD. Automated updates (Dependabot/Renovate). Remove unused dependencies. Monitor CVE databases. |
-| **A07** | **Auth Failures** | Broken authentication allows credential stuffing, brute force, session hijacking. | No rate limit on login; session ID in URL; no MFA option; weak password policy; session not invalidated on password change. | MFA. Rate limit login attempts. Secure session management. Strong password policy. Rotate session on privilege change. |
-| **A08** | **Software/Data Integrity** | Insecure CI/CD pipelines, unsigned updates, deserialization of untrusted data. | `pickle.loads(user_data)`; CDN scripts without SRI hashes; unsigned artifacts in pipeline; auto-merge without review. | SRI for external scripts. Signed artifacts. Review CI/CD pipeline security. Avoid deserializing untrusted data. Code review enforcement. |
-| **A09** | **Logging/Monitoring Failures** | Insufficient logging, missing alerts, no incident response capability. | No logs for login failures; logs without user context; no alerting on suspicious patterns; logs stored locally only. | Log all auth events, access failures, input validation failures. Centralized logging. Alert on anomalies. Retention policy. |
-| **A10** | **SSRF** | Server-side request forgery - application fetches attacker-controlled URL. | `fetch(user_provided_url)`; URL parameter for image processing; webhook URL without validation; DNS rebinding. | Allowlist for outbound URLs/IPs. Block private IP ranges (10.x, 172.16.x, 169.254.x). Disable HTTP redirects. Network segmentation. |
-
----
-
-## OWASP API Security Top 10 (2023)
-
-| # | Vulnerability | Description | Detection Patterns | Fix |
-|---|--------------|-------------|-------------------|-----|
-| **API1** | **Broken Object Level Authorization (BOLA)** | API exposes endpoints that handle object IDs, allowing attackers to access other users' objects. | `GET /api/v1/users/{id}/orders` without ownership check; sequential/predictable IDs; no authz middleware on data endpoints. | Check object ownership in every request. Use random UUIDs, not sequential IDs. Authorization middleware on all data endpoints. |
-| **API2** | **Broken Authentication** | Weak or missing authentication mechanisms on API endpoints. | API keys in URLs; no token expiration; missing auth on internal APIs exposed publicly; credentials in response bodies. | OAuth 2.0 / JWT with short expiry. API key rotation. Auth on ALL endpoints. Never expose credentials in responses. Rate limit auth endpoints. |
-| **API3** | **Broken Object Property Level Authorization** | API exposes all object properties, allowing mass assignment or excessive data exposure. | Response includes `password_hash`, `internal_id`, `is_admin`; PUT/PATCH accepts `role` field from user input. | Explicit response schemas (allowlist fields). Block mass assignment. Never auto-expose DB model. Separate read/write DTOs. |
-| **API4** | **Unrestricted Resource Consumption** | API doesn't limit requests, payload sizes, or resource usage, enabling DoS. | No pagination (`GET /users` returns all); unlimited file upload size; no rate limiting; expensive queries without timeout. | Rate limiting per user/IP. Pagination (max page size). Payload size limits. Query complexity limits. Timeouts on all operations. |
-| **API5** | **Broken Function Level Authorization** | Missing authorization checks on administrative or privileged API functions. | `DELETE /api/users/{id}` accessible to regular users; admin endpoints without role check; horizontal privilege escalation. | RBAC enforcement. Deny by default. Admin endpoints on separate route group with middleware. Regular authorization audits. |
-| **API6** | **Unrestricted Access to Sensitive Business Flows** | Automated abuse of legitimate business flows (scalping, spam, credential stuffing). | Automated account creation; bulk coupon redemption; scraping sensitive listings; no CAPTCHA on sensitive flows. | Rate limit business-critical flows. CAPTCHA/device fingerprinting. Anomaly detection. Business logic abuse monitoring. |
-| **API7** | **Server Side Request Forgery (SSRF)** | API fetches remote resources without validating user-supplied URLs. | `POST /api/import {"url": "http://169.254.169.254/"}` (AWS metadata); webhook URL to internal services. | URL allowlisting. Block internal IP ranges. Disable redirects. Validate URL scheme (https only). Network segmentation. |
-| **API8** | **Security Misconfiguration** | Missing security headers, permissive CORS, verbose errors, default credentials on API infrastructure. | `Access-Control-Allow-Origin: *`; detailed error messages with stack traces; default API gateway credentials; TLS 1.0 enabled. | Hardened configs. Restrictive CORS. Generic error responses. Security headers. Regular config audits. |
-| **API9** | **Improper Inventory Management** | Deprecated/unpatched API versions still accessible. Shadow APIs. Undocumented endpoints. | `/api/v1/` still active alongside `/api/v3/`; internal debug endpoints exposed; undocumented admin API; no API gateway. | API inventory/catalog. Deprecate and remove old versions. API gateway as single entry point. OpenAPI spec as source of truth. |
-| **API10** | **Unsafe Consumption of APIs** | API trusts data from third-party APIs without validation, inheriting their vulnerabilities. | Blindly trusting webhook payloads; no validation on third-party API responses; following redirects from external APIs. | Validate ALL external API responses. Timeout and circuit breakers. Don't trust third-party data more than user input. TLS for all external calls. |
-
----
-
-## OWASP LLM Top 10 (2025)
-
-| # | Vulnerability | Description | Detection Patterns | Fix |
-|---|--------------|-------------|-------------------|-----|
-| **LLM01** | **Prompt Injection** | Attacker manipulates LLM via crafted input (direct) or poisoned context (indirect). | User input contains "ignore previous instructions"; external documents with hidden instructions; unexpected tool calls after processing user content. | Input sanitization. Separate system/user prompts clearly. Output validation. Human-in-the-loop for sensitive actions. Context isolation. |
-| **LLM02** | **Sensitive Information Disclosure** | LLM reveals confidential data from training data, system prompts, or context. | Model outputs API keys, internal URLs, PII; system prompt extraction via "repeat your instructions"; context leakage between users. | Strip secrets from context. Output filtering for PII/secrets. Session isolation. Don't put secrets in system prompts. Anonymize training data. |
-| **LLM03** | **Supply Chain Vulnerabilities** | Compromised training data, model weights, plugins, or dependencies. | Poisoned fine-tuning datasets; malicious third-party plugins; tampered model files; compromised prompt templates. | Verify model integrity (checksums). Audit plugins/tools. Signed artifacts. Scan training data. Vendor security assessment. |
-| **LLM04** | **Data and Model Poisoning** | Attacker corrupts training/fine-tuning data to influence model behavior. | Biased outputs after fine-tuning; backdoor triggers in model responses; degraded performance on specific topics. | Data validation pipeline. Anomaly detection on training data. Multiple data sources. Regular model evaluation. Federated learning safeguards. |
-| **LLM05** | **Improper Output Handling** | LLM output passed to downstream systems without sanitization, enabling XSS, injection, RCE. | LLM output rendered as HTML without escaping; LLM-generated SQL executed directly; LLM output used in system commands. | Treat LLM output as untrusted. Sanitize before rendering. Parameterized queries for LLM-generated SQL. Never pass LLM output to `eval()` or shell. |
-| **LLM06** | **Excessive Agency** | LLM agent has too many permissions, can perform destructive actions without human approval. | Agent can delete files, send emails, modify databases without confirmation; no scope limits on tool access; no approval workflow. | Least-privilege tool access. Human-in-the-loop for destructive actions. Read-only by default. Scope limits per session. Action audit logs. |
-| **LLM07** | **System Prompt Leakage** | Attacker extracts the system prompt, revealing business logic, guardrails, and instructions. | Prompts like "what are your instructions?"; indirect extraction via role-play; iterative probing to reconstruct system prompt. | Don't rely on system prompt secrecy for security. Defense in depth. Monitor for extraction attempts. Separate config from prompts. |
-| **LLM08** | **Vector and Embedding Weaknesses** | Manipulation of RAG retrieval through poisoned embeddings or adversarial documents. | Irrelevant documents surfacing in RAG results; poisoned knowledge base entries; embedding collision attacks. | Validate RAG sources. Access control on knowledge base. Embedding anomaly detection. Source attribution in responses. Regular KB audits. |
-| **LLM09** | **Misinformation** | LLM generates false/misleading content (hallucinations) presented as fact. | Confident assertions about nonexistent APIs; fabricated citations; incorrect code that looks plausible; made-up statistics. | Grounding with verified sources (RAG). Confidence scoring. Fact-checking pipeline. Disclaimers on generated content. Human review for critical outputs. |
-| **LLM10** | **Unbounded Consumption** | Excessive resource usage through crafted prompts, leading to cost explosion or denial of service. | Extremely long context inputs; recursive agent loops; prompt that triggers maximum token generation; no budget limits. | Token limits per request/session. Budget caps per user. Iteration limits for agents. Timeout on generation. Monitor cost anomalies. |
-
----
-
-## Quick Audit Checklist
-
-Use this as a rapid assessment during code reviews:
-
-```
-[ ] Authentication on all endpoints (A07/API2)
-[ ] Authorization checks on every data access (A01/API1/API5)
-[ ] Input validation and parameterized queries (A03)
-[ ] No sensitive data in logs or error messages (A09/API8)
-[ ] Dependencies up to date, no known CVEs (A06)
-[ ] Rate limiting on all public endpoints (API4)
-[ ] HTTPS everywhere, TLS 1.2+ (A02)
-[ ] Security headers set (CSP, HSTS, X-Frame-Options) (A05)
-[ ] LLM output treated as untrusted (LLM05)
-[ ] Agent tool access follows least privilege (LLM06)
-[ ] Prompt injection defenses in place (LLM01)
-[ ] Token/cost budgets configured (LLM10)
-```