{ "generated": "2026-10-09", "scope": "Published references, guided practice, browser labs and local projects.", "domains": [ { "key": "appsec", "name": "Application security" }, { "key": "supply-chain", "name": "Software supply chain" }, { "key": "runtime", "name": "Runtime, cloud & APIs" }, { "key": "identity-crypto", "name": "Identity & cryptography" }, { "key": "governance", "name": "Governance & frameworks" }, { "key": "ai-emerging", "name": "AI security" } ], "topics": [ { "searchText": "sql-injection-python Fix SQL injection in Python sqlite3 Bind query values separately from SQL syntax, then prove the fix preserves legitimate behavior and blocks an injection probe. Python sqlite3 SQL injection Prepared statements Fix a finding CWE-89 CWE-89 A05:2025 V1.2.4 CAPEC-66 WSTG-INPV-05 V1 Python sqlite3 SQLi parameterized queries Understand why a value becomes SQL syntax Run the vulnerable and repaired lookup Use the same binding in other drivers Interpret each result and strengthen the regression Handle identifiers, authorization and later reuse A real-world failure Extend the binding rule to variable-length filters", "key": "sql-injection-python", "domain": "appsec", "topic": "Fix SQL injection in Python sqlite3", "title": "Fix SQL injection in Python sqlite3", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/sql-injection-python-sqlite3/", "platforms": [ "Python / SQLite" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "SQL injection lab: Separate SQL structure from data with sqlite3", "path": "https://softwaresecurity.com/labs/sql-injection-sqlite/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "object-authorization Enforce authorization for every object action Authorize the authenticated subject, requested operation, and specific resource together; a valid login or unpredictable identifier is insufficient. Authorization API security BOLA IDOR Test an application CWE-639 CWE-862 A01:2025 API1:2023 V8.2.2 V8.3.1 V8.4.1 WSTG-ATHZ-04 V8 BOLA IDOR Turn a role label into a decision rule Place selection and permission on the same path Use a matrix that changes one fact at a time Keep authorization understandable during operation Enforce the rule with your framework, not around it A real-world failure Choose bulk and delegated-access semantics explicitly", "key": "object-authorization", "domain": "appsec", "topic": "Enforce authorization for every object action", "title": "Enforce authorization for every object action", "path": "https://softwaresecurity.com/domains/appsec/authorization/object-level-authorization/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "IDOR lab: Repair an invoice authorization bug", "path": "https://softwaresecurity.com/labs/authorization/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "secure-uploads Design a safer file-upload pipeline Treat upload receipt, content processing, storage, and later delivery as separate security decisions. File upload Input validation Secure a feature Web CWE-434 A06:2025 V5.2.1 V5.2.2 V5.2.6 V5.3.2 V5.4.1 WSTG-BUSL-08 WSTG-BUSL-09 V5 Specify what receiving a file is allowed to cause Make publication an explicit state transition Verify the entire lifecycle with explicit budgets Understand what re-encoding and scanning cannot prove A real-world failure Keep storage ownership and job ownership aligned", "key": "secure-uploads", "domain": "appsec", "topic": "Design a safer file-upload pipeline", "title": "Design a safer file-upload pipeline", "path": "https://softwaresecurity.com/domains/appsec/secure-features/secure-file-uploads/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Path traversal lab: Serve an uploaded file without path traversal", "path": "https://softwaresecurity.com/labs/path-traversal-python/" }, { "title": "File upload lab: Accept avatars without publishing pages", "path": "https://softwaresecurity.com/labs/file-upload/" } ], "projects": [ { "title": "Keep extracted files inside their boundary", "path": "https://softwaresecurity.com/labs/#project-archive-extraction", "download": "https://softwaresecurity.com/downloads/projects/archive-extraction-e31e8b17b78e9134.zip" }, { "title": "Convert untrusted documents in a locked-down container", "path": "https://softwaresecurity.com/labs/#project-document-conversion-sandbox", "download": "https://softwaresecurity.com/downloads/projects/document-conversion-sandbox-62d2ff3fa1f9ec09.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "webhook-verification Verify webhook deliveries before acting Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action. Webhooks HMAC Replay Secure a feature API security CWE-347 CWE-294 CWE-306 CWE-208 Verify the exact message the provider signed Separate authenticated receipt from a business effect Check the provider's exact signature scheme Diagnose signature, retry and rotation failures independently A real-world failure Handle event order without inventing a provider guarantee", "key": "webhook-verification", "domain": "appsec", "topic": "Verify webhook deliveries before acting", "title": "Verify webhook deliveries before acting", "path": "https://softwaresecurity.com/domains/appsec/secure-features/verify-webhook-deliveries/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Webhook signature and replay lab: Repair a webhook handler that pays twice", "path": "https://softwaresecurity.com/labs/webhooks/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "multitenant-threat-model Review tenant boundaries before implementation Trace tenant identity through requests, data stores, caches, jobs, and administration, then turn plausible isolation failures into tests. Threat modeling Multitenancy Architecture Review a design A06:2025 V8.4.1 Model one complete tenant-sensitive operation Trace identity, tenant and purpose across every hop Use STRIDE to find what the trace missed Convert threats into falsifiable statements Keep the model small enough to maintain A real-world failure Review support and tenant-switching exceptions as separate flows", "key": "multitenant-threat-model", "domain": "appsec", "topic": "Review tenant boundaries before implementation", "title": "Review tenant boundaries before implementation", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/multitenant-design-review/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "dependency-response Respond to an exploited or malicious dependency When a dependency vulnerability is being exploited, or a package version is malicious, triage gives way to incident response: find every running copy, contain it, patch and redeploy, hunt for exploitation, rotate secrets and close on deployed evidence. Dependencies Incident response Vulnerability response Respond to a vulnerability React2Shell CISA KEV CWE-1395 CWE-1104 A03:2025 V15.1.1 V15.1.2 V15.2.1 CVE-2025-55182 CVE-2025-66478 V15 malicious dependency When does a dependency finding become an incident? Hour one: find every running copy Contain the exposed copies first Patch every copy, then check for follow-up advisories Look for exploitation before you call it closed Rotate what the vulnerable process could read Tell customers what is and is not affected Close on deployed evidence and fix the gap that slowed you Where dependency incident responses go wrong", "key": "dependency-response", "domain": "appsec", "topic": "Respond to an exploited or malicious dependency", "title": "Respond to an exploited or malicious dependency", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/dependency-vulnerability-response/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "minimal-appsec-program Start a minimal AppSec program with owners, triggers and metrics Begin with ownership, a few risk-triggered activities, and evidence that findings are resolved; expand from demonstrated needs. AppSec program Secure SDLC Security metrics Build an AppSec program Where should a small program draw its boundary? What is the smallest operating loop? How do you record the program boundary as data? What should run at each delivery stage first? How does one finding move from report to closure? Which pilot metrics show that the loop works? How do you check ownership and review coverage automatically?", "key": "minimal-appsec-program", "domain": "governance", "topic": "Start a minimal AppSec program with owners, triggers and metrics", "title": "Start a minimal AppSec program with owners, triggers and metrics", "path": "https://softwaresecurity.com/frameworks/appsec-program/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ci-build-integrity Protect the path from pull request to release Separate untrusted contribution checks from privileged release work and verify the identity of the artifact that is actually deployed. CI/CD Build integrity GitHub Actions Provenance SHA pinning A03:2025 A08:2025 CAPEC-444 Find the path that gives code authority Remove the authority before executing contributor code Run contributor tests without release authority Build and attest the release from the protected commit Pin actions to commit SHAs and keep the pins current Account for the 2025–2026 GitHub Actions changes Trace a release through an adversarial evidence table Explain the remaining trust and failure modes", "key": "ci-build-integrity", "domain": "supply-chain", "topic": "Protect the path from pull request to release", "title": "Protect the path from pull request to release", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/build-integrity/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Build and verify a signed software release", "path": "https://softwaresecurity.com/labs/#project-release-verification", "download": "https://softwaresecurity.com/downloads/projects/release-verification-bd914fcbede61c32.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "iac-review Review infrastructure changes as access changes Inspect the effective permissions, exposure, sensitive state, and recovery implications of a proposed infrastructure change. Infrastructure as code Terraform OPA Policy as code Cloud IAM Secrets in state CWE-732 CWE-312 A02:2025 V13.2.2 V13.3.1 V13.3.2 Review the planned result Worked review: an export feature changes three access boundaries Trace access and data paths Encode the review as policy and run it on the plan Treat state and plans as sensitive artifacts Verify after applying Diagnose incomplete fixes Check the result against concrete cases", "key": "iac-review", "domain": "runtime", "topic": "Review infrastructure changes as access changes", "title": "Review infrastructure changes as access changes", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/iac-security/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "prompt-injection-boundaries Contain prompt injection at the application boundary Assume retrieved content can influence model output; enforce data access and consequential actions in components the model cannot authorize for itself. LLM security Prompt injection Indirect prompt injection AI agents CWE-1427 LLM01:2026 ASI01:2026 V8.3.1 Identify every channel that can carry instructions Worked boundary: a support document requests an export Enforce authority outside the model Choose a design that limits what an injection can reach Keep an agent on the user's goal Keep secrets and rules out of the prompt Measure prohibited outcomes Keep a bounded security claim Why delimiters, filters and trusted publishers do not stop injection Check the result against concrete cases", "key": "prompt-injection-boundaries", "domain": "ai-emerging", "topic": "Contain prompt injection at the application boundary", "title": "Contain prompt injection at the application boundary", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/prompt-injection-boundaries/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "secret-handling Secrets management: storage, rotation and leaked-secret response Follow one application credential from issuance through caching, rotation, revocation and restored backups, prove that its old value stops working, and respond correctly when a secret leaks. Secrets management Credential rotation Leaked secrets Secret scanning API keys Incident response CWE-798 CWE-522 CWE-532 V11.5.1 V13.1.4 V13.3.1 V13.3.2 V13.3.4 V13 A secret is a capability with consumers and a cutoff Separate identity, access, and accidental disclosure How should you generate, store and compare secrets and API keys? Rotate the consumer graph in a deliberate order What to do when a secret leaks Stop secrets before they are committed Measure successful migration and explicit old-value rejection", "key": "secret-handling", "domain": "identity-crypto", "topic": "Secrets management: storage, rotation and leaked-secret response", "title": "Secrets management: storage, rotation and leaked-secret response", "path": "https://softwaresecurity.com/domains/identity-crypto/secrets/secrets-lifecycle/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Insecure randomness lab: Generate unguessable API keys", "path": "https://softwaresecurity.com/labs/insecure-randomness/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "mobile-native-boundaries Review trust boundaries in mobile and native clients Protect local data and platform interactions while keeping server-side authorization independent of the client’s behavior. Mobile Native Deep links Trust boundaries Review a design CWE-602 CWE-939 V8.3.1 V2.2.2 Separate possession of a client from authority over data Inventory data copies and externally callable entry points Test boundary violations at both ends of the connection Balance offline use, revocation and resilience A real-world failure Separate token theft, client tampering and authorized offline access", "key": "mobile-native-boundaries", "domain": "appsec", "topic": "Review trust boundaries in mobile and native clients", "title": "Review trust boundaries in mobile and native clients", "path": "https://softwaresecurity.com/domains/appsec/platform-security/mobile-native-trust-boundaries/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Keep an iOS app's storage, links and web bridge in bounds", "path": "https://softwaresecurity.com/labs/#project-ios-platform-boundaries", "download": "https://softwaresecurity.com/downloads/projects/ios-platform-boundaries-5d4c4cd9417f9c64.zip" }, { "title": "Repair an Android app's links, components, network policy and storage", "path": "https://softwaresecurity.com/labs/#project-android-platform-boundaries", "download": "https://softwaresecurity.com/downloads/projects/android-platform-boundaries-52934d7ed9eeeff3.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-ecb ECB mode: why it leaks patterns and what to use instead Derive exactly what ECB reveals and why a longer key cannot fix it, find where ECB enters real code, and replace it with an authenticated mode. ECB Block cipher modes AES AES-GCM Java CWE-327 A04:2025 V11.3.1 V11.3.2 V11.3.3 V11 A permutation applied independently to every block What the observer must be able to compare Choose the security property the record needs What should you do today? Replace the Java default with AES-GCM Verify equality leakage and the replacement boundary", "key": "crypto-ecb", "domain": "identity-crypto", "topic": "ECB mode: why it leaks patterns and what to use instead", "title": "ECB mode: why it leaks patterns and what to use instead", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/ecb-mode-leakage/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-padding-oracle Padding oracle attacks Use a byte-level CBC example to see how a tiny validity signal becomes plaintext information, then design verification that checks more than the error message. Padding oracle CBC Side channels Authenticated encryption Encrypt-then-MAC CWE-353 CWE-208 A04:2025 V11.2.5 V11.3.3 V11.3.5 V11 One changed byte controls one decrypted byte An oracle is observable behavior, not an exception name Stop unauthenticated inputs before plaintext interpretation What should you do today? Use a failure matrix and state the limits of timing evidence", "key": "crypto-padding-oracle", "domain": "identity-crypto", "topic": "Padding oracle attacks", "title": "Padding oracle attacks", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/padding-oracle-attacks/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-hash-collisions Hash collisions and digital signatures: MD5, SHA-1 and what to use Distinguish collisions from preimages, follow a colliding pair through signing and verification, and retire MD5 and SHA-1 from the verifiers that still accept them. Hash functions Digital signatures MD5 SHA-1 Collisions PKI CWE-328 CWE-327 A04:2025 V11.4.1 V11.4.3 V11 What a signature actually authenticates Digest equality is necessary, but workflow matters Migrate the verifier as well as the signer What should you do today? Prove policy rejection independently of signature corruption", "key": "crypto-hash-collisions", "domain": "identity-crypto", "topic": "Hash collisions and digital signatures: MD5, SHA-1 and what to use", "title": "Hash collisions and digital signatures: MD5, SHA-1 and what to use", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/hash-collisions-and-signatures/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-weak-rsa Weak RSA key generation: shared primes, ROCA and safe keys Recover a toy RSA factor with a greatest common divisor, distinguish shared primes, structured primes, duplicate keys and key length, and check a fleet of real public keys. RSA Key generation Entropy ROCA PKI CWE-331 CWE-326 A04:2025 V11.6.1 V11.2.3 V11.5.1 V11 The public modulus is safe only when its factors are hard to recover Do not collapse different key-generation failures Replace the generating process before replacing its outputs What should you do today? Check replacement identity and continuing service", "key": "crypto-weak-rsa", "domain": "identity-crypto", "topic": "Weak RSA key generation: shared primes, ROCA and safe keys", "title": "Weak RSA key generation: shared primes, ROCA and safe keys", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/weak-rsa-key-generation/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-rc4 RC4 keystream bias Understand why fresh RC4 keys do not remove keystream bias and how repeated secret positions turn a small statistical effect into evidence. RC4 Stream ciphers TLS Kerberos Legacy systems CWE-327 A04:2025 V11.3.2 V12.1.2 V11 XOR hides a message only as well as the keystream does Repetition, alignment, and observations determine the attack Retire the primitive and confirm actual negotiation What should you do today? Use counts honestly", "key": "crypto-rc4", "domain": "identity-crypto", "topic": "RC4 keystream bias", "title": "RC4 keystream bias", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/rc4-keystream-bias/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-sweet32-mechanism 64-bit block ciphers and the Sweet32 mechanism Calculate the birthday effect for 64-bit blocks and derive the CBC relation that can turn a collision into a plaintext disclosure. Sweet32 3DES Blowfish Block ciphers Birthday bound CWE-327 CWE-326 A04:2025 V11.3.2 V12.1.2 V11 Block size creates a separate limit from key size A useful collision needs useful traffic structure Replace the short-block construction; bound usage during transition What should you do today? Check arithmetic, collision usefulness, and real key boundaries", "key": "crypto-sweet32-mechanism", "domain": "identity-crypto", "topic": "64-bit block ciphers and the Sweet32 mechanism", "title": "64-bit block ciphers and the Sweet32 mechanism", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/64-bit-block-ciphers-sweet32/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-wep-2001 WEP: RC4 key reuse and weak IVs Separate WEP’s repeated-keystream failure, weak-IV key recovery, and unkeyed integrity weakness through a concrete two-packet exercise. WEP RC4 Wireless security Nonce reuse Integrity CWE-323 CWE-353 A04:2025 V11.3.3 V11.3.4 Several design failures combined in the same frame format Small IV space and linear integrity made local fixes inadequate Nonce allocation, authentication, and replacement are separate tasks What should you do today? What a two-packet calculation can establish", "key": "icdp-case-wep-2001", "domain": "identity-crypto", "topic": "WEP: RC4 key reuse and weak IVs", "title": "WEP: RC4 key reuse and weak IVs", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/wep-rc4-key-reuse/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-flame-2012 Flame: MD5 certificate forgery Follow how a weak digest and an overpowered certificate trust path enabled forged code-signing authority, without equating the event with RSA key theft. PKI MD5 Code signing Certificate validation Collisions CWE-328 CWE-295 A04:2025 V11.4.1 V11.4.3 The forged artifact crossed a trust-purpose boundary Predictable issuance and certificate interpretation mattered Contain the authority and invalidate the vulnerable path What should you do today? Separate observed artifacts from reconstructed explanations", "key": "icdp-case-flame-2012", "domain": "identity-crypto", "topic": "Flame: MD5 certificate forgery", "title": "Flame: MD5 certificate forgery", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/flame-md5-certificate-forgery/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-lucky13-poodle Lucky Thirteen and POODLE: two different oracles Compare two CBC oracles by their signal, protocol rules, and attacker prerequisites instead of treating them as interchangeable padding bugs. TLS Padding oracles Timing attacks Protocol downgrade SSL 3.0 CWE-757 CWE-208 A04:2025 V12.1.1 V12.1.2 V11.2.5 A shared construction, two different leaks Name the observation channel before naming the fix Match remediation to the causal path What should you do today? An equal response is not an equal computation", "key": "icdp-case-lucky13-poodle", "domain": "identity-crypto", "topic": "Lucky Thirteen and POODLE: two different oracles", "title": "Lucky Thirteen and POODLE: two different oracles", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/lucky13-poodle/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-freak-logjam-2015 FREAK and Logjam: export-grade key exchange Trace two export-grade downgrade paths and separate RSA factorization from finite-field Diffie–Hellman discrete logarithms. TLS Diffie–Hellman RSA Protocol downgrade Export-grade cryptography CWE-757 CWE-326 A04:2025 V11.6.2 V12.1.1 V12.1.2 Negotiated labels and signed parameters diverged The arithmetic and amortization are different Remove export paths and validate the actual parameters What should you do today? Keep toy DH separate from the historical exploit", "key": "icdp-case-freak-logjam-2015", "domain": "identity-crypto", "topic": "FREAK and Logjam: export-grade key exchange", "title": "FREAK and Logjam: export-grade key exchange", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/freak-logjam-export-grade-keys/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-drown-2016 DROWN: one RSA key across incompatible protocols Map an RSA key across services to see how an SSLv2 oracle could compromise TLS traffic on a different endpoint. TLS SSLv2 Key reuse Bleichenbacher Padding oracles A04:2025 V11.3.1 V12.1.1 V12.1.2 The vulnerable boundary followed the key, not the hostname A service graph reveals more than a TLS score Close the oracle everywhere the key is used What should you do today? Find endpoints that share a private key Verify both the endpoint and the reuse closure", "key": "icdp-case-drown-2016", "domain": "identity-crypto", "topic": "DROWN: one RSA key across incompatible protocols", "title": "DROWN: one RSA key across incompatible protocols", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/drown/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-sweet32-2016 Sweet32: the cost of a small block size Read the 2016 Sweet32 demonstrations as evidence about traffic volume, repeated secrets, and session lifetime rather than treating a block-size threshold as an instant exploit. Sweet32 TLS 3DES Block ciphers Traffic limits CWE-326 A04:2025 V12.1.2 A long session made an old bound operationally relevant The application supplied repetition and the server supplied longevity Treat cryptographic lifetime as a measurable quantity What should you do today? Convert traffic measurements into bounded conclusions", "key": "icdp-case-sweet32-2016", "domain": "identity-crypto", "topic": "Sweet32: the cost of a small block size", "title": "Sweet32: the cost of a small block size", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/sweet32/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "icdp-case-roca-2017 ROCA: structured RSA key generation Understand why mathematically structured RSA primes were factorable despite normal key lengths, then plan replacement around generation provenance. RSA Key generation Hardware security TPM PKI CWE-1240 CWE-326 A04:2025 V11.6.1 ROCA An optimization restricted the primes a generator could produce Key generation is the affected operation Patch first, generate again, then replace trust What should you do today? A detector is a scoped test, not a warranty", "key": "icdp-case-roca-2017", "domain": "identity-crypto", "topic": "ROCA: structured RSA key generation", "title": "ROCA: structured RSA key generation", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/roca-infineon-weak-keys/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "xss-output-encoding Prevent XSS at the output boundary Choose text rendering, context-aware encoding, or deliberate HTML sanitization according to how the browser will interpret the value. XSS Output encoding HTML DOM Trusted Types Fix a finding CWE-79 CWE-116 A05:2025 V1.2.1 V1.2.2 V1.3.1 V3.2.2 CAPEC-63 CAPEC-588 CAPEC-591 CAPEC-592 WSTG-INPV-01 WSTG-INPV-02 V1 V3 XSS cross site scripting escaping HTML encoding Follow the string into the parser that receives it Choose an interface that preserves the intended type Know the escape hatch in your framework Verify structure and behavior rather than one alert box A real-world failure Check transformations and exceptional rendering paths", "key": "xss-output-encoding", "domain": "appsec", "topic": "Prevent XSS at the output boundary", "title": "Prevent XSS at the output boundary", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/xss-output-encoding/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "XSS lab: Render a model’s answer as text instead of active markup", "path": "https://softwaresecurity.com/labs/output-rendering/" }, { "title": "HTML sanitization lab: Configure a sanitizer for user comments", "path": "https://softwaresecurity.com/labs/html-sanitizer/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ssrf-egress-boundaries Constrain server-side fetches to their intended destinations Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services. SSRF Egress URL validation Cloud metadata Secure a feature CWE-918 A01:2025 API7:2023 V1.3.6 V13.2.4 V15.3.2 CAPEC-664 WSTG-INPV-19 SSRF server side request forgery URL fetching Define the server capability the URL would grant Keep URL policy attached to the actual connection Deny every special-purpose address range Harden the cloud metadata service Check the connected address in Go Use controlled connection evidence for verification Real-world failures Consider mixed DNS answers and authority carried by the fetcher", "key": "ssrf-egress-boundaries", "domain": "appsec", "topic": "Constrain server-side fetches to their intended destinations", "title": "Constrain server-side fetches to their intended destinations", "path": "https://softwaresecurity.com/domains/appsec/secure-features/ssrf-egress-boundaries/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "SSRF lab: Guard an outbound fetch against SSRF", "path": "https://softwaresecurity.com/labs/ssrf-url-policy/" }, { "title": "SSRF validation lab: Validate a fetch URL with ipaddress", "path": "https://softwaresecurity.com/labs/ssrf-validation-python/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "authentication-session-lifecycle Session management: cookies, timeouts, rotation and revocation Model authentication as transitions in server authority, set session cookies and timeouts to current NIST and OWASP values, and verify fixation prevention, expiry, reauthentication, revocation and stolen-cookie defenses. Sessions Session cookies Session timeouts Authentication Secure a feature CWE-384 CWE-613 CWE-614 CWE-1004 CWE-1275 A07:2025 V7.2.3 V7.2.4 V7.3.1 V7.3.2 V7.4.1 V7.4.2 V7.5.1 V3.3.1 V3.3.3 CAPEC-60 CAPEC-61 CAPEC-593 V7 A login event creates authority that survives the password check Session cookies or tokens: which should a web app use? Follow an anonymous browser through login and logout How long should a session last? Issue, check and end a session in Node.js Configure sessions in Spring Boot and Spring Security Configure cookie authentication in ASP.NET Core Exercise a state machine, including a stolen old identifier Defend against stolen session cookies", "key": "authentication-session-lifecycle", "domain": "identity-crypto", "topic": "Session management: cookies, timeouts, rotation and revocation", "title": "Session management: cookies, timeouts, rotation and revocation", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/session-lifecycle/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "password-storage Password storage: hashing parameters and rehash on login Choose Argon2id, scrypt, PBKDF2 or bcrypt with current minimum parameters, store a versioned hash, and upgrade old hashes after a successful login without overwriting a reset. Password hashing Argon2id bcrypt scrypt PBKDF2 NIST SP 800-63B-4 Authentication CWE-916 CWE-759 CWE-760 CWE-257 CWE-521 A04:2025 V6.2.1 V6.2.8 V6.2.9 V6.2.12 V11.4.2 CAPEC-16 CAPEC-49 CAPEC-55 V11 A password verifier should make every offline guess expensive Which algorithm and parameters should you use? Bcrypt or Argon2id: which should you use? Treat cost parameters as a capacity decision with security consequences What password rules does NIST SP 800-63B-4 require? Upgrade with the password you just verified Rehash on login in Python with argon2-cffi Rehash on login in Node.js with argon2 Upgrade hashes with Spring Security Raise the ASP.NET Core Identity work factor Verify compatibility, migration, and concurrency separately", "key": "password-storage", "domain": "identity-crypto", "topic": "Password storage: hashing parameters and rehash on login", "title": "Password storage: hashing parameters and rehash on login", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/password-storage/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Password hashing lab: Verify and upgrade an Argon2 password hash on login", "path": "https://softwaresecurity.com/labs/password-hashing-argon2/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "api-resource-limits Bound API work, not just request counts Protect availability and operating cost with limits on input, per-request work, concurrency, queues, and downstream spending. API security Rate limiting Resource limits HTTP 429 Availability Denial of service CWE-770 CWE-400 API4:2023 V15.1.3 V15.2.2 rate limiting DoS denial of service Identify the expensive operation Worked budget: a report endpoint with an expensive fan-out Apply limits across the work chain Add coarse limits at the edge and use standard responses Observe rejection and recovery Diagnose incomplete fixes Check the result against concrete cases", "key": "api-resource-limits", "domain": "runtime", "topic": "Bound API work, not just request counts", "title": "Bound API work, not just request counts", "path": "https://softwaresecurity.com/domains/runtime/api-security/resource-consumption-limits/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-logging Create security logs someone can investigate Record meaningful decisions with consistent structure, protect the resulting evidence, and prove that important events reach an operational owner. Security logging Audit logs Log injection Redaction OCSF Incident response CWE-532 CWE-778 A09:2025 V16.2.1 V16.2.5 V16.3.2 V16.4.1 V16.4.3 V16 logging security events Start from an investigation question Worked investigation: did a permission change actually take effect? Emit the events with a structured logger Keep the event useful and bounded Map the fields to ECS or OCSF Test the path to a human decision Diagnose incomplete fixes Check the result against concrete cases", "key": "security-logging", "domain": "runtime", "topic": "Create security logs someone can investigate", "title": "Create security logs someone can investigate", "path": "https://softwaresecurity.com/domains/runtime/detection/security-event-logging/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "secure-error-handling Handle failures without leaking internals or weakening controls Give callers a useful, bounded response while preserving protected diagnostic evidence and safe application state. Error handling Information disclosure Reliability Fix a finding CWE-209 CWE-636 CWE-460 CWE-489 A10:2025 V16.5.1 V16.5.3 V13.4.2 WSTG-ERRH-01 WSTG-ERRH-02 V16 Specify an error as a response and a state outcome Preserve the invariant on every failure path Inject failures at meaningful boundaries Switch off framework error detail in production A real-world failure Handle observability failures without hiding the business result", "key": "secure-error-handling", "domain": "appsec", "topic": "Handle failures without leaking internals or weakening controls", "title": "Handle failures without leaking internals or weakening controls", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/secure-error-handling/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "information-disclosure-misconfiguration Security misconfiguration Ship without debug modes, verbose errors or exposed files Turn off debug output, publish an allowlisted build and probe each deployment for exposed files and endpoints. Security misconfiguration Information disclosure Debug mode Error handling Secure defaults Deployment Framework configuration Backend Python Java .NET Node.js PHP Ruby Go Reverse proxy CWE-200 CWE-209 CWE-215 CWE-489 CWE-548 CWE-527 CWE-538 A02:2025 V13.4 V16.5.1 WSTG-CONF-02 WSTG-CONF-04 WSTG-CONF-05 WSTG-ERRH-01 V13 security misconfiguration information disclosure debug mode Actuator source maps directory listing stack trace verbose errors debug page exposed git folder Misconfiguration is the cause, disclosure is the effect Turn off each framework's debug output Django and Flask: what the debug pages really show Spring Boot: expose health, protect the rest ASP.NET Core: the environment decides Express: set NODE_ENV and own the error handler Next.js, Laravel, Rails and PHP: the settings to pin Deploy a build, not a working tree Remove version banners, TRACE and diagnostic endpoints Delete sample apps and default accounts Check configuration in CI and probe every deployment ASVS 5.0 V13.4 requirement by requirement Pitfalls", "key": "information-disclosure-misconfiguration", "domain": "appsec", "topic": "Security misconfiguration", "title": "Ship without debug modes, verbose errors or exposed files", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/information-disclosure-misconfiguration/", "platforms": [ "Backend", "Python", "Java", ".NET", "Node.js", "PHP", "Ruby", "Go", "Reverse proxy" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "coordinated-disclosure Run coordinated vulnerability disclosure from report to advisory Make private reporting discoverable, verify reports, coordinate a tested remedy, and give affected users enough information to act. Vulnerability disclosure VDP PSIRT security.txt CVE Respond to a vulnerability Who receives and owns a vulnerability report? How do you reproduce a report without expanding exposure? When is a fix ready to announce? How do you assign an identifier and publish the advisory? What should the case record hold? How do you keep promises to the reporter on schedule? What does a short advisory look like? When can you close the case? Which regulatory clocks run alongside disclosure? What do you do when the reporter disagrees?", "key": "coordinated-disclosure", "domain": "appsec", "topic": "Run coordinated vulnerability disclosure from report to advisory", "title": "Run coordinated vulnerability disclosure from report to advisory", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/coordinated-disclosure/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "csrf-origin-defense Browser request boundaries Protect cookie-authenticated actions against CSRF Make the server distinguish an intended action from a request another site caused the browser to send. CSRF Cookies Origin SameSite Fetch Metadata Secure a feature Web APIs CWE-352 CWE-1275 A01:2025 V3.3.2 V3.3.3 V3.5.1 V3.5.2 V3.5.3 CAPEC-62 WSTG-SESS-05 V3 CSRF Origin SameSite cross site request forgery Explain why a valid cookie does not prove user intent Bind the action to a session-specific secret and origin policy Check stored state after every browser decision Use your framework's protection Keep the protection attached to the actual authentication model A real-world failure Define missing-header and mixed-authentication exceptions narrowly", "key": "csrf-origin-defense", "domain": "appsec", "topic": "Browser request boundaries", "title": "Protect cookie-authenticated actions against CSRF", "path": "https://softwaresecurity.com/domains/appsec/browser-security/csrf-origin-defense/", "platforms": [ "Web", "APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "CSRF lab: Protect an account change from a forged request", "path": "https://softwaresecurity.com/labs/csrf/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "cors-csp-browser-boundaries Browser response policies Configure CORS and CSP around the browser capabilities you need Control who can read API responses and which resources a page may execute without confusing either control with authorization. CORS CSP Trusted Types Browser security Headers Web APIs CWE-942 CWE-346 CWE-1021 A02:2025 API8:2023 V3.4.2 V3.4.3 V3.4.6 V3.4.7 V3.5.2 WSTG-CLNT-07 V3 Distinguish two browser decisions Write a narrow CORS contract and preserve cache correctness Derive CSP from actual document requirements Debug the layer that actually denied the operation A real-world failure Account for response caching and document reuse", "key": "cors-csp-browser-boundaries", "domain": "appsec", "topic": "Browser response policies", "title": "Configure CORS and CSP around the browser capabilities you need", "path": "https://softwaresecurity.com/domains/appsec/browser-security/cors-csp-browser-boundaries/", "platforms": [ "Web", "APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "CORS policy lab: Grant CORS to the right origins only", "path": "https://softwaresecurity.com/labs/cors-policy/" }, { "title": "CSP builder lab: Build a strict Content-Security-Policy", "path": "https://softwaresecurity.com/labs/csp-policy/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "rich-text-dom-security Rich text and DOM safety Render rich text without granting it application privileges Choose text rendering or a restricted HTML policy, then test the final DOM after every transformation. XSS HTML sanitization Rich text DOM Trusted Types postMessage Web CWE-79 CWE-346 A05:2025 V1.3.1 V1.3.5 V3.2.2 V3.2.3 V3.5.5 CAPEC-588 CAPEC-592 V1 V3 sanitization Trusted Types DOM XSS Treat rich text as a request for browser capabilities Sanitize after conversion and before the HTML sink Choose a maintained sanitizer and keep it current Constrain the application surrounding the rendered content Verify retained formatting and removed capability Decide how stored content survives a policy change", "key": "rich-text-dom-security", "domain": "appsec", "topic": "Rich text and DOM safety", "title": "Render rich text without granting it application privileges", "path": "https://softwaresecurity.com/domains/appsec/browser-security/rich-text-dom-security/", "platforms": [ "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "HTML sanitization lab: Configure a sanitizer for user comments", "path": "https://softwaresecurity.com/labs/html-sanitizer/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "function-property-authorization Function and property authorization Authorize functions and fields as well as objects Prevent mass assignment, sensitive-field exposure and administrative actions that a valid object lookup alone cannot protect. Authorization Mass assignment BFLA BOPLA API security Fix a finding Web APIs Backend CWE-915 CWE-213 CWE-862 A01:2025 API3:2023 API5:2023 V8.2.1 V8.2.3 V15.3.1 V15.3.3 V8 BFLA BOPLA mass assignment function authorization property authorization Ask four separate permission questions Build writable and readable projections explicitly Use your framework's field allowlist Bind privileged transitions to current state Test forbidden fields and forbidden functions independently Separate omission, deletion and unchanged values", "key": "function-property-authorization", "domain": "appsec", "topic": "Function and property authorization", "title": "Authorize functions and fields as well as objects", "path": "https://softwaresecurity.com/domains/appsec/authorization/function-property-authorization/", "platforms": [ "Web", "APIs", "Backend" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Mass assignment lab: Update only the fields users may edit", "path": "https://softwaresecurity.com/labs/mass-assignment/" } ], "projects": [ { "title": "Secure a real HTTP API", "path": "https://softwaresecurity.com/labs/#project-express-api", "download": "https://softwaresecurity.com/downloads/projects/express-api-519f6cf7960d8d96.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "transaction-races Transactions and business abuse Preserve business invariants under concurrent requests Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through. Race conditions Transactions Idempotency Business logic PostgreSQL Backend APIs PostgreSQL CWE-362 CWE-367 CWE-837 A06:2025 V2.3.3 V2.3.4 V15.4.2 CAPEC-26 CAPEC-29 V2 V15 race condition TOCTOU Compute the invariant across an interleaving Make the condition part of the atomic database change Lock rows when the rule spans several records Carry one operation identity into external effects Verify results and contention deliberately A real-world failure Choose what an idempotent replay is allowed to reveal", "key": "transaction-races", "domain": "appsec", "topic": "Transactions and business abuse", "title": "Preserve business invariants under concurrent requests", "path": "https://softwaresecurity.com/domains/appsec/business-logic/transaction-races/", "platforms": [ "Backend", "APIs", "PostgreSQL" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Race condition lab: Repair a balance check that races", "path": "https://softwaresecurity.com/labs/checkout-race/" }, { "title": "Business logic lab: Price an order without trusting the client", "path": "https://softwaresecurity.com/labs/coupon-limits/" } ], "projects": [ { "title": "Make a checkout transaction atomic", "path": "https://softwaresecurity.com/labs/#project-checkout-sqlite", "download": "https://softwaresecurity.com/downloads/projects/checkout-sqlite-0f06facdf0c0bb1b.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "injection-parser-boundaries Injection and parser safety Keep untrusted values out of executable syntax Choose a safe interface for each interpreter and bound the work performed by parsers and converters. Command injection XXE Deserialization NoSQL injection LDAP injection SSTI Web Backend Native CWE-943 CWE-90 A05:2025 V1.2.4 V1.2.5 V1.2.6 V1.3.2 V1.3.7 V1.5.1 V1.5.2 CAPEC-88 CAPEC-201 CAPEC-586 CAPEC-676 CAPEC-136 CAPEC-242 V1 command injection argument injection OS command injection shell injection Identify every interpreter, not only the first input check Replace source construction with a typed operation Use the safe interface each language provides Disable parser capabilities the format does not require Build NoSQL and directory queries from typed values Test ordinary values, syntax-shaped values and resource edges Treat sanitizers as grammar-specific claims", "key": "injection-parser-boundaries", "domain": "appsec", "topic": "Injection and parser safety", "title": "Keep untrusted values out of executable syntax", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/injection-parser-boundaries/", "platforms": [ "Web", "Backend", "Native" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "SQL injection lab: Separate SQL structure from data with sqlite3", "path": "https://softwaresecurity.com/labs/sql-injection-sqlite/" }, { "title": "OS command injection lab: Run git without a shell", "path": "https://softwaresecurity.com/labs/command-injection/" }, { "title": "SSTI lab: Render a welcome banner without template injection", "path": "https://softwaresecurity.com/labs/template-injection-jinja/" }, { "title": "XXE lab: Parse an uploaded invoice without resolving external entities", "path": "https://softwaresecurity.com/labs/xxe-lxml/" }, { "title": "Pickle deserialization lab: Load a session token without pickle", "path": "https://softwaresecurity.com/labs/pickle-deserialization/" } ], "projects": [ { "title": "Parse bounded JSON and XML invoices safely", "path": "https://softwaresecurity.com/labs/#project-bounded-data-parsing", "download": "https://softwaresecurity.com/downloads/projects/bounded-data-parsing-aa166a936b50b8b5.zip" }, { "title": "Repair a native parser using sanitizer evidence", "path": "https://softwaresecurity.com/labs/#project-native-memory-safety", "download": "https://softwaresecurity.com/downloads/projects/native-memory-safety-c6897059c95e033a.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "os-command-injection Command injection Run external programs without command or argument injection Run programs from an argument list with no shell, end options before user values, and keep untrusted arguments away from Windows batch files. Command injection Argument injection Injection Subprocess Shell Input validation Backend Python Node.js Java .NET Go PHP Ruby Windows Linux CWE-78 CWE-77 CWE-88 A05:2025 V1.2.5 V1.2.8 V2.2.1 CAPEC-88 CAPEC-6 CAPEC-248 WSTG-INPV-12 command injection shell injection argument injection BatBadBut subprocess OS command injection shell metacharacters option injection The shell is what turns data into commands Use the argument-array API in every language Python: subprocess with a list, a pattern and --end-of-options Prove it with a test that watches for side effects An argument array still lets a value become an option Node.js: execFile with an array and limits Java: ProcessBuilder with a list and a cleared environment C#: ProcessStartInfo.ArgumentList, never an Arguments string Go: exec.CommandContext with an explicit Env Choose the executable, environment and working directory Windows: batch files reparse their arguments (BatBadBut) Map choices to fixed arguments with an allowlist Find the remaining call sites Pitfalls", "key": "os-command-injection", "domain": "appsec", "topic": "Command injection", "title": "Run external programs without command or argument injection", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/os-command-injection/", "platforms": [ "Backend", "Python", "Node.js", "Java", ".NET", "Go", "PHP", "Ruby", "Windows", "Linux" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "code-template-injection Code and template injection Keep untrusted input out of eval, expression languages and templates Keep code and templates constant, pass input as data, and treat in-process sandboxes as one layer, not a boundary. Code injection Template injection SSTI Expression language injection Injection Sandboxing Eval Backend Node.js Python Java PHP Ruby CWE-94 CWE-95 CWE-1336 CWE-917 A05:2025 V1.3.2 V1.3.7 CAPEC-242 WSTG-INPV-11 WSTG-INPV-18 SSTI template injection code injection eval SpEL OGNL server side template injection expression language injection EL injection Input that becomes source code JavaScript: no eval, no Function, and vm is not a sandbox Python: eval, exec and the limits of literal_eval Java expression languages: SpEL, OGNL and Jakarta EL Template injection: where the template text comes from What each engine exposes, and its setting for user templates PHP: the Twig sandbox for templates users write Ruby: ERB templates are Ruby code In-process sandboxes are a layer, not a boundary Give users a language you control Test that expressions come back as text Pitfalls", "key": "code-template-injection", "domain": "appsec", "topic": "Code and template injection", "title": "Keep untrusted input out of eval, expression languages and templates", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/code-template-injection/", "platforms": [ "Backend", "Node.js", "Python", "Java", "PHP", "Ruby" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "archive-path-safety Archive and filesystem safety Extract archives without escaping the destination Prevent traversal, link tricks, overwrites and decompression exhaustion while preserving legitimate file extraction. Path traversal Zip Slip Archives Symlinks File upload Backend Desktop CI CWE-22 CWE-23 CWE-36 CWE-59 CWE-409 A01:2025 V5.2.3 V5.2.5 V5.3.3 CAPEC-126 CAPEC-139 CAPEC-597 V5 path traversal archive extraction Zip Slip directory traversal Read archive members as instructions to a filesystem Keep all writes inside a private destination Use the containment API your platform provides Account for actual work and partial extraction Verify names, types, bytes and cleanup independently Review publication and cleanup as separate authority changes", "key": "archive-path-safety", "domain": "appsec", "topic": "Archive and filesystem safety", "title": "Extract archives without escaping the destination", "path": "https://softwaresecurity.com/domains/appsec/secure-features/archive-path-safety/", "platforms": [ "Backend", "Desktop", "CI" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Path traversal lab: Keep archive entries inside their extraction directory", "path": "https://softwaresecurity.com/labs/archive-paths/" }, { "title": "Path traversal lab: Serve an uploaded file without path traversal", "path": "https://softwaresecurity.com/labs/path-traversal-python/" } ], "projects": [ { "title": "Keep extracted files inside their boundary", "path": "https://softwaresecurity.com/labs/#project-archive-extraction", "download": "https://softwaresecurity.com/downloads/projects/archive-extraction-e31e8b17b78e9134.zip" }, { "title": "Convert untrusted documents in a locked-down container", "path": "https://softwaresecurity.com/labs/#project-document-conversion-sandbox", "download": "https://softwaresecurity.com/downloads/projects/document-conversion-sandbox-62d2ff3fa1f9ec09.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "untrusted-document-conversion Document conversion Convert untrusted office documents and PDFs in an isolated parser DOCX, XLSX and ODF files are ZIP archives of XML, and PDFs can carry scripts; the converters that read them are large C and C++ programs with a long CVE history. Check the package before any parser reads it, convert each document in a container with no network, no writable root and hard limits, kill it at a deadline, and re-render to pixels when people will open the result. Document conversion File upload Archives Zip bomb XXE Resource limits PDF Memory safety Sandboxing Backend Containers Linux CWE-409 V5.2.2 V5.2.3 V1.5.1 V15.2.5 document conversion LibreOffice Ghostscript Dangerzone zip bomb document sanitization office document sandbox What a document can make a parser do Check the package before any parser reads it Run each document in its own locked-down container Kill the container at the deadline, then check the output Settings for the common converters Re-render to pixels when people will open the result What the project's live tests showed Pitfalls", "key": "untrusted-document-conversion", "domain": "appsec", "topic": "Document conversion", "title": "Convert untrusted office documents and PDFs in an isolated parser", "path": "https://softwaresecurity.com/domains/appsec/secure-features/untrusted-document-conversion/", "platforms": [ "Backend", "Containers", "Linux" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Convert untrusted documents in a locked-down container", "path": "https://softwaresecurity.com/labs/#project-document-conversion-sandbox", "download": "https://softwaresecurity.com/downloads/projects/document-conversion-sandbox-62d2ff3fa1f9ec09.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "webrtc-security WebRTC Secure WebRTC signaling, TURN relays and media servers WebRTC encrypts media, but signaling decides whose keys you trust and TURN relays wherever it is allowed. Authorize every signaling message, mint short-lived TURN credentials, deny internal addresses and harden media servers. WebRTC TURN Signaling DTLS-SRTP WebSocket Resource limits Privacy Web WebSocket Node.js Python CWE-441 CWE-295 CWE-359 V17 V17.1.1 V17.1.2 V17.2.1 V17.2.2 V17.2.3 V17.2.4 V17.2.5 V17.2.6 V17.2.7 V17.2.8 V17.3.1 V17.3.2 WebRTC TURN coturn signaling DTLS-SRTP ICE candidates video call security STUN ASVS V17 Encryption is mandatory; trust in signaling is not Authenticate and authorize every signaling message Mint short-lived TURN credentials Stop the TURN server relaying inward Test the relay from outside Decide what ICE candidates reveal DTLS-SRTP: fingerprints, cipher suites and keys Harden media servers against hostile packets ASVS 5.0 V17, requirement by requirement Pitfalls", "key": "webrtc-security", "domain": "appsec", "topic": "WebRTC", "title": "Secure WebRTC signaling, TURN relays and media servers", "path": "https://softwaresecurity.com/domains/appsec/secure-features/webrtc-security/", "platforms": [ "Web", "WebSocket", "Node.js", "Python" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-code-review Security code review Review a code change through its trust boundaries Turn a pull request into a small set of security claims that can be checked against the surrounding system and tests. Code review Pull requests Authorization AI-assisted coding Secure SDLC All platforms V8.2.2 V8.3.1 Find the newly reachable capability in the change Match review depth to what the change touches Trace one request through the real control flow Write a finding another engineer can reproduce Treat AI-assisted and automated review as inputs Verify the patch and the review assumptions A real-world failure Review the test as evidence rather than decoration", "key": "security-code-review", "domain": "appsec", "topic": "Security code review", "title": "Review a code change through its trust boundaries", "path": "https://softwaresecurity.com/domains/appsec/code-review/security-code-review/", "platforms": [ "All platforms" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Secure a real HTTP API", "path": "https://softwaresecurity.com/labs/#project-express-api", "download": "https://softwaresecurity.com/downloads/projects/express-api-519f6cf7960d8d96.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "sast-dast-workflow Application security testing Combine static and dynamic tests around a verified finding Use analysis tools to find evidence, then retain an application regression that demonstrates the failure and the fix. SAST DAST IAST Semgrep OWASP ZAP Triage Web APIs CI SAST DAST IAST security scanning Understand the evidence each technique can supply Make the static claim reproducible and inspectable Run the rules in CI and keep the results as SARIF Prove the dynamic test reached the intended operation Close a finding by connecting behavior to the repair Keep scan configuration and application revision linked", "key": "sast-dast-workflow", "domain": "appsec", "topic": "Application security testing", "title": "Combine static and dynamic tests around a verified finding", "path": "https://softwaresecurity.com/domains/appsec/testing/sast-dast-workflow/", "platforms": [ "Web", "APIs", "CI" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "parser-fuzzing Fuzzing and memory safety Fuzz a parser and turn crashes into lasting regressions Build a narrow harness, observe memory and resource failures, minimize the input, and test the repaired parser. Fuzzing Sanitizers Parsers Memory safety libFuzzer Go C C++ Go Python Native Backend CWE-130 CWE-1284 V1.4.1 V1.4.2 CAPEC-28 Define the parser invariant before choosing a fuzzer Use a deterministic target and explicit semantic checks Build a native harness with sanitizers Use the fuzzing engine your language provides Reduce a failure to the rule it violates Interpret a clean run as bounded evidence A real-world failure Improve the oracle before increasing execution count", "key": "parser-fuzzing", "domain": "appsec", "topic": "Fuzzing and memory safety", "title": "Fuzz a parser and turn crashes into lasting regressions", "path": "https://softwaresecurity.com/domains/appsec/testing/parser-fuzzing/", "platforms": [ "C", "C++", "Go", "Python", "Native", "Backend" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Parse bounded JSON and XML invoices safely", "path": "https://softwaresecurity.com/labs/#project-bounded-data-parsing", "download": "https://softwaresecurity.com/downloads/projects/bounded-data-parsing-aa166a936b50b8b5.zip" }, { "title": "Repair a native parser using sanitizer evidence", "path": "https://softwaresecurity.com/labs/#project-native-memory-safety", "download": "https://softwaresecurity.com/downloads/projects/native-memory-safety-c6897059c95e033a.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "framework-security-patterns Framework security patterns Preserve framework security controls across the request lifecycle Trace middleware, persistence and rendering so custom code does not bypass the protections supplied by the framework. Frameworks Secure defaults Middleware Deployment Django Spring Security Python Django Java Spring .NET Node.js Web CWE-1188 CWE-288 CWE-489 V13.4.2 V3.3.1 V3.4.1 V3.4.3 V15.3.4 Django Spring middleware framework security Follow the request lifecycle instead of assuming defaults apply Preserve middleware behavior across alternate routes Turn on the production settings in your framework Review escape hatches at their actual sinks Verify one complete request and then break one assumption at a time Treat upgrades as changes to a verified contract", "key": "framework-security-patterns", "domain": "appsec", "topic": "Framework security patterns", "title": "Preserve framework security controls across the request lifecycle", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/framework-security-patterns/", "platforms": [ "Python", "Django", "Java", "Spring", ".NET", "Node.js", "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Secure a real HTTP API", "path": "https://softwaresecurity.com/labs/#project-express-api", "download": "https://softwaresecurity.com/downloads/projects/express-api-519f6cf7960d8d96.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "android-ios-security Android and iOS security Review mobile storage, links and platform permissions Keep local artifacts and platform entry points from exposing authority that belongs on the server. MASVS Android iOS Deep links Local storage Review a design Android iOS Mobile CWE-926 CWE-939 CWE-922 CWE-532 CWE-295 Model the operating system as a set of entry points and storage policies Trace sensitive data beyond the primary credential store Narrow links, permissions and inter-app requests Map each control to its Android and iOS setting Verify on the supported device and account lifecycle A real-world failure Validate platform-specific assumptions with targeted evidence", "key": "android-ios-security", "domain": "appsec", "topic": "Android and iOS security", "title": "Review mobile storage, links and platform permissions", "path": "https://softwaresecurity.com/domains/appsec/platform-security/android-ios-security/", "platforms": [ "Android", "iOS", "Mobile" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Keep an iOS app's storage, links and web bridge in bounds", "path": "https://softwaresecurity.com/labs/#project-ios-platform-boundaries", "download": "https://softwaresecurity.com/downloads/projects/ios-platform-boundaries-5d4c4cd9417f9c64.zip" }, { "title": "Repair an Android app's links, components, network policy and storage", "path": "https://softwaresecurity.com/labs/#project-android-platform-boundaries", "download": "https://softwaresecurity.com/downloads/projects/android-platform-boundaries-52934d7ed9eeeff3.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "electron-native-security Desktop and native boundaries Constrain desktop IPC and privileged helpers Keep renderer content, local callers and plugins from turning a narrow feature into unrestricted operating-system access. Electron IPC contextBridge Sandbox Desktop Privilege separation Electron Windows macOS Linux CWE-749 CWE-346 CWE-940 Treat the renderer as a requester of native actions Expose a small bridge and validate the sender Work through Electron's security checklist Apply the same rule to native helpers and updates Test the capability without relying on the ordinary UI Make sender checks survive application navigation", "key": "electron-native-security", "domain": "appsec", "topic": "Desktop and native boundaries", "title": "Constrain desktop IPC and privileged helpers", "path": "https://softwaresecurity.com/domains/appsec/platform-security/electron-native-security/", "platforms": [ "Electron", "Windows", "macOS", "Linux" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Stop untrusted pages from using an Electron bridge", "path": "https://softwaresecurity.com/labs/#project-electron-ipc-bridge", "download": "https://softwaresecurity.com/downloads/projects/electron-ipc-bridge-af9ef6ea324e1aa6.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "embedded-update-security Embedded lifecycle security Design firmware updates that can recover safely Connect trusted boot, update authorization, rollback policy and end-of-life behavior to the device’s actual failure modes. Secure boot Firmware OTA updates MCUboot Anti-rollback Recovery Embedded IoT Firmware CWE-494 CWE-1277 CWE-1329 A08:2025 Separate authentic code from an authorized upgrade Authenticate metadata and enforce freshness before destructive work Make interruption part of the state machine Sign the version into the image Choose an update framework for the device class Test recovery, fleet visibility and retirement Publish and meet the support period A real-world failure Include key change and recovery in the test matrix", "key": "embedded-update-security", "domain": "appsec", "topic": "Embedded lifecycle security", "title": "Design firmware updates that can recover safely", "path": "https://softwaresecurity.com/domains/appsec/platform-security/embedded-update-security/", "platforms": [ "Embedded", "IoT", "Firmware" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Recover from failed firmware updates with A/B slots", "path": "https://softwaresecurity.com/labs/#project-firmware-ab-recovery", "download": "https://softwaresecurity.com/downloads/projects/firmware-ab-recovery-68b16aa41556a541.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "kubernetes-workload-security Kubernetes workload hardening Run Kubernetes workloads with only the privileges they need Review pod settings, service accounts and effective permissions together before treating a namespace as an isolation boundary. Kubernetes Pod Security Standards Pod Security Admission securityContext RBAC Service accounts Kubernetes Linux containers CWE-250 A02:2025 K01:2025 A pod has operating-system and API privileges Worked design: a status service that reads one ConfigMap Choose explicit restrictions and necessary exceptions Enforce the Restricted standard at admission Treat the service account as an application credential Test the effective deployment Diagnose incomplete fixes Check the result against concrete cases", "key": "kubernetes-workload-security", "domain": "runtime", "topic": "Kubernetes workload hardening", "title": "Run Kubernetes workloads with only the privileges they need", "path": "https://softwaresecurity.com/domains/runtime/containers/kubernetes-workload-security/", "platforms": [ "Kubernetes", "Linux containers" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Privileged container lab: Reject a privileged workload before deployment", "path": "https://softwaresecurity.com/labs/kubernetes-policy/" }, { "title": "NetworkPolicy lab: Lock down a shop namespace", "path": "https://softwaresecurity.com/labs/network-policy/" } ], "projects": [ { "title": "Verify Kubernetes admission and network boundaries", "path": "https://softwaresecurity.com/labs/#project-kubernetes-enforcement", "download": "https://softwaresecurity.com/downloads/projects/kubernetes-enforcement-6d129f5f9f250337.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "container-network-admission Container network and admission Prove network and admission policies enforce the intended boundary Verify allowed traffic and rejected deployments in the cluster instead of treating policy files as evidence of isolation. NetworkPolicy Default deny Egress Admission ValidatingAdmissionPolicy Kubernetes Kubernetes Containers A02:2025 K04:2025 K05:2025 NetworkPolicy network policy default deny Policy meaning depends on the enforcing component Worked policy: why a second allow rule reopens the database Permit the actual dependency graph Reject unsafe changes with a recoverable operating model Use positive and negative probes Diagnose incomplete fixes Check the result against concrete cases", "key": "container-network-admission", "domain": "runtime", "topic": "Container network and admission", "title": "Prove network and admission policies enforce the intended boundary", "path": "https://softwaresecurity.com/domains/runtime/containers/container-network-admission/", "platforms": [ "Kubernetes", "Containers" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Privileged container lab: Reject a privileged workload before deployment", "path": "https://softwaresecurity.com/labs/kubernetes-policy/" }, { "title": "NetworkPolicy lab: Lock down a shop namespace", "path": "https://softwaresecurity.com/labs/network-policy/" } ], "projects": [ { "title": "Verify Kubernetes admission and network boundaries", "path": "https://softwaresecurity.com/labs/#project-kubernetes-enforcement", "download": "https://softwaresecurity.com/downloads/projects/kubernetes-enforcement-6d129f5f9f250337.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "cloud-iam-trust Cloud IAM and trust Review cloud permissions and role trust together Distinguish who can obtain a cloud identity from what that identity can do, then test the effective access path. Cloud IAM Workload identity federation GitHub OIDC Trust policies Least privilege Terraform AWS Azure Google Cloud A02:2025 A useful permission needs an authorized way to acquire it Worked access graph: a narrow role with a broad entrance Constrain the principal and its context Evaluate the complete access decision Test allowed, unrelated and expired identities Diagnose incomplete fixes Check the result against concrete cases", "key": "cloud-iam-trust", "domain": "runtime", "topic": "Cloud IAM and trust", "title": "Review cloud permissions and role trust together", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/cloud-iam-trust/", "platforms": [ "AWS", "Azure", "Google Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "IAM trust policy lab: Evaluate a role trust policy against the confused deputy", "path": "https://softwaresecurity.com/labs/iam-trust-policy/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "iac-policy-drift Infrastructure policy and drift Test infrastructure policy and detect security-relevant drift Connect source configuration, the proposed plan and deployed resources so a safe review does not become stale after deployment. IaC Policy as code OPA Drift detection Terraform Exceptions Terraform Cloud Kubernetes A02:2025 Three representations can disagree Worked policy: public database ingress with unknown values Build policies around insecure and secure fixtures Bind approval to what is applied Practice a drift decision before an incident Diagnose incomplete fixes Check the result against concrete cases", "key": "iac-policy-drift", "domain": "runtime", "topic": "Infrastructure policy and drift", "title": "Test infrastructure policy and detect security-relevant drift", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/iac-policy-drift/", "platforms": [ "Terraform", "Cloud", "Kubernetes" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "subdomain-takeover DNS and subdomain takeover Prevent subdomain takeover from dangling DNS records A DNS record that outlives its cloud resource lets whoever claims the name serve content on your domain. Bind records to resources in IaC, remove the record first, verify domains and scan for dangling records. Subdomain takeover Dangling DNS DNS Infrastructure as code Cloud security baseline Asset inventory Certificate Transparency AWS Azure Google Cloud Terraform CDN V3.3.3 V3.4.2 V10.4.1 WSTG-CONF-10 subdomain takeover dangling DNS dangling CNAME CNAME NS delegation domain takeover DNS takeover WSTG-CONF-10 A record that outlives its resource Why it is an application security problem Which provider names can be reclaimed Order the record and resource lifecycle Terraform on AWS: alias records and a delegation that waits Terraform on Azure: domain verification and alias records Limit certificate issuance and watch for it Scan your zones for dangling records Check one name by hand If a subdomain has been taken over Pitfalls", "key": "subdomain-takeover", "domain": "runtime", "topic": "DNS and subdomain takeover", "title": "Prevent subdomain takeover from dangling DNS records", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/subdomain-takeover/", "platforms": [ "AWS", "Azure", "Google Cloud", "Terraform", "CDN" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "api-gateway-inventory API inventory and gateway trust Maintain an API inventory and prevent gateway bypass Connect documented routes, deployed listeners and backend trust so retired or direct paths do not bypass the intended controls. API inventory API gateway Trusted proxies X-Forwarded-For API retirement API security REST OpenAPI Gateways Cloud CWE-290 CWE-348 CWE-306 API9:2023 V4.1.3 A gateway protects only traffic that actually crosses it Worked inventory: one invoice service, three entrances, one forgotten route Authenticate the upstream and distrust caller headers Trust forwarded headers only from your own proxies Validate requests without hiding parser disagreements Remove the capability, not only the documentation Diagnose incomplete fixes Check the result against concrete cases", "key": "api-gateway-inventory", "domain": "runtime", "topic": "API inventory and gateway trust", "title": "Maintain an API inventory and prevent gateway bypass", "path": "https://softwaresecurity.com/domains/runtime/api-security/api-gateway-inventory/", "platforms": [ "REST", "OpenAPI", "Gateways", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "protocol-api-security Protocol-specific API controls Apply security limits to GraphQL, WebSocket and gRPC operations Carry authorization and resource budgets past the initial HTTP request into resolvers, messages and long-lived streams. GraphQL WebSocket gRPC API security Resource limits CSWSH GraphQL WebSocket gRPC REST CWE-1385 CWE-307 V4.3.1 V4.3.2 V4.4.1 V4.4.2 V4 The request boundary changes with the protocol Worked operations: count the work behind the connection Authorize resolved data and bound the query cost Reevaluate authority and stop work when the stream ends Set gRPC limits and make deadlines cancel work Observe the expensive and persistent parts Diagnose incomplete fixes Check the result against concrete cases", "key": "protocol-api-security", "domain": "runtime", "topic": "Protocol-specific API controls", "title": "Apply security limits to GraphQL, WebSocket and gRPC operations", "path": "https://softwaresecurity.com/domains/runtime/api-security/protocol-api-security/", "platforms": [ "GraphQL", "WebSocket", "gRPC", "REST" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a real proxy and shared cache", "path": "https://softwaresecurity.com/labs/#project-proxy-cache-boundaries", "download": "https://softwaresecurity.com/downloads/projects/proxy-cache-boundaries-66af6733aa29700d.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "bounded-background-work Queues and resource budgets Bound background jobs and make retries safe Keep queues, workers and paid dependencies within a defined budget when clients retry, cancel or disappear. Queues Idempotency Retries Dead-letter queues Backpressure Cancellation Backend Queues Serverless APIs V15.2.2 V16.5.2 queues backpressure timeouts An HTTP timeout may leave the expensive work running Worked crash: one charge, two message deliveries Apply backpressure before accepting unbounded obligations Carry deadlines and idempotency through the chain Measure recovery as well as rejection Diagnose incomplete fixes Check the result against concrete cases", "key": "bounded-background-work", "domain": "runtime", "topic": "Queues and resource budgets", "title": "Bound background jobs and make retries safe", "path": "https://softwaresecurity.com/domains/runtime/availability/bounded-background-work/", "platforms": [ "Backend", "Queues", "Serverless", "APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "workload-mtls-serverless Workload and service identity Authenticate workloads and authorize their service actions Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization. mTLS Istio SPIFFE Service mesh AWS Lambda Authorization Service mesh Kubernetes Serverless Cloud V12.3.3 V12.3.5 V8.2.1 V12 A workload identity names a caller, not its entire permission set Worked service call: a valid certificate is only the first decision Express the allowed service graph explicitly Separate invocation authority from execution authority Keep each invocation's authority local Test identity changes and unauthorized peers Diagnose incomplete fixes Check the result against concrete cases", "key": "workload-mtls-serverless", "domain": "runtime", "topic": "Workload and service identity", "title": "Authenticate workloads and authorize their service actions", "path": "https://softwaresecurity.com/domains/runtime/service-security/workload-mtls-serverless/", "platforms": [ "Service mesh", "Kubernetes", "Serverless", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "runtime-detection-response Runtime detection and response Turn runtime events into a tested investigation and containment path Collect evidence that answers a concrete security question and rehearse the response without destroying the facts needed to investigate. Detection engineering Incident response Kubernetes audit CloudTrail Sigma Audit logs Cloud Kubernetes Applications A09:2025 Collection and detection are different outcomes Worked investigation: privilege change followed by export Implement the rule on event time Collect enough context without copying secrets Record Kubernetes API actions with an audit policy Turn on the CloudTrail data events you will need Connect a rule to an investigation decision Write the detection once in Sigma Exercise the full path to recovery Diagnose incomplete fixes Check the result against concrete cases", "key": "runtime-detection-response", "domain": "runtime", "topic": "Runtime detection and response", "title": "Turn runtime events into a tested investigation and containment path", "path": "https://softwaresecurity.com/domains/runtime/detection/runtime-detection-response/", "platforms": [ "Cloud", "Kubernetes", "Applications" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "edge-waf-bot-defense Edge and automated abuse defense Operate edge rules without hiding application defects Tune WAF and abuse controls against legitimate traffic, parser behavior and measurable business effects. WAF OWASP CRS ModSecurity Bot defense Credential stuffing Rule exclusions WAF Reverse proxy CDN Web V2.4.1 V6.3.1 An edge control sees a different view from the application Worked exclusion: a comment field contains legitimate punctuation Write a narrow exclusion for OWASP CRS Tune narrow exceptions with representative traffic Keep intermediaries consistent about the request and response Rate-limit the business consequence as well as traffic Diagnose incomplete fixes Check the result against concrete cases", "key": "edge-waf-bot-defense", "domain": "runtime", "topic": "Edge and automated abuse defense", "title": "Operate edge rules without hiding application defects", "path": "https://softwaresecurity.com/domains/runtime/edge-defense/edge-waf-bot-defense/", "platforms": [ "WAF", "Reverse proxy", "CDN", "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a real proxy and shared cache", "path": "https://softwaresecurity.com/labs/#project-proxy-cache-boundaries", "download": "https://softwaresecurity.com/downloads/projects/proxy-cache-boundaries-66af6733aa29700d.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "sbom-generation SBOM generation Generate an SBOM for the software you actually release Define the inventory boundary, compare build and artifact evidence, and connect the resulting SBOM to an immutable release. SBOM CycloneDX SPDX Syft CISA minimum elements Release inventory Build systems Containers Package ecosystems A03:2025 V15.1.2 Define what the inventory describes Combine views without inventing certainty Generate the inventory with Syft, Trivy and package managers Test completeness against independent known facts Check the CISA 2026 minimum elements Sign the SBOM and attach it to the image digest Publish the inventory as part of a release record Know which requirement the SBOM must meet", "key": "sbom-generation", "domain": "supply-chain", "topic": "SBOM generation", "title": "Generate an SBOM for the software you actually release", "path": "https://softwaresecurity.com/domains/supply-chain/sbom/generate-release-inventory/", "platforms": [ "Build systems", "Containers", "Package ecosystems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "SBOM completeness lab: Find the dependencies missing from a release SBOM", "path": "https://softwaresecurity.com/labs/sbom-inventory/" } ], "projects": [ { "title": "Build and verify a signed software release", "path": "https://softwaresecurity.com/labs/#project-release-verification", "download": "https://softwaresecurity.com/downloads/projects/release-verification-bd914fcbede61c32.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "sbom-formats-identifiers SBOM formats and identifiers Choose SBOM formats and identify components accurately Separate schema versions, document references and package identities so inventory conversion and advisory matching preserve meaning. SPDX CycloneDX purl CPE Component identity SBOM conversion Package ecosystems Build systems A03:2025 purl package URL SPDX CycloneDX SBOM Treat an SBOM format as an interface contract Find each minimum element in CycloneDX and SPDX Separate graph references, package coordinates and bytes Use purl for packages and CPE where a database needs it Preserve what an edge actually claims Use a fixture designed to expose information loss", "key": "sbom-formats-identifiers", "domain": "supply-chain", "topic": "SBOM formats and identifiers", "title": "Choose SBOM formats and identify components accurately", "path": "https://softwaresecurity.com/domains/supply-chain/sbom/formats-and-identifiers/", "platforms": [ "Package ecosystems", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "sbom-release-diff SBOM lifecycle Review SBOM changes between releases Turn inventory differences into explainable release decisions without confusing generator changes with software changes. SBOM CycloneDX Release management Inventory diff Distribution Build systems Containers A03:2025 Establish comparability before counting change Separate upgrades, substitutions and discoveries Classify the changes with a script you can audit Turn the difference into an owned decision Preserve the history consumers need", "key": "sbom-release-diff", "domain": "supply-chain", "topic": "SBOM lifecycle", "title": "Review SBOM changes between releases", "path": "https://softwaresecurity.com/domains/supply-chain/sbom/release-diff-and-distribution/", "platforms": [ "Build systems", "Containers" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "dependency-risk-triage Dependency risk Triage new dependency vulnerability findings Turn a weekly batch of Dependabot, OSV-Scanner or npm audit findings into a short list of distinct, shipped, reachable issues, each routed to one outcome: fix, not affected, accept or escalate. SCA Dependency triage Dependabot npm audit OSV-Scanner Reachability Transitive dependencies Package ecosystems Node.js Python Go CWE-1395 CWE-1104 A03:2025 V15.1.1 V15.2.1 V15 Dependabot OSV-Scanner SCA triage How many findings are really in this batch? Fix the parent, then triage what is left Check the precondition each advisory names Route each finding to one outcome Let update bots carry the routine fixes Close the finding on the deployed artifact", "key": "dependency-risk-triage", "domain": "supply-chain", "topic": "Dependency risk", "title": "Triage new dependency vulnerability findings", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/evidence-based-triage/", "platforms": [ "Package ecosystems", "Node.js", "Python", "Go" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "artifact-signature-policy Artifact verification Verify artifact signatures against an explicit trust policy Require the expected artifact, signer and release context before allowing a signed package or image to proceed. Sigstore cosign Signing Trust policy Artifact integrity Admission control Build systems Containers Package ecosystems CWE-347 A03:2025 A08:2025 CAPEC-206 CICD-SEC-9 Sigstore artifact signing signature verification Write down what a valid signature must authorize Authenticate first, then compare exact subject and identity Verify with cosign: identity, issuer and claims Sign and verify keylessly on GitLab Know what the bundle and the transparency log prove Enforce the policy at admission Make verification and deployment one identity-preserving operation Use near misses to prove that the rule is discriminating", "key": "artifact-signature-policy", "domain": "supply-chain", "topic": "Artifact verification", "title": "Verify artifact signatures against an explicit trust policy", "path": "https://softwaresecurity.com/domains/supply-chain/provenance/artifact-signature-policy/", "platforms": [ "Build systems", "Containers", "Package ecosystems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Signed artifact provenance lab: Reject a release from the wrong producer", "path": "https://softwaresecurity.com/labs/artifact-policy/" } ], "projects": [ { "title": "Build and verify a signed software release", "path": "https://softwaresecurity.com/labs/#project-release-verification", "download": "https://softwaresecurity.com/downloads/projects/release-verification-bd914fcbede61c32.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "slsa-provenance Provenance and attestation Read SLSA provenance and verify the claim you need Connect an artifact to its build evidence while distinguishing provenance, build assurance and source controls. SLSA in-toto Provenance Build integrity slsa-verifier Build systems Containers A03:2025 A08:2025 CAPEC-444 CICD-SEC-9 Ask a question that provenance can answer Read the subject, build definition and run details Evaluate the trusted statement against separate predicates Run the same checks with real verifiers Keep the decision reproducible and its claim bounded", "key": "slsa-provenance", "domain": "supply-chain", "topic": "Provenance and attestation", "title": "Read SLSA provenance and verify the claim you need", "path": "https://softwaresecurity.com/domains/supply-chain/provenance/read-and-verify-slsa/", "platforms": [ "Build systems", "Containers" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Build and verify a signed software release", "path": "https://softwaresecurity.com/labs/#project-release-verification", "download": "https://softwaresecurity.com/downloads/projects/release-verification-bd914fcbede61c32.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ci-untrusted-workflows CI/CD trust boundaries Keep untrusted CI work outside the release boundary Review workflow authority, persistent state and artifact handoffs before contributor-controlled code reaches privileged jobs. CI/CD GitHub Actions Script injection workflow_run Cache poisoning Runner isolation GitHub Actions Build systems CWE-829 A03:2025 CAPEC-88 CAPEC-242 CICD-SEC-4 Follow influence across jobs, not just event names Remove ambient and persistent authority Keep event text out of the script: expression injection Pass untrusted values through environment variables Design a narrow data contract for results Fetch the artifact as data in the privileged job Test confidentiality, integrity and persistence separately", "key": "ci-untrusted-workflows", "domain": "supply-chain", "topic": "CI/CD trust boundaries", "title": "Keep untrusted CI work outside the release boundary", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/untrusted-workflow-boundaries/", "platforms": [ "GitHub Actions", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Actions injection lab: Flag GitHub Actions expression injection", "path": "https://softwaresecurity.com/labs/actions-injection/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "package-attack-response Malicious package response Investigate a suspected malicious package safely Distinguish package substitution, publisher compromise and dangerous installation behavior while containing exposure and preserving evidence. Malicious packages Dependency confusion Typosquatting Install scripts Incident response Package analysis Package ecosystems Build systems CWE-506 A03:2025 V15.2.4 CAPEC-538 dependency confusion malicious packages package compromise Establish the suspicious delta before running anything Inspect the package without installing it Stop new execution and remove exposed authority Answer bounded questions with isolated evidence Rebuild the trusted path and state what remains unknown Recognize how malicious packages arrive Harden installs before the next incident", "key": "package-attack-response", "domain": "supply-chain", "topic": "Malicious package response", "title": "Investigate a suspected malicious package safely", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/package-attack-response/", "platforms": [ "Package ecosystems", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "vex-decisions VEX decisions Use VEX without losing vulnerability evidence Produce and consume precise vulnerability status statements tied to the product, version, justification and evidence. VEX OpenVEX CSAF CycloneDX Vulnerability status Trivy Package ecosystems Build systems A03:2025 Keep the detection and the impact assessment separate Map statuses across OpenVEX, CSAF and CycloneDX Make the reason falsifiable for one product Treat authority, scope and freshness as separate checks Apply VEX in Trivy and Grype without hiding other findings Test the events that invalidate the conclusion", "key": "vex-decisions", "domain": "supply-chain", "topic": "VEX decisions", "title": "Use VEX without losing vulnerability evidence", "path": "https://softwaresecurity.com/domains/supply-chain/vex/producer-and-consumer-decisions/", "platforms": [ "Package ecosystems", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "reproducible-builds Reproducible builds Investigate build differences and improve reproducibility Control inputs and environment, compare artifact bytes, and explain the security properties a repeatable build can demonstrate. Reproducibility SOURCE_DATE_EPOCH diffoscope Hermetic builds Build inputs Artifact comparison Build systems Containers Native software A03:2025 Separate reproducibility, isolation and authenticity Record inputs that actually influence the bytes Use the standard levers for each toolchain Package the release deterministically Find and explain the first meaningful divergence Let diffoscope find the divergence Make independence and the comparison claim explicit", "key": "reproducible-builds", "domain": "supply-chain", "topic": "Reproducible builds", "title": "Investigate build differences and improve reproducibility", "path": "https://softwaresecurity.com/domains/supply-chain/builds/reproducibility-and-hermeticity/", "platforms": [ "Build systems", "Containers", "Native software" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "dependency-project-health Project health and intake Review dependency health without treating a score as a guarantee Combine security practices, maintenance, licensing and product exposure into a recorded adoption or replacement decision. OpenSSF Scorecard deps.dev OSS intake Maintenance Provenance License review Package ecosystems Build systems CWE-1104 CWE-1357 A03:2025 V15.1.2 V15.1.4 V15 Assess the dependency in the role it will have Read checks and observations behind the aggregate Collect the evidence with deps.dev, Scorecard and npm Record conditions that can actually be enforced Use change events and expiry instead of a permanent badge", "key": "dependency-project-health", "domain": "supply-chain", "topic": "Project health and intake", "title": "Review dependency health without treating a score as a guarantee", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/project-health-and-intake/", "platforms": [ "Package ecosystems", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "trusted-publishing-updates Publishing and secure updates Protect package publication and the update channel Constrain release identities, verify what consumers receive, and prepare for publisher or update-key compromise. Trusted publishing OIDC npm PyPI TUF Release recovery Package ecosystems Build systems Native software CWE-494 A03:2025 A08:2025 CAPEC-657 Authorize a workflow and close alternative publication paths Publish to npm from GitHub Actions without a token Publish to PyPI with attestations Close the legacy publication paths Bind publication authority to the bytes being released Verify what consumers download Protect freshness and authorized target selection Withdraw trust without losing the incident history", "key": "trusted-publishing-updates", "domain": "supply-chain", "topic": "Publishing and secure updates", "title": "Protect package publication and the update channel", "path": "https://softwaresecurity.com/domains/supply-chain/releases/trusted-publishing-and-updates/", "platforms": [ "Package ecosystems", "Build systems", "Native software" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-program-operations Program operations Run an AppSec program: owners, finding states, deadlines and champions Translate a security baseline into service ownership, change triggers, reusable patterns and evidence that work reaches deployment. AppSec program Ownership Security champions Secure SDLC Engineering organizations Web & APIs Build systems Who is accountable for each service? Which changes should trigger a security review? Which states does a finding move through, and who moves it? How do you enforce the states in code? How do you test the state rules? How should deadlines follow exploitation evidence? How do security champions extend a small team? What should the weekly review look at?", "key": "security-program-operations", "domain": "governance", "topic": "Program operations", "title": "Run an AppSec program: owners, finding states, deadlines and champions", "path": "https://softwaresecurity.com/frameworks/program-operations/", "platforms": [ "Engineering organizations", "Web & APIs", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "asvs-verification-evidence Verification evidence ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat Scope edition-qualified requirements, connect them to implementation and tests, and separate a passing check from an unsupported assurance claim. ASVS 5.0.0 Verification Test evidence Requirements Web & APIs Engineering organizations V1.2.5 ASVS 5.0.0 verification requirements OWASP ASVS What must an ASVS verification record pin down? What's in ASVS 5.0.0? How do you argue from requirement to code to test? What makes an observation reproducible? How do you report a scoped result?", "key": "asvs-verification-evidence", "domain": "governance", "topic": "Verification evidence", "title": "ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat", "path": "https://softwaresecurity.com/frameworks/asvs-verification-evidence/", "platforms": [ "Web & APIs", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Release evidence lab: Keep stale test evidence out of a release decision", "path": "https://softwaresecurity.com/labs/release-evidence/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ssdf-product-lifecycle Secure development frameworks Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026 Connect secure-development practices to an actual product’s work, artifacts and responsibilities instead of a questionnaire full of unsupported yes answers. NIST SSDF SP 800-218 Lifecycle evidence Software attestation Engineering organizations Build systems NIST SSDF SP 800-218 secure development Which SSDF edition should you assess against? What are the SSDF 1.1 practices, and what evidence shows each? What changed for US federal attestation after OMB M-26-05? How do preparation and protection practices produce evidence? How do you follow a defect from design to response? How do you assess each practice claim within the product boundary? How do you check the evidence matrix in CI?", "key": "ssdf-product-lifecycle", "domain": "governance", "topic": "Secure development frameworks", "title": "Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026", "path": "https://softwaresecurity.com/frameworks/ssdf-product-lifecycle/", "platforms": [ "Engineering organizations", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "samm-assessment Maturity assessment Run an OWASP SAMM assessment with evidence and a practical roadmap Use OWASP SAMM to distinguish isolated successes from repeatable practices and choose improvements the organization can sustain. OWASP SAMM Maturity Roadmap Evidence Engineering organizations SAMM OWASP SAMM maturity assessment What must you define before scoring maturity? How is SAMM structured and scored? How do you record answers so they can be checked? How do you compute the scores reproducibly? How do you test a maturity claim against records? Which improvements should you fund first? How do you know the improvement stuck?", "key": "samm-assessment", "domain": "governance", "topic": "Maturity assessment", "title": "Run an OWASP SAMM assessment with evidence and a practical roadmap", "path": "https://softwaresecurity.com/frameworks/samm-assessment/", "platforms": [ "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "risk-exceptions-metrics Risk decisions and measurement Approve, expire and measure security exceptions without hiding risk Keep temporary acceptance separate from remediation and measure outcomes using definitions that survive changing visibility. Risk acceptance Exceptions Metrics Remediation Engineering organizations Web & APIs What must an exception record say? Does the compensating control actually break the attack path? How do you measure exceptions without hiding unresolved risk? What should happen when an exception expires? How do you find expiring exceptions and reset ages automatically?", "key": "risk-exceptions-metrics", "domain": "governance", "topic": "Risk decisions and measurement", "title": "Approve, expire and measure security exceptions without hiding risk", "path": "https://softwaresecurity.com/frameworks/risk-exceptions-and-metrics/", "platforms": [ "Engineering organizations", "Web & APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Gate an image build on a CIS scan and a deviation register", "path": "https://softwaresecurity.com/labs/#project-image-benchmark-gate", "download": "https://softwaresecurity.com/downloads/projects/image-benchmark-gate-b76ad8a05569f566.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "assurance-mapping Control mappings Control mapping between frameworks: state the relationship without overstating equivalence Record exactly how an implementation supports a requirement, which evidence is reusable and which obligations remain unresolved. Control mapping NIST IR 8477 NIST OLIR Evidence Engineering organizations Web & APIs What does a mapping row actually claim? Can one piece of evidence support two requirements? What should a mapping registry record? How do you publish mappings in a machine-readable form? How do you test a mapping before relying on it?", "key": "assurance-mapping", "domain": "governance", "topic": "Control mappings", "title": "Control mapping between frameworks: state the relationship without overstating equivalence", "path": "https://softwaresecurity.com/frameworks/control-mapping-and-evidence/", "platforms": [ "Engineering organizations", "Web & APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "supplier-assurance Supplier assurance Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use Connect supplier claims to product scope, supported versions, release integrity and vulnerability handling before making a procurement decision. Supplier risk Procurement SBOM Assurance evidence Engineering organizations SaaS Package ecosystems What access will the supplier's software get? What does each supplier document establish, and what doesn't it? What should you ask a supplier for? How do you make a purchasing condition testable? How do you verify a supplier's update before it installs? How do you keep supplier access conditional after the contract?", "key": "supplier-assurance", "domain": "governance", "topic": "Supplier assurance", "title": "Supplier software assurance: check SOC 2 reports, SBOMs and signed updates against your use", "path": "https://softwaresecurity.com/frameworks/supplier-software-assurance/", "platforms": [ "Engineering organizations", "SaaS", "Package ecosystems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "product-security-obligations Product obligations Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan Determine the relevant actor, product, market and requirement before connecting CRA or payment-security expectations to implementation work. Cyber Resilience Act Vulnerability reporting PCI DSS Product security Software products Web & APIs Engineering organizations Which obligation applies to which product? What CRA evidence does a product need beyond reporting? Which CRA dates apply now? How do you report an exploited vulnerability or severe incident? What does the CRA require of the product from December 2027? Where is the payment boundary, and who decides the assessment route? What do PCI DSS 6.4.3 and 11.6.1 require for payment pages? How do you join provision, owner and release without claiming legal completion?", "key": "product-security-obligations", "domain": "governance", "topic": "Product obligations", "title": "Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan", "path": "https://softwaresecurity.com/frameworks/product-security-obligations/", "platforms": [ "Software products", "Web & APIs", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "assurance-frameworks Assurance frameworks ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers Distinguish management systems, technical controls, risk outcomes, independent reports and government cloud requirements before reusing evidence. ISO 27001 SOC 2 NIST CSF NIST 800-53 FedRAMP Engineering organizations Cloud services Which assurance question do you need answered? How do the five frameworks compare? What does an ISO 27001 certificate or a SOC 2 report cover? What do NIST CSF 2.0 and SP 800-53 give you, and what don't they? How do you check a FedRAMP route and status in 2026? How do you record what each artifact tells you? What does the register check print?", "key": "assurance-frameworks", "domain": "governance", "topic": "Assurance frameworks", "title": "ISO 27001, SOC 2, NIST CSF or FedRAMP: choose the framework by the question it answers", "path": "https://softwaresecurity.com/frameworks/choosing-assurance-frameworks/", "platforms": [ "Engineering organizations", "Cloud services" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "privacy-regulatory-scope Privacy and regulated data GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls Map data, actors and processing purposes to the relevant GDPR, California or HIPAA requirements and preserve uncertainty about applicability. Privacy GDPR CCPA HIPAA Health data Web & APIs Data services Engineering organizations Which processing facts decide what applies? When does GDPR apply, and what does it say about health data? What do the 2026 CCPA regulations add? When is health data covered by HIPAA? Which rules cover health data outside HIPAA? How do you test a privacy promise while the legal question stays open? How do you keep scope decisions explicit? What does the scope check enforce?", "key": "privacy-regulatory-scope", "domain": "governance", "topic": "Privacy and regulated data", "title": "GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls", "path": "https://softwaresecurity.com/frameworks/privacy-and-health-data-scope/", "platforms": [ "Web & APIs", "Data services", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "oauth-oidc-login Federated login OAuth 2.0 and OpenID Connect login: authorization code with PKCE Implement OAuth 2.0 and OpenID Connect login with the authorization code flow and PKCE, keep each transaction bound to its browser, and block redirect, mix-up, code-injection and token-theft attacks. OAuth 2.0 OpenID Connect PKCE Federated login Single sign-on Web API CWE-601 CWE-346 CWE-294 A07:2025 V10.1.1 V10.2.1 V10.2.2 V10.4.1 V10.4.5 V10.5.1 V10.5.2 V10.5.4 V10 OAuth OIDC OpenID Connect PKCE single sign on SSO The browser carries messages but does not choose what to trust Follow one code flow in order Which OAuth and OIDC attacks does each control stop? Keep the application’s remaining decisions explicit Where should a single-page app keep its tokens? Implement the code flow in Node.js with openid-client Implement the code flow in Python with Authlib and Flask Implement the code flow in Java with Spring Security Reject the wrong transaction while preserving the right one", "key": "oauth-oidc-login", "domain": "identity-crypto", "topic": "Federated login", "title": "OAuth 2.0 and OpenID Connect login: authorization code with PKCE", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/oauth-oidc-login/", "platforms": [ "Web", "API" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "OAuth redirect and PKCE lab: Match redirect URIs and verify PKCE", "path": "https://softwaresecurity.com/labs/oauth-redirect-pkce/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "jwt-validation-rollover Token validation JWT validation: algorithms, keys, claims and key rollover Validate a JWT against a fixed algorithm, trusted keys and the expected issuer, audience and type, reject the known header attacks, and rotate signing keys without accepting arbitrary keys or breaking valid tokens. JWT JWKS Token validation Key rollover OAuth access tokens API Web CWE-347 CWE-290 A07:2025 API2:2023 V9.1.1 V9.1.2 V9.1.3 V9.2.1 V9.2.2 V9.2.3 CAPEC-475 V9 JWT JWKS key rollover JSON web token token verification Decoding is parsing; validation establishes a narrower claim Which JWT attacks must a verifier reject? Make failures bounded and distinguishable internally Verify an access token in Node.js with jose Verify an access token in Python with PyJWT Verify an access token in Java with Spring Security Verify an access token in ASP.NET Core Publish before use and retire after the old acceptance window Exercise key state and token semantics independently Use the real verification projects for a concrete boundary", "key": "jwt-validation-rollover", "domain": "identity-crypto", "topic": "Token validation", "title": "JWT validation: algorithms, keys, claims and key rollover", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/jwt-validation-rollover/", "platforms": [ "API", "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "JWT validation lab: Validate the purpose and audience of a token", "path": "https://softwaresecurity.com/labs/token-validation/" }, { "title": "JWT verification lab: Verify a JWT before trusting it", "path": "https://softwaresecurity.com/labs/jwt-verification/" } ], "projects": [ { "title": "Secure a real HTTP API", "path": "https://softwaresecurity.com/labs/#project-express-api", "download": "https://softwaresecurity.com/downloads/projects/express-api-519f6cf7960d8d96.zip" }, { "title": "Verify tokens through rotation and revocation", "path": "https://softwaresecurity.com/labs/#project-token-lifecycle", "download": "https://softwaresecurity.com/downloads/projects/token-lifecycle-2351d64b881f0c32.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "passkeys-mfa-lifecycle Passkeys and MFA Passkeys and MFA: WebAuthn enrollment, sign-in and replacement Register, verify and replace passkeys with WebAuthn so phishing resistance survives the account’s whole lifecycle, and map passkeys and other MFA methods to the NIST SP 800-63B-4 assurance levels. Passkeys WebAuthn FIDO2 MFA Phishing-resistant authentication Web Mobile CWE-308 CWE-294 CWE-1390 A07:2025 V6.3.3 V6.4.3 V6.5.1 V6.6.1 V6.6.4 V6.7.2 V6 WebAuthn passkeys MFA FIDO2 A passkey proves possession in a relying-party context Registration gives a new device future authority Which authenticators meet AAL2 and AAL3? Consume the challenge and enforce the full assertion Verify registration and sign-in in Node.js with SimpleWebAuthn Verify registration and sign-in in Python with py_webauthn Add passkeys to a Spring Security application Test replacement as carefully as login", "key": "passkeys-mfa-lifecycle", "domain": "identity-crypto", "topic": "Passkeys and MFA", "title": "Passkeys and MFA: WebAuthn enrollment, sign-in and replacement", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/passkeys-mfa-lifecycle/", "platforms": [ "Web", "Mobile" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "account-recovery-linking Account recovery Account recovery: password resets, help-desk resets and account linking Treat password resets, support-desk recovery and account linking as new grants of authority: single-use high-entropy proofs, atomic consumption, session revocation, and stable identity rather than email matching. Account recovery Password reset Account linking Help desk Social engineering Web API CWE-640 CWE-204 A07:2025 API2:2023 V6.3.7 V6.3.8 V6.4.3 V6.4.4 V7.4.3 V11.5.1 CAPEC-50 V6 A recovery channel can become the strongest credential Bind one proof to one action and consume it atomically Create and redeem a reset token in Python Prove both sides of the link Protect help-desk recovery from social engineering Prove replay resistance and scope, not just expiry", "key": "account-recovery-linking", "domain": "identity-crypto", "topic": "Account recovery", "title": "Account recovery: password resets, help-desk resets and account linking", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/account-recovery-linking/", "platforms": [ "Web", "API" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Password reset token lab: Make a recovery credential single-use", "path": "https://softwaresecurity.com/labs/recovery/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "aead-record-design Authenticated encryption AEAD records: AES-GCM nonces, associated data and key limits Build an encrypted record whose tag binds ciphertext to the intended tenant, record, purpose and format, keep nonces unique within each key’s usage limit, and verify the design with actual AES-GCM. Authenticated encryption AEAD AES-GCM Nonces Associated data XChaCha20-Poly1305 ChaCha20-Poly1305 Web API CWE-323 CWE-353 A04:2025 V11.2.1 V11.3.2 V11.3.3 V11.3.4 V11 AEAD AES GCM nonce associated data authenticated encryption Authenticity applies to the inputs you actually authenticate AES-GCM or ChaCha20-Poly1305: which should a record use? A versioned envelope needs one unambiguous interpretation Uniqueness belongs to the key and every writer using it Run the real record-binding repair", "key": "aead-record-design", "domain": "identity-crypto", "topic": "Authenticated encryption", "title": "AEAD records: AES-GCM nonces, associated data and key limits", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/authenticated-record-design/", "platforms": [ "Web", "API" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "AES-GCM nonce reuse lab: Fix a nonce allocator that breaks after restart", "path": "https://softwaresecurity.com/labs/nonces/" } ], "projects": [ { "title": "Bind ciphertext to the correct record", "path": "https://softwaresecurity.com/labs/#project-encrypted-records", "download": "https://softwaresecurity.com/downloads/projects/encrypted-records-0959d731656638c9.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "envelope-encryption-rotation Key lifecycle Envelope encryption and key rotation: data keys, KMS keys and backups Encrypt each record with its own data key, wrap that key in a KMS or HSM key, and keep wrapping-key rotation, data re-encryption, key deletion and restored backups as separate, tested operations. Envelope encryption Key rotation KMS Data keys Crypto-shredding Encryption at rest API Cloud CWE-324 CWE-323 CWE-321 A04:2025 V11.1.1 V11.1.2 V11.3.3 V11.3.4 V13.3.1 V13.3.3 V11 Two key roles create two different rotation operations How should you encrypt data at rest? The record and the key service need matching context How do AWS KMS, Google Cloud KMS and Azure Key Vault handle these operations? Use a resumable state machine rather than a one-shot script Wrap, rewrap and decrypt a record in Python Delete data by destroying its key When do you need an HSM or FIPS 140-3 validation? A retired key must be unnecessary or deliberately retained", "key": "envelope-encryption-rotation", "domain": "identity-crypto", "topic": "Key lifecycle", "title": "Envelope encryption and key rotation: data keys, KMS keys and backups", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/envelope-encryption-rotation/", "platforms": [ "API", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Bind ciphertext to the correct record", "path": "https://softwaresecurity.com/labs/#project-encrypted-records", "download": "https://softwaresecurity.com/downloads/projects/encrypted-records-0959d731656638c9.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "tls-pki-operations TLS and PKI Operate TLS and certificates: configuration, renewal and verification Configure a modern TLS profile with hybrid post-quantum key exchange, automate renewal for certificate lifetimes that fall to 47 days, and verify every termination point with a fresh handshake. TLS PKI Certificates ACME HSTS Post-quantum TLS Web API Cloud CWE-295 CWE-297 CWE-298 CWE-319 A04:2025 V12.1.1 V12.1.2 V12.2.2 V12.3.2 V12.3.4 V3.4.1 CAPEC-94 V12 certificate The certificate authenticates a key in a protocol exchange Make the client and server enforce one intended profile Turn on hybrid post-quantum key exchange Renewal includes deployment and independent observation Plan for 200-, 100- and 47-day certificates Add HSTS, CAA and Certificate Transparency monitoring Verify a server from the command line Test identity failure as well as successful encryption", "key": "tls-pki-operations", "domain": "identity-crypto", "topic": "TLS and PKI", "title": "Operate TLS and certificates: configuration, renewal and verification", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/tls-pki-operations/", "platforms": [ "Web", "API", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "workload-identity-models Workload identity Workload identity federation: short-lived, scoped identities for services and CI Trace how a running workload obtains a short-lived identity, write cloud trust policies that match immutable claims instead of names or wildcards, and keep the resulting credential limited by audience and authorization. Workload identity OIDC federation GitHub Actions SPIFFE CI/CD API Cloud CI/CD CWE-290 V13.2.1 V13.2.2 V13.3.1 V13 SPIFFE workload identity service identity Short lifetimes help only after the issuer identifies the workload Bind issuer assertions to a narrowly defined runtime identity How do AWS, Google Cloud and Azure check a GitHub Actions token? Trust one environment of one repository in AWS Accept a GitHub Actions token in your own service Choose scope, refresh, and outage behavior together Exercise the denied neighboring identities", "key": "workload-identity-models", "domain": "identity-crypto", "topic": "Workload identity", "title": "Workload identity federation: short-lived, scoped identities for services and CI", "path": "https://softwaresecurity.com/domains/identity-crypto/identity/workload-identity-models/", "platforms": [ "API", "Cloud", "CI/CD" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "authorization-models Authorization models Authorization models: RBAC, ABAC, ReBAC and policy as code you can test Translate roles, attributes and relationships into explicit subject-action-resource decisions, prevent broken object level authorization (BOLA), and verify ownership and tenant boundaries with tests. Authorization RBAC ABAC ReBAC BOLA Policy as code Web API Cloud CWE-863 A01:2025 V8.2.1 V8.2.2 V8.2.3 V8.3.1 V8.3.3 V8.4.1 CWE-284 V8 Authentication supplies a subject; authorization evaluates an action Which authorization model fits: RBAC, ABAC or ReBAC? Write the decision before choosing a policy engine Keep checks next to the trusted resource and mutation Express the invoice rules as tested policy in Rego Use a matrix that keeps authentication and authorization distinct", "key": "authorization-models", "domain": "identity-crypto", "topic": "Authorization models", "title": "Authorization models: RBAC, ABAC, ReBAC and policy as code you can test", "path": "https://softwaresecurity.com/domains/identity-crypto/identity/authorization-models/", "platforms": [ "Web", "API", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Secure a real HTTP API", "path": "https://softwaresecurity.com/labs/#project-express-api", "download": "https://softwaresecurity.com/downloads/projects/express-api-519f6cf7960d8d96.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "data-minimization-retention Data lifecycle Data minimization and retention: collect less and prove that deletion works Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit. Data minimization Data retention Deletion Crypto-shredding Backups Web API Cloud CWE-359 CWE-532 V14.1.2 V14.2.6 V14.2.7 V11.7.2 V14 Data you do not collect has no downstream deletion problem Give each field a purpose and each copy an owner Make deletion propagate and survive retries Make deletion reach backups with per-person keys Follow one synthetic subject all the way through", "key": "data-minimization-retention", "domain": "identity-crypto", "topic": "Data lifecycle", "title": "Data minimization and retention: collect less and prove that deletion works", "path": "https://softwaresecurity.com/domains/identity-crypto/privacy/data-minimization-retention/", "platforms": [ "Web", "API", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "tokenization-privacy-engineering Privacy transformations Tokenization, pseudonymization and privacy transformations: choose deliberately Choose between vault tokens, keyed pseudonyms, format-preserving encryption, aggregation and differential privacy by the joins, reversibility and leakage each allows, and test re-identification on the data you release. Tokenization Pseudonymization Format-preserving encryption Differential privacy Data pipelines API Data pipelines CWE-359 CWE-328 V14.1.1 V14.2.4 V14.2.6 Changing identifiers does not necessarily remove identity Pick the transformation that supports only necessary operations Create keyed, purpose-scoped pseudonyms in Python Where do format-preserving encryption and PCI tokenization fit? Inspect the residual fields and the available side information Test intended utility and unwanted linkage", "key": "tokenization-privacy-engineering", "domain": "identity-crypto", "topic": "Privacy transformations", "title": "Tokenization, pseudonymization and privacy transformations: choose deliberately", "path": "https://softwaresecurity.com/domains/identity-crypto/privacy/tokenization-privacy-engineering/", "platforms": [ "API", "Data pipelines" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-inventory-pqc Cryptographic migration Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines Inventory public-key cryptography by operation, owner and lifetime, turn on hybrid ML-KEM key exchange where it is already available, and plan signature and archive migration against the NIST, NSA, NCSC and EU dates. Post-quantum cryptography ML-KEM Cryptographic inventory Hybrid TLS Crypto agility Web API Cloud Embedded CWE-326 A04:2025 V11.1.2 V11.1.3 V11.1.4 V11.2.2 V11.2.3 V11 RSA Inventory the operation, not just the algorithm name Which standards and deadlines apply in 2026? Give every cryptographic use an owner and evidence Inventory what your TLS endpoints negotiate Prioritize by exposure horizon and the slowest dependency What should you do first? Make the inventory support a concrete migration decision", "key": "crypto-inventory-pqc", "domain": "identity-crypto", "topic": "Cryptographic migration", "title": "Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/crypto-inventory-pqc/", "platforms": [ "Web", "API", "Cloud", "Embedded" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "rag-tenant-isolation RAG isolation Keep retrieval inside the user’s data boundary Carry document permissions through ingestion, retrieval, caching and citations so a model never receives another tenant’s records. RAG security Vector databases Multi-tenancy Access control Web API Data pipelines LLM09:2026 V8.2.2 V8.4.1 V14.2.2 Retrieval changes who can see the data Worked retrieval: the final answer is too late to filter Preserve provenance and permissions Constrain every candidate and reuse path Test the assembled context, not only the answer Why post-filtering and opaque embeddings still leak Check the result against concrete cases", "key": "rag-tenant-isolation", "domain": "ai-emerging", "topic": "RAG isolation", "title": "Keep retrieval inside the user’s data boundary", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/rag-tenant-isolation/", "platforms": [ "Web", "API", "Data pipelines" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "RAG access control lab: Stop a retriever from returning another tenant’s documents", "path": "https://softwaresecurity.com/labs/rag-isolation/" } ], "projects": [ { "title": "Enforce retrieval and tool boundaries across crashes", "path": "https://softwaresecurity.com/labs/#project-agent-tool-boundaries", "download": "https://softwaresecurity.com/downloads/projects/agent-tool-boundaries-26b9a352bb160338.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "agent-tool-authorization Agent permissions Authorize agent tools outside the model Bind each proposed action to the user, resource and approved arguments before allowing a tool to cause a side effect. AI agents Tool authorization Excessive agency Human approval API Agent systems CWE-367 LLM03:2026 ASI02:2026 ASI09:2026 V8.3.1 V8.3.2 V15.4.2 A proposed action is not a permission grant Worked payment: approval is a record, not a sentence Build a deterministic execution contract Bind consent to the action that will run Make approvals hard to exploit Test effects under adversarial proposals Why signed approvals and model-supplied tenants still fail Place the gateway where agent standards expect it Check the result against concrete cases", "key": "agent-tool-authorization", "domain": "ai-emerging", "topic": "Agent permissions", "title": "Authorize agent tools outside the model", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/tool-authorization/", "platforms": [ "API", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Excessive agency lab: Bind an agent’s action to the approved arguments", "path": "https://softwaresecurity.com/labs/agent-tool-gateway/" } ], "projects": [ { "title": "Enforce retrieval and tool boundaries across crashes", "path": "https://softwaresecurity.com/labs/#project-agent-tool-boundaries", "download": "https://softwaresecurity.com/downloads/projects/agent-tool-boundaries-26b9a352bb160338.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "untrusted-model-output Output handling Keep generated output out of executable contexts Choose safe rendering and narrow operations so model text cannot become browser code, database syntax or an unrestricted command. LLM security Output handling XSS Markdown rendering Web API Agent systems A05:2025 LLM10:2026 V1 V1.2.4 V1.2.5 V1.3.1 V3.2.2 The dangerous boundary is the downstream consumer Worked output: one value, four different interpreters Make content display intentionally inert Replace free-form execution with bounded choices Supply malicious output directly Why substring filters and a CSP alone are not output handling Check the result against concrete cases", "key": "untrusted-model-output", "domain": "ai-emerging", "topic": "Output handling", "title": "Keep generated output out of executable contexts", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/untrusted-model-output/", "platforms": [ "Web", "API", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "XSS lab: Render a model’s answer as text instead of active markup", "path": "https://softwaresecurity.com/labs/output-rendering/" } ], "projects": [ { "title": "Run model-generated Python in a locked-down container", "path": "https://softwaresecurity.com/labs/#project-agent-code-sandbox", "download": "https://softwaresecurity.com/downloads/projects/agent-code-sandbox-ca88c140c78d6501.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ai-security-evaluation AI evaluation Build evaluations around prohibited outcomes Test the application’s actual security boundaries, preserve legitimate tasks and distinguish deterministic enforcement from variable model behavior. AI evaluation AI red teaming LLM security AI governance Web API Agent systems Evaluate a claim that evidence can answer Worked evaluation: a reassuring answer with a failed ledger check Build paired attack and legitimate-task cases Record the complete tested configuration Turn failures into bounded release decisions Connect the evidence to AI governance frameworks Why judge models and zero-failure runs mislead Check the result against concrete cases", "key": "ai-security-evaluation", "domain": "ai-emerging", "topic": "AI evaluation", "title": "Build evaluations around prohibited outcomes", "path": "https://softwaresecurity.com/domains/ai-emerging/assurance/ai-security-evaluation/", "platforms": [ "Web", "API", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Gate model and provider changes on a versioned red-team corpus", "path": "https://softwaresecurity.com/labs/#project-ai-eval-regression", "download": "https://softwaresecurity.com/downloads/projects/ai-eval-regression-eb82940745d462ec.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ai-red-teaming AI evaluation Red-team LLM applications and agents by their effects A red-teaming method for LLM features and agents: scope the whole system, map attacks to OWASP and MITRE ATLAS identifiers, score trials from observed effects, report rates with confidence intervals and retest on every model or provider change. AI red teaming AI evaluation LLM security Prompt injection Agentic security Excessive agency Unbounded consumption Test evidence API Agent systems CWE-1427 red teaming garak PyRIT promptfoo Inspect MITRE ATLAS canary attack success rate LLM red teaming AI red team agent red teaming eval regression testing Scope the system, not the model Map attacks to OWASP and MITRE ATLAS identifiers Measure effects with canaries, logs and meters Run each case many times and report intervals Use automated tools for breadth Point the tools at the system, and pin their versions Run human red-team exercises for depth Report findings so they can be fixed and retested Verify fixes and retest on every model or provider change Worked example: an upgrade that looks safer and is not What a red-team result can and cannot show", "key": "ai-red-teaming", "domain": "ai-emerging", "topic": "AI evaluation", "title": "Red-team LLM applications and agents by their effects", "path": "https://softwaresecurity.com/domains/ai-emerging/assurance/ai-red-teaming/", "platforms": [ "API", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Gate model and provider changes on a versioned red-team corpus", "path": "https://softwaresecurity.com/labs/#project-ai-eval-regression", "download": "https://softwaresecurity.com/downloads/projects/ai-eval-regression-eb82940745d462ec.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ai-cost-memory-operations AI operations Bound agent spending, memory and recovery Enforce budgets and stop conditions outside the model, and make retained context and side effects recoverable. AI agents Unbounded consumption Cost controls Agent memory API Agent systems Cloud LLM06:2026 V15.4.2 One request can become a long-running workload Worked budget: two children spend the same remaining balance Reserve and enforce resources before work starts Treat retained context as governed data Test stop, retry and resume semantics Why early releases and memory deletion are not recovery Check the result against concrete cases", "key": "ai-cost-memory-operations", "domain": "ai-emerging", "topic": "AI operations", "title": "Bound agent spending, memory and recovery", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/cost-memory-operations/", "platforms": [ "API", "Agent systems", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "model-artifact-security Model supply chain Treat model releases as executable supply-chain inputs Verify provenance, constrain loading and preserve the relationship between model weights, configuration and runtime dependencies. AI supply chain Model loading Safetensors Model signing Data pipelines Cloud Desktop LLM04:2026 V1.5.2 V15.2.4 V15.2.5 A model package contains more than weights Worked release: unchanged weights, changed executable loader Separate retrieval from execution Test loading in a constrained environment Record provenance in a machine-readable form Test integrity and useful behavior independently Why a clean sandbox run and one file hash miss the release Check the result against concrete cases", "key": "model-artifact-security", "domain": "ai-emerging", "topic": "Model supply chain", "title": "Treat model releases as executable supply-chain inputs", "path": "https://softwaresecurity.com/domains/ai-emerging/ml-security/model-artifact-security/", "platforms": [ "Data pipelines", "Cloud", "Desktop" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "training-data-poisoning Data poisoning Protect training and retrieval data from targeted poisoning Track who can influence datasets, keep evaluation independent and investigate targeted behavior changes without relying on aggregate accuracy. Data poisoning AI supply chain Model evaluation Data lineage Data pipelines Cloud LLM05:2026 Poisoning changes what the system learns or retrieves Worked candidate: aggregate accuracy hides a targeted regression Make input authority and provenance visible Keep the yardstick independent Contain the affected version and its descendants Why schema checks and deleting the class are not fixes Check the result against concrete cases", "key": "training-data-poisoning", "domain": "ai-emerging", "topic": "Data poisoning", "title": "Protect training and retrieval data from targeted poisoning", "path": "https://softwaresecurity.com/domains/ai-emerging/ml-security/training-data-poisoning/", "platforms": [ "Data pipelines", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "model-privacy-attacks Model privacy Assess extraction, membership and inference risks Define what an adversary can observe and measure privacy leakage without confusing a model’s output with proof about its training data. Model privacy Membership inference Training data extraction Differential privacy API Data pipelines CWE-359 LLM02:2026 Separate the privacy questions Worked membership claim: distinguish correct guesses from false accusations Inventory exposure and collection choices Use controlled data and an explicit baseline Match the control to the observed cause Why tuned thresholds and live sensitive records mislead Check the result against concrete cases", "key": "model-privacy-attacks", "domain": "ai-emerging", "topic": "Model privacy", "title": "Assess extraction, membership and inference risks", "path": "https://softwaresecurity.com/domains/ai-emerging/ml-security/model-privacy-attacks/", "platforms": [ "API", "Data pipelines" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "mcp-multiagent-security MCP and multi-agent systems Constrain MCP and multi-agent trust boundaries Validate each connection and delegated action without treating a token for another service, a tool description, another agent or a state handle as authority. MCP security AI agents OAuth Tool poisoning Multi-agent systems API Agent systems CWE-441 ASI03:2026 ASI07:2026 ASI04:2026 V10.2.2 V10.3.1 V10.3.3 V10.4.1 V8.2.2 A connected tool is a new trust boundary Worked delegation: a helper asks a more privileged parent to export Validate the audience on the server and the issuer on the client Harden the client against a malicious server Ask for consent per client when your server proxies another API Bind state handles to the verified user Keep permission checks near execution Pin tool definitions and keep servers apart Treat servers, tools and other agents as supply-chain inputs Launch local servers with consent and a sandbox Test compromised inputs without real side effects Why handles, annotations and parent identity are not authority Check the result against concrete cases", "key": "mcp-multiagent-security", "domain": "ai-emerging", "topic": "MCP and multi-agent systems", "title": "Constrain MCP and multi-agent trust boundaries", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/mcp-multiagent-security/", "platforms": [ "API", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Enforce retrieval and tool boundaries across crashes", "path": "https://softwaresecurity.com/labs/#project-agent-tool-boundaries", "download": "https://softwaresecurity.com/downloads/projects/agent-tool-boundaries-26b9a352bb160338.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "agent-failure-containment Agent containment Contain cascading failures and rogue agents Stop a looping, compromised or drifting agent from spreading harm: kill switches, budget and rate limits, circuit breakers, behavior monitoring, blast-radius limits, quarantine, rollback and incident response, all enforced outside the agent. AI agents Cascading failures Rogue agents Multi-agent systems Incident response Circuit breakers Agent systems Python ASI08:2026 ASI10:2026 V2.4.1 V8.3.2 V16.4.3 V16.5.2 kill switch circuit breaker blast radius rogue agents quarantine runaway agent agent loop Two ways one agent’s fault becomes everyone’s problem Worked incident: a support agent loops on account credits Run every limit in the gateway, before the tool Build a kill switch that works when the agent will not cooperate Set budget, step, rate and delegation limits Break circuits between agents and their dependencies Limit the blast radius before anything goes wrong Monitor behavior against a declared manifest Put people at the irreversible steps Quarantine the agent and roll back its effects Run incident response for agent misbehavior Why prompts, self-reports and shared monitors do not contain Check the result against concrete cases", "key": "agent-failure-containment", "domain": "ai-emerging", "topic": "Agent containment", "title": "Contain cascading failures and rogue agents", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/agent-failure-containment/", "platforms": [ "Agent systems", "Python" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ai-governance-regulation AI governance Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence What the NIST AI RMF and its Generative AI Profile, ISO/IEC 42001 and the EU AI Act, as amended in 2026, ask of teams that build AI features, turned into engineering practices and one set of evidence. Not legal advice. AI governance EU AI Act NIST AI RMF NIST AI 600-1 ISO/IEC 42001 EU regulation Software products Engineering organizations Agent systems EU AI Act AI Act AI RMF ISO/IEC 42001 Digital Omnibus ISO 42001 high-risk AI system Which of the three applies to your team? What does the EU AI Act ask, by role and risk class? What do the high-risk requirements mean in engineering terms? What do the transparency duties need from your product? How do you use the NIST AI RMF and the Generative AI Profile? What does ISO/IEC 42001 certification look at? How do the three line up for one engineering practice? How do you keep the evidence once, for all three? What does the register check do? Where do the AI Act changes and standards stand? What this guide does not decide", "key": "ai-governance-regulation", "domain": "ai-emerging", "topic": "AI governance", "title": "Turn NIST AI RMF, ISO/IEC 42001 and EU AI Act duties into engineering evidence", "path": "https://softwaresecurity.com/domains/ai-emerging/governance/ai-governance-regulation/", "platforms": [ "Software products", "Engineering organizations", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "smart-contract-invariants Smart-contract security Test smart contracts through state invariants Define the properties funds and privileges must preserve, then exercise callbacks, transaction sequences and exceptional conditions locally. Smart-contract security Reentrancy Solidity Invariant testing Smart contracts CWE-1265 CWE-841 A correct transaction can hide an unsafe sequence Worked ledger: a callback spends the same credit twice See the vulnerable ordering Identify where authority or accounting changes Combine examples, sequences and adversarial receivers Extend the model to real dependencies Why revert-only tests and unreached harnesses pass broken code Check the result against concrete cases", "key": "smart-contract-invariants", "domain": "appsec", "topic": "Smart-contract security", "title": "Test smart contracts through state invariants", "path": "https://softwaresecurity.com/domains/appsec/smart-contracts/security-invariants/", "platforms": [ "Smart contracts" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "http-request-desynchronization HTTP request framing and desynchronization Keep HTTP request boundaries consistent across intermediaries Trace framing disagreements, reject ambiguous requests and verify what reaches the origin with a real loopback proxy project. Request smuggling HTTP desync CWE-444 Content-Length Transfer-Encoding HTTP/2 nginx HTTP/1.1 Reverse proxy Node.js CDN CWE-444 A06:2025 API8:2023 V4.2.1 V4.2.2 V4.2.3 CAPEC-33 V4 The boundary itself is a security decision Count the supplied bytes before discussing a fix Recognize the desync variants Reject framing at the parser; reject ambiguous authority before use Remove HTTP/1.1 from the proxy-to-origin hop Run the real proxy and origin Verify the deployed chain and keep its configuration explainable Evidence that distinguishes a repair from blanket rejection Use the project as a mechanism test", "key": "http-request-desynchronization", "domain": "runtime", "topic": "HTTP request framing and desynchronization", "title": "Keep HTTP request boundaries consistent across intermediaries", "path": "https://softwaresecurity.com/domains/runtime/edge-defense/http-request-desynchronization/", "platforms": [ "HTTP/1.1", "Reverse proxy", "Node.js", "CDN" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a real proxy and shared cache", "path": "https://softwaresecurity.com/labs/#project-proxy-cache-boundaries", "download": "https://softwaresecurity.com/downloads/projects/proxy-cache-boundaries-66af6733aa29700d.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "cache-poisoning-deception Shared-cache security Prevent shared-cache poisoning and private-response deception Define lookup and storage policy, trace cache/origin interpretation differences and verify both public reuse and private isolation. Cache poisoning Cache deception CWE-524 Cache-Control Vary nginx Tenant isolation HTTP CDN Reverse proxy Node.js CWE-524 API8:2023 V14.2.2 V14.2.5 CAPEC-141 V14 A shared hit releases data without asking the origin again Three collisions with different repairs Separate eligibility, identity and reuse Configure the shared cache: an nginx example Reproduce the leak and repair both directions Make cache and origin interpretation agree Test a cold cache, a warm cache and recovery Retain these route-specific outcomes Separate a useful project from production evidence", "key": "cache-poisoning-deception", "domain": "runtime", "topic": "Shared-cache security", "title": "Prevent shared-cache poisoning and private-response deception", "path": "https://softwaresecurity.com/domains/runtime/edge-defense/cache-poisoning-deception/", "platforms": [ "HTTP", "CDN", "Reverse proxy", "Node.js" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a real proxy and shared cache", "path": "https://softwaresecurity.com/labs/#project-proxy-cache-boundaries", "download": "https://softwaresecurity.com/downloads/projects/proxy-cache-boundaries-66af6733aa29700d.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "bounded-json-xml-parsing Safe deserialization and XML processing Parse bounded JSON and XML into an explicit application schema Separate parser capabilities from schema rules, reject ambiguous and coercible inputs, and implement the boundary in a complete Python project. Deserialization XML XXE CWE-611 CWE-502 Input validation Duplicate keys Parser limits Python JSON XML Expat CWE-20 CWE-502 CWE-611 CWE-776 A05:2025 A08:2025 V1.5.1 V1.5.2 V1.5.3 V2.2.1 V1 V2 Parsing produces meaning, not permission Define a small vocabulary with quantitative bounds Preserve ambiguity long enough to reject it Exclude unused parser capabilities at the parser boundary Run and repair the complete parser project Do not confuse a partial fix with the contract Use reason-specific results Know where this implementation stops", "key": "bounded-json-xml-parsing", "domain": "appsec", "topic": "Safe deserialization and XML processing", "title": "Parse bounded JSON and XML into an explicit application schema", "path": "https://softwaresecurity.com/domains/appsec/input-handling/bounded-json-xml-parsing/", "platforms": [ "Python", "JSON", "XML", "Expat" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "XXE lab: Parse an uploaded invoice without resolving external entities", "path": "https://softwaresecurity.com/labs/xxe-lxml/" }, { "title": "Pickle deserialization lab: Load a session token without pickle", "path": "https://softwaresecurity.com/labs/pickle-deserialization/" } ], "projects": [ { "title": "Parse bounded JSON and XML invoices safely", "path": "https://softwaresecurity.com/labs/#project-bounded-data-parsing", "download": "https://softwaresecurity.com/downloads/projects/bounded-data-parsing-aa166a936b50b8b5.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "saml-verification-boundaries Enterprise SSO SAML single sign-on: verify signed assertions without losing the identity boundary Bind a validated SAML assertion to its trusted issuer, the exact signed element, your service, the browser request and a replay record before creating a local session, and keep your SAML library ahead of its advisories. SAML 2.0 Single sign-on XML signature Signature wrapping Replay Web Enterprise CWE-347 CWE-290 CWE-294 A07:2025 V6.8.1 V6.8.2 V6.8.3 V6 Choose an explicit SSO contract Use the identity element the library actually verified Which SAML library vulnerabilities should you check for? Check where, when and in response to what Configure a Node.js service provider with node-saml Map the federation identity to current local authority Test changes to trust as carefully as login Keep protocol and application failures distinguishable", "key": "saml-verification-boundaries", "domain": "identity-crypto", "topic": "Enterprise SSO", "title": "SAML single sign-on: verify signed assertions without losing the identity boundary", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/saml-verification-boundaries/", "platforms": [ "Web", "Enterprise" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Prove deprovisioning reaches sessions and queued work", "path": "https://softwaresecurity.com/labs/#project-identity-lifecycle", "download": "https://softwaresecurity.com/downloads/projects/identity-lifecycle-510849ac517b9ec2.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "scim-provisioning-deprovisioning Enterprise provisioning SCIM deprovisioning: make account disablement remove every usable authority Connect SCIM resource updates to current sessions, tokens, group-derived permissions and background jobs, with explicit tenant mapping, CAEP revocation events and a measurable revocation contract. SCIM 2.0 Provisioning Deprovisioning Shared Signals and CAEP Revocation API Enterprise CWE-613 V7.4.2 V8.3.2 V8.4.1 Treat provisioning as a separate security boundary Choose the tenant from the authenticated connector Implement SCIM operations with their own semantics Define the local transition that disables authority How do other services learn that access has ended? Handle retries and stale state without inventing protocol guarantees Prove disable from the user’s remaining entry points Run the durable lifecycle model", "key": "scim-provisioning-deprovisioning", "domain": "identity-crypto", "topic": "Enterprise provisioning", "title": "SCIM deprovisioning: make account disablement remove every usable authority", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/scim-provisioning-deprovisioning/", "platforms": [ "API", "Enterprise" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Prove deprovisioning reaches sessions and queued work", "path": "https://softwaresecurity.com/labs/#project-identity-lifecycle", "download": "https://softwaresecurity.com/downloads/projects/identity-lifecycle-510849ac517b9ec2.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "prototype-pollution-boundaries Prototype pollution Keep untrusted object keys out of prototype and authority paths Trace an actual nested-merge mutation, replace it with a narrow schema, and make authorization independent of inherited properties. JavaScript Prototype pollution CWE-1321 Input validation Authorization Node.js Web CWE-1321 V15.3.6 V15.3.3 V15 Follow both the write and the later read Parsing the JSON is not the mutation Replace the generic merge with the product’s actual update contract Use a dictionary when keys really are arbitrary data Require a current, own, explicitly typed grant Know what pollution can reach, and what hardening covers A real-world failure Test the boundaries independently", "key": "prototype-pollution-boundaries", "domain": "appsec", "topic": "Prototype pollution", "title": "Keep untrusted object keys out of prototype and authority paths", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/prototype-pollution-boundaries/", "platforms": [ "Node.js", "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Stop prototype pollution at merge and authorization boundaries", "path": "https://softwaresecurity.com/labs/#project-prototype-pollution", "download": "https://softwaresecurity.com/downloads/projects/prototype-pollution-2ef4d5a55b001cfe.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "android-secure-coding Harden an Android app's storage, network and entry points Encrypt local secrets with Android Keystore keys now that Jetpack Security is deprecated, set transport policy in Network Security Configuration, close exported components and mutable PendingIntents, confine WebViews, verify App Links and judge Play Integrity verdicts on the server, mapped to OWASP MASVS 2.1. Android Kotlin Android Keystore Network Security Configuration Intents and PendingIntents WebView App Links OWASP MASVS CWE-312 CWE-319 CWE-295 CWE-926 CWE-927 CWE-749 CWE-939 CWE-532 MASVS-STORAGE-1 MASVS-STORAGE-2 MASVS-CRYPTO-1 MASVS-CRYPTO-2 MASVS-AUTH-2 MASVS-AUTH-3 MASVS-NETWORK-1 MASVS-NETWORK-2 MASVS-PLATFORM-1 MASVS-PLATFORM-2 MASVS-PLATFORM-3 MASVS-CODE-1 MASVS-CODE-4 MASVS-RESILIENCE-1 MASVS-RESILIENCE-2 Map each MASVS 2.1 control to an Android mechanism Encrypt secrets with a Keystore key Migrate off EncryptedSharedPreferences Bind step-up authentication to a key, not a callback Keep data out of backups, logs, screenshots and the clipboard Set transport policy in Network Security Configuration Pin only keys you can rotate Export only the components other apps must reach Make PendingIntents explicit and immutable Confine WebViews to content you control Verify App Links and validate every parameter Judge Play Integrity verdicts on your server A real-world failure Test the release build like an attacker", "key": "android-secure-coding", "domain": "appsec", "topic": "Harden an Android app's storage, network and entry points", "title": "Harden an Android app's storage, network and entry points", "path": "https://softwaresecurity.com/domains/appsec/platform-security/android-secure-coding/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair an Android app's links, components, network policy and storage", "path": "https://softwaresecurity.com/labs/#project-android-platform-boundaries", "download": "https://softwaresecurity.com/downloads/projects/android-platform-boundaries-52934d7ed9eeeff3.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "business-logic-flaws Prevent business-logic flaws with server-side invariants Recompute prices on the server, run workflows as state machines, build reset links from configuration, limit valuable flows, and turn each business rule into an invariant that the database and the tests both check. Business logic Price tampering Workflow bypass Password reset poisoning Anti-automation Invariants Property-based testing CWE-472 CWE-602 CWE-1284 CWE-839 CWE-837 CWE-841 CWE-640 CWE-799 A06:2025 API6:2023 V2.2 V2.3 V2.4 V6.4 CAPEC-162 CAPEC-74 CAPEC-50 CAPEC-212 Valid requests that break the business rules Price and quantity tampering Fix: recompute every amount from server data Coupons, refunds and the database as the last check Run workflows as server-side state machines Password reset poisoning Fix: configured origin, one address, stored recipient Limit sensitive business flows (API6:2023) Write invariants down, then let tests attack them Pitfalls", "key": "business-logic-flaws", "domain": "appsec", "topic": "Prevent business-logic flaws with server-side invariants", "title": "Prevent business-logic flaws with server-side invariants", "path": "https://softwaresecurity.com/domains/appsec/business-logic/business-logic-flaws/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Business logic lab: Price an order without trusting the client", "path": "https://softwaresecurity.com/labs/coupon-limits/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-log4shell Case study: Log4Shell (CVE-2021-44228) How a JNDI lookup in Apache Log4j became internet-wide remote code execution, why transitive and shaded dependencies made it so hard to patch, which mitigations held, and what it teaches about dependency inventory and SBOMs. Log4Shell Log4j JNDI injection Transitive dependencies SBOM Vulnerability response Remote code execution CWE-674 CWE-1104 CAPEC-137 CAPEC-242 CVE-2021-44228 CVE-2021-45046 CVE-2021-45105 CVE-2021-44832 A single log call became remote code execution How a log message reached JNDI Why nearly everything was exploitable Why patching was hard The disclosure race and the follow-up CVEs Mitigations that worked and ones that did not Find it in running systems, not just package lists Corroborate presence with an advisory query Which controls would have stopped or limited it? Lessons: inventory, SBOM, and a rehearsed response Verify the fix and keep it from regressing Ban the vulnerable range in the build What the public evidence does not establish", "key": "case-study-log4shell", "domain": "appsec", "topic": "Case study: Log4Shell (CVE-2021-44228)", "title": "Case study: Log4Shell (CVE-2021-44228)", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/case-study-log4shell/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crlf-header-log-injection Prevent CRLF header injection, log forging and CSV formula injection Carriage return and line feed separate HTTP header fields, log records and CSV rows, and a leading = turns a spreadsheet cell into a formula. Let the framework write headers, log structured JSON, and neutralize formula triggers in exports. CRLF injection HTTP response splitting Header injection Log injection Log forging CSV injection Formula injection nginx CWE-93 CWE-113 CWE-117 CWE-1236 A05:2025 V1.2 V4.2 V16.4 CAPEC-34 CAPEC-105 CAPEC-93 CAPEC-81 CR and LF are record separators Header injection and response splitting What current stacks do with CR and LF The common modern case: decoded variables in nginx Fix: let the framework encode, and allowlist what you echo Log injection and log forging CSV and formula injection Library switches for CSV XLSX is not automatically safe Pitfalls Verify on the wire, in the log sink and in the file", "key": "crlf-header-log-injection", "domain": "appsec", "topic": "Prevent CRLF header injection, log forging and CSV formula injection", "title": "Prevent CRLF header injection, log forging and CSV formula injection", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/crlf-header-log-injection/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "devsecops-pipeline Place each security control in the pipeline and decide what it blocks Put secrets scanning, SAST, SCA, IaC and image scanning, DAST, fuzzing, attestation and admission control where each sees the right input, block only on findings a developer can act on, and deploy only images the pipeline has attested. DevSecOps CI/CD GitHub Actions SAST Software composition analysis DAST Fuzzing Admission control CWE-798 CWE-1395 CWE-1104 V13.3 V15.1 V15.2 Put each control where it gets the right input Know what each category finds and misses Block on findings that are new, confident and fixable Make every exception specific, explained and temporary Stop secrets before they leave the laptop Write rules for your own invariants and test them Example pipeline for GitHub Actions Run DAST against the image you built Fuzz parsers briefly per pull request and longer at night Attest the exact digest and verify it before it runs Treat the pipeline and its scanners as production systems Choose tools by evidence from your own code Avoid the pitfalls that make pipelines noisy or hollow", "key": "devsecops-pipeline", "domain": "appsec", "topic": "Place each security control in the pipeline and decide what it blocks", "title": "Place each security control in the pipeline and decide what it blocks", "path": "https://softwaresecurity.com/domains/appsec/testing/devsecops-pipeline/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a security pipeline for GitHub Actions and GitLab CI", "path": "https://softwaresecurity.com/labs/#project-security-pipeline", "download": "https://softwaresecurity.com/downloads/projects/security-pipeline-365c6d54e88d6c1c.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "appsec-tool-categories-and-evaluation Choose and evaluate application security testing tools What SAST, DAST, IAST, SCA, secrets, IaC, container and API scanners and ASPM each find and miss, where each runs, how to evaluate them on a seeded repository with per-CWE scoring and triage cost, and which to adopt first. SAST DAST IAST SCA Secrets scanning IaC scanning Container scanning API security testing ASPM OWASP Benchmark Tool evaluation False positives CI/CD Web APIs Python Containers Terraform V15.1 V15.2 SAST DAST IAST SCA ASPM OWASP Benchmark secrets scanning security testing tools application security testing What each category finds and misses What the tools found in a seeded repository What the run teaches about evaluating tools Run your own evaluation in six steps Score SARIF results against the answer key Seed flaws with safe twins Reproduce the runs Decide what to adopt first Pitfalls", "key": "appsec-tool-categories-and-evaluation", "domain": "appsec", "topic": "Choose and evaluate application security testing tools", "title": "Choose and evaluate application security testing tools", "path": "https://softwaresecurity.com/domains/appsec/testing/appsec-tool-categories-and-evaluation/", "platforms": [ "CI/CD", "Web", "APIs", "Python", "Containers", "Terraform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a security pipeline for GitHub Actions and GitLab CI", "path": "https://softwaresecurity.com/labs/#project-security-pipeline", "download": "https://softwaresecurity.com/downloads/projects/security-pipeline-365c6d54e88d6c1c.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "dom-xss-postmessage Prevent DOM XSS, postMessage abuse and client-side injection Trace attacker-controlled values from the URL, messages and storage to the browser APIs that parse HTML or run code, then close those sinks with safe APIs, a sanitizer, Trusted Types and strict message checks. DOM XSS Trusted Types postMessage DOM clobbering Client-side template injection DOMPurify JavaScript frameworks CWE-346 A05:2025 V1.2 V1.3 V3.2 V3.5 CAPEC-588 CAPEC-63 DOM XSS happens entirely in the browser Know the sources, replace the sinks Fix: keep data as text, functions and checked URLs Framework escape hatches Enforce Trusted Types so missed sinks fail closed postMessage: an origin check that isn't one Check origin, source and shape before acting DOM clobbering: markup that answers your lookups Client-side template injection in AngularJS Find sinks in code and prove fixes in a browser Pitfalls", "key": "dom-xss-postmessage", "domain": "appsec", "topic": "Prevent DOM XSS, postMessage abuse and client-side injection", "title": "Prevent DOM XSS, postMessage abuse and client-side injection", "path": "https://softwaresecurity.com/domains/appsec/browser-security/dom-xss-postmessage/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ios-secure-coding Harden an iOS app's storage, network and entry points Store secrets in the Keychain with the narrowest accessibility class, set file protection explicitly, keep App Transport Security on, prefer universal links, constrain WKWebView bridges, keep step-up keys in the Secure Enclave, verify App Attest on the server and ship an accurate privacy manifest, mapped to OWASP MASVS 2.1. iOS Swift Keychain App Transport Security Universal links WKWebView App Attest OWASP MASVS CWE-312 CWE-319 CWE-295 CWE-939 CWE-940 CWE-749 CWE-532 CWE-602 MASVS-STORAGE-1 MASVS-STORAGE-2 MASVS-CRYPTO-1 MASVS-CRYPTO-2 MASVS-AUTH-2 MASVS-AUTH-3 MASVS-NETWORK-1 MASVS-NETWORK-2 MASVS-PLATFORM-1 MASVS-PLATFORM-2 MASVS-PLATFORM-3 MASVS-CODE-4 MASVS-RESILIENCE-1 MASVS-RESILIENCE-2 MASVS-PRIVACY-1 MASVS-PRIVACY-3 Map each MASVS 2.1 control to an iOS mechanism Store secrets in the Keychain with the narrowest class Set file protection explicitly Keep secrets out of logs, snapshots, the pasteboard and caches Keep App Transport Security on Pin with NSPinnedDomains only when you can rotate Prefer universal links and validate every URL Constrain WKWebView and its message handlers Bind step-up to a Secure Enclave key Prove app integrity with App Attest and check it on the server Ship an accurate privacy manifest A real-world failure Check the shipped bundle and a real device", "key": "ios-secure-coding", "domain": "appsec", "topic": "Harden an iOS app's storage, network and entry points", "title": "Harden an iOS app's storage, network and entry points", "path": "https://softwaresecurity.com/domains/appsec/platform-security/ios-secure-coding/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Keep an iOS app's storage, links and web bridge in bounds", "path": "https://softwaresecurity.com/labs/#project-ios-platform-boundaries", "download": "https://softwaresecurity.com/downloads/projects/ios-platform-boundaries-5d4c4cd9417f9c64.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "memory-safety-c-cpp Find, fix and contain memory-safety bugs in C and C++ Recognize out-of-bounds access, use after free, NULL dereference and integer overflow in C and C++, fix them with checked lengths and single ownership, harden release builds, catch the rest with sanitizers and fuzzing, and plan new code in a memory-safe language. Memory safety C and C++ Buffer overflow Use after free Compiler hardening Sanitizers Fuzzing Memory-safe languages CWE-787 CWE-125 CWE-416 CWE-120 CWE-121 CWE-122 CWE-476 CWE-190 V1.4 CAPEC-100 CAPEC-540 CAPEC-92 Know what each memory bug gives an attacker Vulnerable: three functions that trust their input Fixed: check what arrived, check the arithmetic, clear the owner Write the hostile input down as a test Follow rules that remove whole bug classes In C++, let types carry the bounds and the owner Harden release builds with the OpenSSF baseline Apply the flags in one place Check the binary you ship, not the build script Run sanitizers in separate test builds Fuzz every parser with the sanitizers attached Plan the move to memory-safe languages Start with new code and untrusted-input parsers Pitfalls", "key": "memory-safety-c-cpp", "domain": "appsec", "topic": "Find, fix and contain memory-safety bugs in C and C++", "title": "Find, fix and contain memory-safety bugs in C and C++", "path": "https://softwaresecurity.com/domains/appsec/platform-security/memory-safety-c-cpp/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Buffer over-read lab: Stop a heartbeat over-read", "path": "https://softwaresecurity.com/labs/heartbeat-bounds/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "nosql-ldap-xpath-injection Prevent NoSQL, LDAP, XPath and expression-language injection SQL is not the only query language that receives user input. Stop MongoDB operator injection with type checks and $eq, escape LDAP filter values, pass XPath values as variables, and never evaluate SpEL or OGNL built from request data. NoSQL injection MongoDB LDAP injection XPath injection Expression language injection SpEL OGNL Input validation CWE-943 CWE-90 CWE-643 CWE-1287 A05:2025 V1.2 V1.3 V15.3 CAPEC-676 CAPEC-136 CAPEC-83 Each query language needs its own boundary MongoDB: the attack is the value's type, not a quote Fix: require a string, then compare with $eq Turn off JavaScript inside the database LDAP: escape filter values with the library function Authenticate with search-then-bind and refuse empty passwords XPath: pass values as variables Expression languages: never evaluate request data Pitfalls that reopen the hole Verify against the real engines", "key": "nosql-ldap-xpath-injection", "domain": "appsec", "topic": "Prevent NoSQL, LDAP, XPath and expression-language injection", "title": "Prevent NoSQL, LDAP, XPath and expression-language injection", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/nosql-ldap-xpath-injection/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "SSTI lab: Render a welcome banner without template injection", "path": "https://softwaresecurity.com/labs/template-injection-jinja/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "open-redirect Redirect users only to destinations you control Check every redirect target taken from a request, so attackers cannot borrow your domain for phishing, carry OAuth tokens off-site or steer a server-side fetcher through your redirects. Open redirect CWE-601 URL validation OAuth Phishing SSRF CWE-601 A01:2025 WSTG-CLNT-04 open redirect unvalidated redirect An open redirect lends your domain to someone else's link Phishing with your login page as the lure Find every redirect sink, not just the login page OAuth: an open redirect on the client leaks tokens Chained with SSRF or a client-side redirect Why string checks fail Accept only same-origin paths (Node.js) The same rule in Python The same rule in Java and Spring Off-site destinations: IDs or exact origins Use framework helpers, and know what they check Pitfalls A real-world failure Test every redirect sink with bypass payloads", "key": "open-redirect", "domain": "appsec", "topic": "Redirect users only to destinations you control", "title": "Redirect users only to destinations you control", "path": "https://softwaresecurity.com/domains/appsec/secure-features/open-redirect/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Open redirect lab: Return users to this site only", "path": "https://softwaresecurity.com/labs/safe-redirect/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "redos-input-validation Validate input safely and prevent regex denial of service Find and fix exponential and quadratic regex backtracking with measured examples, choose linear-time engines or timeouts, and build allowlist validation that decodes once and rejects type confusion and parameter pollution. ReDoS Regular expressions Input validation RE2 Catastrophic backtracking HTTP parameter pollution Schema validation Unicode normalization CWE-1333 CWE-1287 CWE-777 CWE-180 CWE-235 V1.1 V1.2 V1.3 V2.2 V15.3 CAPEC-492 CAPEC-460 CAPEC-267 CAPEC-71 See why a short string can stall a server Don't rely on one engine's optimizations Find the risky shapes before attackers do Spot the ambiguous pattern Rewrite the pattern so each input matches one way Keep a near-miss input in the test suite Match the whole value in Python Use a linear-time engine where the pattern allows it Set NonBacktracking or a timeout in .NET Know what can interrupt a running match Never compile user input as a pattern Validate against an allowlist, in the right order Decide what a repeated parameter means Reject arrays, objects and loose type coercion Parse requests with a strict schema Turn off coercion in Pydantic", "key": "redos-input-validation", "domain": "appsec", "topic": "Validate input safely and prevent regex denial of service", "title": "Validate input safely and prevent regex denial of service", "path": "https://softwaresecurity.com/domains/appsec/input-handling/redos-input-validation/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "rust-unsafe-ffi Audit unsafe Rust, FFI boundaries and crate dependencies Know what the Rust compiler proves and what it leaves to you: review unsafe code for soundness, wrap foreign calls in small safe functions, decide how overflow and panics behave in release builds, gate crates with RustSec, and replace C one boundary at a time. Rust Unsafe code FFI Miri Integer overflow Panics RustSec Supply chain CWE-758 CWE-762 CWE-190 CWE-617 CWE-1395 V1.4 V15.1 V15.2 CAPEC-538 CAPEC-100 Know what safe Rust guarantees and what it leaves to you Treat every unsafe block as a proof you write down Vulnerable: a safe method that exposes undefined behavior Fixed: validate once, then expose only checked access Make the compiler enforce the review rules Test unsafe code under Miri and FFI under a sanitizer Vulnerable: an FFI wrapper with three lifetime mistakes Fixed: one safe wrapper per foreign function Expose Rust to C without trusting the pointer or panicking Decide what overflow and panics do in release builds Gate crates before they build Run the checks on every pull request Replace C components one boundary at a time Pitfalls", "key": "rust-unsafe-ffi", "domain": "appsec", "topic": "Audit unsafe Rust, FFI boundaries and crate dependencies", "title": "Audit unsafe Rust, FFI boundaries and crate dependencies", "path": "https://softwaresecurity.com/domains/appsec/platform-security/rust-unsafe-ffi/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-headers Configure HTTP security headers from a tested baseline Send the response headers that make browsers enforce HTTPS, run only your own scripts, refuse hostile framing and keep cookies on one host, then prove they appear on every kind of response. HTTP security headers HSTS Content Security Policy Clickjacking Cookies Cross-origin isolation Framework configuration CWE-1021 CWE-319 CWE-614 CWE-1004 A02:2025 CAPEC-103 CAPEC-102 WSTG-CONF-07 WSTG-CLNT-09 Send each header where the browser uses it Turn on HSTS in stages Treat HSTS preload as a one-way door Use a nonce- or hash-based CSP, not a host allowlist Roll CSP out in report-only mode Block framing with frame-ancestors Stop MIME sniffing, trim referrers and switch off unused features Isolate windows and resources with COOP, CORP and COEP Lock session cookies to one host with __Host- Express: helmet plus a per-response nonce Spring Security: headers() plus a nonce filter ASP.NET Core: UseHsts plus one header middleware Django: SecurityMiddleware settings and built-in CSP Next.js: fixed headers in next.config Next.js: a nonce-based CSP in proxy.ts nginx: use always, and watch add_header inheritance Pitfalls that silently remove protection A real-world failure Verify on real responses and keep a regression test", "key": "security-headers", "domain": "appsec", "topic": "Configure HTTP security headers from a tested baseline", "title": "Configure HTTP security headers from a tested baseline", "path": "https://softwaresecurity.com/domains/appsec/browser-security/security-headers/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "CSP builder lab: Build a strict Content-Security-Policy", "path": "https://softwaresecurity.com/labs/csp-policy/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "threat-modeling-methods Choose a threat modeling method and turn its findings into tests Use the four-question frame to scope a design, pick STRIDE, attack trees, LINDDUN or PASTA by the question you need answered, and leave behind threat records and abuse-case tests the team can run. Threat modeling STRIDE Attack trees LINDDUN PASTA Data-flow diagrams Secure design A06:2025 What are the four questions of threat modeling? Which threat modeling method should you use? Draw the data-flow diagram and its trust boundaries How do you apply STRIDE per element? When should you switch to STRIDE per interaction? When is an attack tree the right tool? When do you need LINDDUN? When does PASTA fit? How do you threat model a single story? Worked example: an expense-claims API How do you turn each threat you keep into a test? Record decisions and check the model Avoid the failure modes that waste sessions", "key": "threat-modeling-methods", "domain": "appsec", "topic": "Choose a threat modeling method and turn its findings into tests", "title": "Choose a threat modeling method and turn its findings into tests", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/threat-modeling-methods/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "vdp-bug-bounty-pentest Start with a VDP, then add bug bounties and penetration tests Publish a vulnerability disclosure policy and security.txt first, add a bug bounty only when you can triage and fix at the pace rewards bring, and buy penetration tests with a written scope, rules of engagement and a retest. Vulnerability disclosure VDP Bug bounty Penetration testing security.txt Safe harbor ISO/IEC 29147 VDP, bug bounty or penetration test: which does what? Why publish a VDP first? What goes in a vulnerability disclosure policy? Where does safe harbor stop? What goes in security.txt? Serve it with the right type Sign it with a key kept off the web server Check every host in CI What response targets and severity ratings should you set? How much should a bug bounty pay? Should you run a bounty yourself or through a platform? How do you scope a penetration test? Agree rules of engagement before testing starts What should a penetration test report and retest include?", "key": "vdp-bug-bounty-pentest", "domain": "appsec", "topic": "Start with a VDP, then add bug bounties and penetration tests", "title": "Start with a VDP, then add bug bounties and penetration tests", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/vdp-bug-bounty-pentest/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-shai-hulud Case study: the Shai-Hulud npm worm (2025-2026) How a self-replicating npm worm turned stolen tokens into hundreds of infected packages in 2025, how its 2026 successors hijacked release pipelines and trusted publishing, what npm and GitHub changed in response, and the publishing, install and response practices that stop it. npm Supply chain attack Worm Shai-Hulud Trusted publishing Install scripts Token theft Incident response CWE-506 CWE-522 A03:2025 V15.2 V13.3 CAPEC-538 CAPEC-511 A worm that publishes itself with stolen tokens Wave one, September 2025: a postinstall worm Wave two, November 2025: preinstall, Bun and a wiper The 2026 waves Why it spread What npm and GitHub changed A release workflow the worm could use Publish without a stored token, and with a human Keep install-time code out of CI Check whether you installed an infected version If an infected version ran Which controls would have stopped or limited it? Lessons What the public evidence does not establish", "key": "case-study-shai-hulud", "domain": "supply-chain", "topic": "Case study: the Shai-Hulud npm worm (2025-2026)", "title": "Case study: the Shai-Hulud npm worm (2025-2026)", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/case-study-shai-hulud/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-tj-actions Case study: the tj-actions/changed-files compromise (CVE-2025-30066) In March 2025 an attacker moved the version tags of a popular GitHub Action, and of a reviewdog action before it, to code that printed CI secrets into build logs. This case study traces the token chain back to one pull_request_target workflow, sizes the exposure, and shows how it was caught and which controls held. GitHub Actions CI/CD Supply chain attack CVE-2025-30066 CVE-2025-30154 SHA pinning Secrets in logs Incident response CWE-506 CWE-532 A03:2025 V13.3 CAPEC-538 CAPEC-439 CVE-2025-30066 CVE-2025-30154 A moved tag ran attacker code in thousands of pipelines Timeline How the payload turned logs into the leak Why tags failed and SHA pins held A workflow that was exposed The same job, hardened Who was exposed How it was caught and contained Pull the logs from the exposure window Scan the logs for encoded secret dumps Which controls would have stopped or limited it? Lessons that still apply It happened again in 2026 What the public evidence does not establish", "key": "case-study-tj-actions", "domain": "supply-chain", "topic": "Case study: the tj-actions/changed-files compromise (CVE-2025-30066)", "title": "Case study: the tj-actions/changed-files compromise (CVE-2025-30066)", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/case-study-tj-actions/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-xz-utils Case study: the xz Utils backdoor (CVE-2024-3094) How a multi-year maintainer takeover planted a backdoor in xz Utils release tarballs, how build-time injection hid it from the git repository, why a performance anomaly exposed it, which systems shipped it, and what it teaches about reproducible builds and maintainer health. xz Utils liblzma Supply chain Backdoor Reproducible builds Maintainer trust Social engineering CWE-506 CWE-912 A03:2025 CAPEC-444 CAPEC-538 CVE-2024-3094 xz backdoor A backdoor shipped in a release tarball, not the repository How the payload hid: tarball versus git How it reached sshd A multi-year maintainer takeover Which systems shipped it Why half a second of CPU exposed it Detect and respond Which controls would have stopped or limited it? Lessons: reproducible builds, tarball-vs-repo, maintainer health Verify your build inputs What the public evidence does not establish", "key": "case-study-xz-utils", "domain": "supply-chain", "topic": "Case study: the xz Utils backdoor (CVE-2024-3094)", "title": "Case study: the xz Utils backdoor (CVE-2024-3094)", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/case-study-xz-utils/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-solarwinds Case study: the SolarWinds Orion build compromise (SUNBURST) How an implant on SolarWinds' build server inserted the SUNBURST backdoor into signed Orion updates in 2020, how it was found, why code signing and review could not catch it, and which build controls would have. SolarWinds SUNBURST SUNSPOT Orion Build compromise Code signing Supply chain Build systems Windows Software products CWE-912 CAPEC-444 CAPEC-511 CAPEC-206 Solorigate SolarWinds hack A clean repository, a signed release, and a backdoor in between Timeline How did SUNSPOT change the build without changing the source? What SUNBURST did on customer networks How was it found? Check a server for an affected version Search resolver logs for the first-stage domain Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-solarwinds", "domain": "supply-chain", "topic": "Case study: the SolarWinds Orion build compromise (SUNBURST)", "title": "Case study: the SolarWinds Orion build compromise (SUNBURST)", "path": "https://softwaresecurity.com/domains/supply-chain/builds/case-study-solarwinds/", "platforms": [ "Build systems", "Windows", "Software products" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-codecov Case study: the Codecov Bash Uploader compromise (2021) How a credential leaked through Codecov's Docker image process let an attacker change the Bash Uploader that many CI pipelines downloaded and ran, which sent their environment variables, and the secrets in them, to the attacker for two months in 2021. Codecov Bash Uploader CI secrets curl pipe bash Download integrity Supply chain CI/CD GitHub Actions Build systems CAPEC-439 Codecov breach A script many pipelines downloaded on every run Timeline How did one changed file reach so many secrets? What was exposed downstream? How was it caught? Verify a downloaded CI tool before running it Give the coverage job nothing worth stealing Which controls would have stopped or contained it? Lessons that still apply What the public evidence does not establish", "key": "case-study-codecov", "domain": "supply-chain", "topic": "Case study: the Codecov Bash Uploader compromise (2021)", "title": "Case study: the Codecov Bash Uploader compromise (2021)", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/case-study-codecov/", "platforms": [ "CI/CD", "GitHub Actions", "Build systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-3cx Case study: the 3CX DesktopApp supply-chain attack (CVE-2023-29059) How a trojanized trading application on one employee's personal computer led to 3CX's build servers and to signed, malicious 3CX DesktopApp releases in 2023: the first cascading software supply-chain compromise Mandiant had seen, how EDR caught it, and the controls that would have stopped it. 3CX X_TRADER Cascading supply chain attack Build compromise Code signing EDR Build systems Windows macOS Electron Desktop CAPEC-511 CAPEC-444 CAPEC-206 CVE-2023-29059 3CX supply chain attack One trojanized download led to another vendor's signed release Timeline How did the attackers get from a trading app to 3CX's builds? How was it found, and why was it nearly dismissed? Check endpoints for an affected version The same check on macOS Which controls would have broken the chain? Lessons that still apply What the public evidence does not establish", "key": "case-study-3cx", "domain": "supply-chain", "topic": "Case study: the 3CX DesktopApp supply-chain attack (CVE-2023-29059)", "title": "Case study: the 3CX DesktopApp supply-chain attack (CVE-2023-29059)", "path": "https://softwaresecurity.com/domains/supply-chain/builds/case-study-3cx/", "platforms": [ "Build systems", "Windows", "macOS", "Electron", "Desktop" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-event-stream Case study: event-stream and ua-parser-js, two npm package takeovers Two ways attackers took over popular npm packages: event-stream (2018), handed to a stranger who added a targeted, encrypted payload through a new dependency, and ua-parser-js (2021), whose maintainer's account was hijacked to publish versions that installed malware for four hours. Timelines, detection and the controls that stop both. event-stream ua-parser-js flatmap-stream npm Maintainer takeover Account takeover Install scripts Package ecosystems Node.js JavaScript CAPEC-538 CVE-2021-4229 ua-parser-js hijack Two takeovers: a handover and a hijack Timeline event-stream: how a targeted payload hid in a new dependency ua-parser-js: a hijacked account and a four-hour window Why did they reach so many installs? Check lockfiles for the affected versions Harden installs and publishing Which controls would have helped? Lessons that still apply What the public evidence does not establish", "key": "case-study-event-stream", "domain": "supply-chain", "topic": "Case study: event-stream and ua-parser-js, two npm package takeovers", "title": "Case study: event-stream and ua-parser-js, two npm package takeovers", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/case-study-event-stream/", "platforms": [ "Package ecosystems", "Node.js", "JavaScript" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-polyfill-io Case study: the polyfill.io CDN takeover (2024) How the sale of the polyfill.io domain and project in February 2024 turned a script tag on more than 100,000 websites into a channel for malicious redirects by June, why Subresource Integrity could not have protected it, and the controls that would have. polyfill.io Third-party JavaScript CDN Subresource Integrity Content Security Policy Domain takeover Web CDN JavaScript CVE-2024-38526 polyfill supply chain attack A script tag whose owner changed Timeline What did the injected code do? Why couldn't Subresource Integrity protect these sites? Find references in code, builds and live pages Replace dynamic third-party scripts with pinned ones Which controls would have helped? Lessons that still apply What the public evidence does not establish", "key": "case-study-polyfill-io", "domain": "supply-chain", "topic": "Case study: the polyfill.io CDN takeover (2024)", "title": "Case study: the polyfill.io CDN takeover (2024)", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/case-study-polyfill-io/", "platforms": [ "Web", "CDN", "JavaScript" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-moveit Case study: MOVEit Transfer mass exploitation (CVE-2023-34362) How one unauthenticated SQL injection in an internet-facing file transfer product let the Cl0p group steal data from thousands of organizations in days in 2023, how defenders found the web shell, and the vendor and customer controls that would have limited it. MOVEit MOVEit Transfer SQL injection Cl0p Managed file transfer Web shell Mass exploitation Web Windows .NET Software products CAPEC-66 CVE-2023-34362 CVE-2023-35036 CVE-2023-35708 MOVEit breach One SQL injection, thousands of victims Timeline How did the attack work? The weakness: SQL built from request data How was it found, and what should you hunt for? Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-moveit", "domain": "appsec", "topic": "Case study: MOVEit Transfer mass exploitation (CVE-2023-34362)", "title": "Case study: MOVEit Transfer mass exploitation (CVE-2023-34362)", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/case-study-moveit/", "platforms": [ "Web", "Windows", ".NET", "Software products" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "dependency-confusion Stop dependency confusion and typosquatting at install time Pin every internal package name to its real source, verify installed bytes against a lockfile, and delay or gate install scripts so a public look-alike cannot replace a private dependency. Dependency confusion Typosquatting Slopsquatting npm pip Package source mapping Lockfiles CWE-427 CWE-427 CWE-1104 A03:2025 V15.2.4 V15.1.2 CAPEC-471 CAPEC-538 CICD-SEC-3 Why a public name can outrank your private one npm and pnpm: scope the name to its registry npm: approve install scripts deliberately pip and uv: one index, not two uv: pin an internal name to an explicit index Install from a lockfile with integrity hashes Add a release-age cooldown Maven, Gradle and NuGet: map names to sources NuGet: packageSourceMapping with a repo-local cache Verify names, especially AI-suggested ones", "key": "dependency-confusion", "domain": "supply-chain", "topic": "Stop dependency confusion and typosquatting at install time", "title": "Stop dependency confusion and typosquatting at install time", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/dependency-confusion/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "github-actions-hardening Harden GitHub Actions against workflow and supply-chain attacks Close the paths that give untrusted pull-request code secrets or a write token: pass context through env, keep pull_request_target away from fork code, pin actions to commit SHAs, scope GITHUB_TOKEN and OIDC, and treat artifacts as data. GitHub Actions CI/CD Script injection pull_request_target OIDC GITHUB_TOKEN SHA pinning Self-hosted runners CWE-116 CWE-275 CWE-349 A03:2025 V1.2.5 V13.3.1 V13.3.2 CAPEC-88 CAPEC-538 CICD-SEC-4 Find the jobs that hold power Script injection: keep context out of the shell The env fix, plus per-job permissions pull_request_target and workflow_run: the pwn request Split the work: untrusted build, trusted comment The privileged consumer validates, never executes Pin actions to a commit SHA OIDC: scope the token and the trust policy Runners, secrets and environments", "key": "github-actions-hardening", "domain": "supply-chain", "topic": "Harden GitHub Actions against workflow and supply-chain attacks", "title": "Harden GitHub Actions against workflow and supply-chain attacks", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/github-actions-hardening/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Actions injection lab: Flag GitHub Actions expression injection", "path": "https://softwaresecurity.com/labs/actions-injection/" } ], "projects": [ { "title": "Repair a security pipeline for GitHub Actions and GitLab CI", "path": "https://softwaresecurity.com/labs/#project-security-pipeline", "download": "https://softwaresecurity.com/downloads/projects/security-pipeline-365c6d54e88d6c1c.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "source-repository-protection Source integrity Protect the source repository: rulesets, reviews and signed commits Configure the controls every repository that ships software needs: protected branches and tags, required review with CODEOWNERS, signed commits, secret push protection and account security, mapped to the SLSA Source track, the OpenSSF OSPS Baseline and Scorecard. Branch protection Rulesets CODEOWNERS Signed commits Push protection SLSA Source track OSPS Baseline OpenSSF Scorecard GitHub Actions CI/CD Engineering organizations CICD-SEC-1 branch protection signed commits CODEOWNERS gitsign vigilant mode repository security commit signing What goes wrong in a source repository? Protect the default branch and release tags with rulesets Apply the rulesets from the command line Route sensitive changes to the right reviewers with CODEOWNERS Sign commits and tags, and know what a signature proves Stop secrets at push time Control who can change the repository The same controls on GitLab Map the controls to SLSA Source, OSPS Baseline and Scorecard Check that the rules actually hold", "key": "source-repository-protection", "domain": "supply-chain", "topic": "Source integrity", "title": "Protect the source repository: rulesets, reviews and signed commits", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/source-repository-protection/", "platforms": [ "GitHub Actions", "CI/CD", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "developer-workstation-security Development environment Secure the developer workstation: extensions, package managers, secrets and AI agents Attackers reach the software supply chain through developers' editors, package installs and AI agents. Allow-list extensions, stop install scripts and brand-new versions, keep long-lived secrets off laptops, and lock down repository files that run code when a project opens. Developer workstation VS Code extension security Open VSX GlassWorm Install scripts Workspace Trust Dev containers AI coding agents Desktop Package ecosystems Agent systems Node.js Python CWE-522 Open VSX Workspace Trust dev container MCP servers IDE security developer laptop security How do attackers get in through a developer's machine? Allow-list and pin editor extensions Don't let a repository run code when you open it Stop install scripts and versions that are only hours old Keep long-lived secrets off the laptop Use dev containers for isolation, knowing what they share Constrain AI coding agents and MCP servers A workstation baseline Check a machine after an extension or package advisory", "key": "developer-workstation-security", "domain": "supply-chain", "topic": "Development environment", "title": "Secure the developer workstation: extensions, package managers, secrets and AI agents", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/developer-workstation-security/", "platforms": [ "Desktop", "Package ecosystems", "Agent systems", "Node.js", "Python" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "open-source-license-compliance Dependency risk Open source license compliance: SPDX expressions, obligations and SBOM checks Know which licenses you ship, read SPDX license expressions correctly, meet the obligations of common licenses for the way you distribute, and enforce a license policy in CI from the SBOM. License compliance Open source licenses License expressions Copyleft Third-party notices SBOM Package ecosystems Software products Engineering organizations license compliance copyleft third-party notices license scanning OSS license compliance Which licenses do you actually ship? Read SPDX license expressions What each common license asks of you Write a license policy by distribution model Enforce the policy from the SBOM Catch new licenses in pull requests Run the checks from the command line Produce the compliance artifacts with each release", "key": "open-source-license-compliance", "domain": "supply-chain", "topic": "Dependency risk", "title": "Open source license compliance: SPDX expressions, obligations and SBOM checks", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/open-source-license-compliance/", "platforms": [ "Package ecosystems", "Software products", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "cloud-provider-baselines Apply a security baseline across AWS, Azure and Google Cloud Give workloads platform identities instead of keys, guard the instance metadata endpoint, block public storage, keep audit logs past the default retention, close inbound admin ports and use the native secret store, with tested Terraform for AWS, Azure and Google Cloud. Cloud security baseline AWS Azure Google Cloud IMDSv2 Workload identity Terraform Audit logging CWE-1188 CWE-732 CWE-798 A02:2025 V13.2 V13.3 V16.4 CAPEC-664 CAPEC-560 Enforce the baseline at three levels The same controls on each provider Replace keys with platform identities Treat the metadata endpoint as a credential store AWS: require IMDSv2 at both levels Block public storage from the top Encryption is on by default; key control is a choice Keep audit logs longer than the provider does Azure: storage, Key Vault and the Activity Log Close inbound management paths Google Cloud: organization policies and VMs Keep the remaining secrets in the provider's store What a failing configuration looks like Test the Terraform before it reaches an account Pitfalls Check the live accounts", "key": "cloud-provider-baselines", "domain": "runtime", "topic": "Apply a security baseline across AWS, Azure and Google Cloud", "title": "Apply a security baseline across AWS, Azure and Google Cloud", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/cloud-provider-baselines/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "runtime-threat-detection Detect container and host threats at runtime with eBPF sensors and cloud services Watch process, file and network activity inside containers with an eBPF sensor or a managed cloud agent, write and test rules for the attacks you expect, tune them with narrow exceptions and contain a compromised pod without destroying evidence. Runtime security Falco Tetragon Tracee eBPF GuardDuty Runtime Monitoring Defender for Containers Container Threat Detection Detection engineering Incident response Kubernetes Linux containers AWS Azure Google Cloud Falco Tetragon Tracee eBPF runtime security GuardDuty Runtime Monitoring runtime threat detection container runtime security What a runtime sensor sees Choose a sensor you run or one your provider runs Install Falco with the upstream rules and your own Write a rule for an attack you expect Tune with narrow exceptions, not by switching rules off Report or block in the kernel with Tetragon Use the provider's agent on EKS, AKS and GKE Contain the pod, keep the evidence, then replace it Pitfalls", "key": "runtime-threat-detection", "domain": "runtime", "topic": "Detect container and host threats at runtime with eBPF sensors and cloud services", "title": "Detect container and host threats at runtime with eBPF sensors and cloud services", "path": "https://softwaresecurity.com/domains/runtime/detection/runtime-threat-detection/", "platforms": [ "Kubernetes", "Linux containers", "AWS", "Azure", "Google Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "managed-kubernetes-hardening Harden managed Kubernetes on EKS, AKS and GKE Know what your provider secures and what you still own, then lock down API access, cloud identity, nodes, pod privileges and admission with settings that are generally available in Kubernetes 1.37, checked against the CIS and NSA/CISA baselines. Kubernetes EKS AKS GKE Shared responsibility CIS Benchmark NSA/CISA Kubernetes Hardening Guidance Pod Security Admission User namespaces AppArmor seccomp ValidatingAdmissionPolicy Kubernetes AWS Azure Google Cloud Linux containers CWE-269 CWE-1188 K07:2025 EKS AKS GKE kube-bench user namespaces AppArmor CIS Benchmark EKS hardening AKS hardening GKE hardening Kubernetes hardening Know what the provider secures and what you still own Use the CIS and NSA/CISA baselines as checklists Restrict who can reach and call the API Give pods their own cloud identity and keep them off the node's Keep nodes current and isolate risky workloads Enforce Pod Security restricted, seccomp, AppArmor and user namespaces Enforce what Pod Security cannot at admission Pitfalls", "key": "managed-kubernetes-hardening", "domain": "runtime", "topic": "Harden managed Kubernetes on EKS, AKS and GKE", "title": "Harden managed Kubernetes on EKS, AKS and GKE", "path": "https://softwaresecurity.com/domains/runtime/containers/managed-kubernetes-hardening/", "platforms": [ "Kubernetes", "AWS", "Azure", "Google Cloud", "Linux containers" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "l7-ddos-resilience Keep HTTP services up under application-layer DDoS Bound every phase of an HTTP request, patch for the HTTP/2 attack classes, rate limit at the edge and the origin, and shed load deliberately, with nginx, Envoy and Node.js settings tested against slow clients and bursts. DDoS Application-layer DDoS Slowloris HTTP flood HTTP/2 Rapid Reset Rate limiting Load shedding nginx Envoy Node.js Reverse proxy CDN WAF Node.js APIs Web CAPEC-469 CAPEC-488 Slowloris HTTP flood Rapid Reset DDoS load shedding slow POST layer 7 DDoS application layer DDoS What an application-layer attack exhausts HTTP/2 multiplies the work one connection can create Bound every phase of a request nginx: timeouts, sizes and per-client limits Envoy: edge defaults are not on by default Node.js: set the server limits explicitly Absorb floods at the edge and lock the origin behind it Shed load before everything slows down Test the limits before an attacker does Pitfalls", "key": "l7-ddos-resilience", "domain": "runtime", "topic": "Keep HTTP services up under application-layer DDoS", "title": "Keep HTTP services up under application-layer DDoS", "path": "https://softwaresecurity.com/domains/runtime/availability/l7-ddos-resilience/", "platforms": [ "Reverse proxy", "CDN", "WAF", "Node.js", "APIs", "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "cloud-security-posture Choose cloud security posture tools and apply zero trust What CSPM, CWPP, CIEM, CNAPP, DSPM and ASPM each find and miss, how they overlap, how to evaluate one on your own accounts, and how zero trust as defined in NIST SP 800-207 uses what they measure. CSPM CWPP CIEM CNAPP DSPM ASPM Cloud security posture management Zero trust NIST SP 800-207 Prowler Tool evaluation AWS Azure Google Cloud Kubernetes Cloud CWE-1188 CWE-732 CSPM CWPP CIEM CNAPP DSPM ASPM zero trust NIST SP 800-207 cloud security posture management zero trust architecture What each category looks at Where they overlap, and why correlation matters Start with native services and one open-source scanner Evaluate a platform on a seeded sandbox Selection criteria Zero trust as NIST SP 800-207 defines it Pitfalls", "key": "cloud-security-posture", "domain": "runtime", "topic": "Choose cloud security posture tools and apply zero trust", "title": "Choose cloud security posture tools and apply zero trust", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/cloud-security-posture/", "platforms": [ "AWS", "Azure", "Google Cloud", "Kubernetes", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "container-image-hardening Harden container images from Dockerfile to admission Build minimal, non-root images pinned by digest, keep secrets out of every layer, then scan, sign and verify the exact digest before it runs with dropped privileges. Containers Dockerfile Distroless BuildKit secrets Image scanning SBOM Sigstore Admission control CWE-538 CWE-1395 What an image carries into production Vulnerable: a Dockerfile that works and leaks Fixed: build in one stage, ship a minimal one Allowlist the build context Keep secrets out of layers, history and provenance Pin base images by digest and keep them moving Scan the digest in CI, then keep scanning Attach an SBOM to the image you ship Sign the digest in CI and verify the signer Enforce the signature at admission Run with the fewest privileges the image allows Prove the settings took effect Pitfalls Tooling", "key": "container-image-hardening", "domain": "runtime", "topic": "Harden container images from Dockerfile to admission", "title": "Harden container images from Dockerfile to admission", "path": "https://softwaresecurity.com/domains/runtime/containers/container-image-hardening/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Repair a security pipeline for GitHub Actions and GitLab CI", "path": "https://softwaresecurity.com/labs/#project-security-pipeline", "download": "https://softwaresecurity.com/downloads/projects/security-pipeline-365c6d54e88d6c1c.zip" }, { "title": "Gate an image build on a CIS scan and a deviation register", "path": "https://softwaresecurity.com/labs/#project-image-benchmark-gate", "download": "https://softwaresecurity.com/downloads/projects/image-benchmark-gate-b76ad8a05569f566.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "image-hardening-benchmarks Hardening benchmarks Harden the images you ship against CIS, STIG and SCAP benchmarks Hold each image your team ships (container base images, golden VM images, Kubernetes node images) to a published benchmark through a pinned SCAP Security Guide profile, scan every build with OpenSCAP, and fail the build on any failure that a deviation register does not explain with an owner, an approver and an expiry. CIS Benchmark DISA STIG OpenSCAP SCAP Security Guide Hardening baseline Containers Image scanning Risk acceptance Exceptions Containers Linux Kubernetes CI CWE-1188 OpenSCAP SCAP Security Guide DISA STIG CIS Benchmark deviation register hardening baseline golden image hardening compliance scanning Which images need a benchmark CIS, DISA STIG and SCAP Security Guide: access and versions Scan an image offline in CI Read the results before you gate on them Keep a deviation register Enforce the register in CI An image is not the whole host Pitfalls", "key": "image-hardening-benchmarks", "domain": "runtime", "topic": "Hardening benchmarks", "title": "Harden the images you ship against CIS, STIG and SCAP benchmarks", "path": "https://softwaresecurity.com/domains/runtime/containers/image-hardening-benchmarks/", "platforms": [ "Containers", "Linux", "Kubernetes", "CI" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Gate an image build on a CIS scan and a deviation register", "path": "https://softwaresecurity.com/labs/#project-image-benchmark-gate", "download": "https://softwaresecurity.com/downloads/projects/image-benchmark-gate-b76ad8a05569f566.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "osps-baseline-maintainers Open-source baselines Meet the OpenSSF OSPS Baseline as a maintainer: the levels, every Level 1 control on GitHub, and the evidence Walk through the eight control families and three maturity levels of OSPS Baseline v2026.08.28, meet each Level 1 requirement on a GitHub repository, and keep evidence a consumer can check. OSPS Baseline OpenSSF Scorecard Security Insights Branch protection Rulesets Secure SDLC Maintainer trust CI/CD Package ecosystems OSPS Baseline Security Insights Privateer OpenSSF Baseline Open Source Project Security Baseline Which version should you claim, and what do the levels mean? What do the eight control families cover? How do you meet each Level 1 requirement on GitHub, and what proves it? How do you publish the facts a scanner can't see? Which Level 2 controls matter most? What do least-privilege pipelines and signed releases look like? Which Level 3 controls change how the project works? How do you write verification instructions that name the signer? What evidence should you keep, and how do you collect it? What do Scorecard, Minder and the Privateer scanner actually check? How will consumers read your claim?", "key": "osps-baseline-maintainers", "domain": "supply-chain", "topic": "Open-source baselines", "title": "Meet the OpenSSF OSPS Baseline as a maintainer: the levels, every Level 1 control on GitHub, and the evidence", "path": "https://softwaresecurity.com/domains/supply-chain/ci-cd/osps-baseline-for-maintainers/", "platforms": [ "CI/CD", "Package ecosystems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "s2c2f-consumer-adoption Open-source baselines Adopt the OpenSSF S2C2F as a consumer: the eight practices, the four maturity levels and a staged plan with evidence Assess how your organization takes in open source against the Secure Supply Chain Consumption Framework's 25 requirements, then reach each maturity level in turn with evidence an assessor can check. S2C2F OSS intake Dependencies Lockfiles Package source mapping Supplier risk SCA Engineering organizations Package ecosystems S2C2F curated feed deny list Secure Supply Chain Consumption Framework OSS consumption maturity What is S2C2F, and which edition do you cite? What do the eight practices ask for? What does each maturity level require? How do you assess where your organization is? What does the assessment matrix look like? A staged adoption plan, with the evidence for each level Which GitHub-native controls map to the requirements? Where does S2C2F stop?", "key": "s2c2f-consumer-adoption", "domain": "supply-chain", "topic": "Open-source baselines", "title": "Adopt the OpenSSF S2C2F as a consumer: the eight practices, the four maturity levels and a staged plan with evidence", "path": "https://softwaresecurity.com/domains/supply-chain/dependencies/s2c2f-adoption/", "platforms": [ "Engineering organizations", "Package ecosystems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "crypto-quick-reference Choose cryptographic algorithms and parameters by job A sourced quick reference for October 2026: which algorithm and parameters to use for encryption, hashing, passwords, MACs, signatures, key agreement, key derivation, randomness and TLS, the matching APIs in Node.js, Python, Java, Go and .NET, and where post-quantum migration stands. Cryptography AEAD Password hashing Digital signatures Key derivation Randomness TLS Post-quantum cryptography CWE-326 CWE-328 CWE-338 CWE-323 CWE-757 A04:2025 V11.2 V11.3 V11.4 V11.5 V11.6 V12.1 CAPEC-97 CAPEC-20 CAPEC-55 CAPEC-463 CAPEC-620 RSA ChaCha20 ECDSA Ed25519 hashing timing safe cryptography cheat sheet which algorithm Pick the primitive by the job What is the difference between hashing, encryption and a MAC? Encrypt with an AEAD and never reuse a nonce AES-GCM or ChaCha20-Poly1305: which should you use? Hash with SHA-2 or SHA-3, authenticate with HMAC How do you compare tokens and MACs without leaking timing? Hash passwords with Argon2id and current parameters Sign with Ed25519, ECDSA P-256 or RSA-PSS RSA or ECDSA (or Ed25519): which should you use? Agree keys with X25519, then derive them with HKDF Encrypt to a public key with HPKE Take every secret value from the OS CSPRNG The same jobs in Node.js, Python, Java, Go and .NET Use TLS 1.3; keep TLS 1.2 only where you must Post-quantum status in October 2026 Retire these on sight Check code and endpoints", "key": "crypto-quick-reference", "domain": "identity-crypto", "topic": "Choose cryptographic algorithms and parameters by job", "title": "Choose cryptographic algorithms and parameters by job", "path": "https://softwaresecurity.com/domains/identity-crypto/encryption/crypto-quick-reference/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "Insecure randomness lab: Generate unguessable API keys", "path": "https://softwaresecurity.com/labs/insecure-randomness/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "jwt-attacks Defend JWTs against forgery, confusion and replay Verify a JWT as an issuer-, type- and audience-bound assertion with an algorithm allowlist and trusted keys, closing the alg \"none\", key-confusion, header-injection, weak-secret and replay attacks. JWT JWS JWE Token validation Algorithm confusion API Web CWE-287 CWE-290 CWE-613 CWE-326 A07:2025 API2:2023 CAPEC-475 CAPEC-196 CAPEC-593 localStorage algorithm confusion A signature proves who signed, not that the token is yours Close alg \"none\" and RS/HS key confusion with an allowlist Never resolve keys from the token's own headers Keep HMAC secrets full-length, or prefer asymmetric keys Check issuer, audience, type and time on a trusted layer How long should access tokens and refresh tokens live? A signed JWT is readable; use JWE only for confidentiality Should you store a JWT in localStorage? Prove the rejections, with tooling and tests", "key": "jwt-attacks", "domain": "identity-crypto", "topic": "Defend JWTs against forgery, confusion and replay", "title": "Defend JWTs against forgery, confusion and replay", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/jwt-attacks/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "JWT verification lab: Verify a JWT before trusting it", "path": "https://softwaresecurity.com/labs/jwt-verification/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "leaked-secret-response Contain a leaked secret, then investigate and clean up Revoke an exposed API key, token or private key at its issuer before anything else, end the sessions it minted, check the provider's logs, then remove every copy and replace it with a credential that expires on its own. Leaked secrets Incident response Credential rotation Secret scanning Git history Cloud IAM Short-lived credentials CWE-798 CWE-540 CWE-532 CWE-522 CWE-321 V13.3 V13.2 CAPEC-560 CAPEC-37 CAPEC-191 Revoke at the issuer before anything else Establish what leaked, what it can do and for how long Runbook by credential type Example: contain a leaked AWS access key Read the provider's logs for use and persistence Purge history correctly, and rotate anyway Catch leaks with secret scanning and push protection Make the next leak expire on its own Close the incident with evidence", "key": "leaked-secret-response", "domain": "identity-crypto", "topic": "Contain a leaked secret, then investigate and clean up", "title": "Contain a leaked secret, then investigate and clean up", "path": "https://softwaresecurity.com/domains/identity-crypto/secrets/leaked-secret-response/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "mfa-account-takeover Stop account takeover with the right MFA and login defenses Rank MFA options by the attacks they stop, implement TOTP and push approvals correctly, and close the login, reset and recovery paths that attackers use instead of breaking the second factor. Multi-factor authentication Account takeover TOTP Passkeys MFA fatigue Credential stuffing NIST SP 800-63B-4 User enumeration CWE-307 CWE-308 CWE-294 CWE-204 CWE-208 CWE-521 CWE-640 A07:2025 V6.2 V6.3 V6.4 V6.5 V6.6 V2.4 CAPEC-600 CAPEC-565 CAPEC-49 CAPEC-94 CAPEC-575 SMS TOTP push bombing Which MFA method is strongest? Verify TOTP codes once, against the server clock Test replay, skew and the attempt limit Make push approvals carry a code, and cap them Is SMS MFA still acceptable? Make passkeys the default and stop fallbacks undoing them Give recovery the same strength as login Throttle by account, address and network Reject breached passwords without sending them anywhere Answer identically for real and unknown accounts Close the paths that skip the second factor", "key": "mfa-account-takeover", "domain": "identity-crypto", "topic": "Stop account takeover with the right MFA and login defenses", "title": "Stop account takeover with the right MFA and login defenses", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/mfa-account-takeover/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "oauth-oidc-attacks Defend OAuth and OIDC against redirect and token attacks Apply RFC 9700 and RFC 10017: exact redirect matching, PKCE with downgrade protection, state and iss binding, refresh-token rotation, sender-constrained tokens, and a backend-for-frontend so browser tokens cannot be stolen. OAuth 2.0 OpenID Connect PKCE DPoP Refresh tokens Backend-for-frontend Federated login CWE-601 CWE-346 CWE-294 CWE-287 A07:2025 CAPEC-62 CAPEC-593 Where the attacks hit a delegated-authorization flow Match redirect URIs exactly, and never be an open redirector PKCE binds the code to the client, and blocks downgrade Bind the callback to the browser and to the issuer Drop the implicit and password grants Make refresh tokens detectable when stolen Sender-constrain tokens so a stolen token is inert Keep tokens out of the SPA with a backend-for-frontend Prove each defense against a concrete attack", "key": "oauth-oidc-attacks", "domain": "identity-crypto", "topic": "Defend OAuth and OIDC against redirect and token attacks", "title": "Defend OAuth and OIDC against redirect and token attacks", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/oauth-oidc-attacks/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "OAuth redirect and PKCE lab: Match redirect URIs and verify PKCE", "path": "https://softwaresecurity.com/labs/oauth-redirect-pkce/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "appsec-metrics-and-slas Set remediation SLAs and measure AppSec outcomes Set vulnerability SLAs by exploitation and exposure, route misses through expiring exceptions, and measure the program with cohort-based, censoring-aware metrics that resist gaming. AppSec metrics Remediation SLA Vulnerability management OWASP SAMM NIST SSDF BSIMM Dashboards Which AppSec metrics are worth reporting? Define each metric before you chart it How do you report time to remediate without hiding open findings? How do you compute SLA attainment and backlog age? What SLAs can engineers actually meet? Use an SLA policy template Route misses through exceptions that expire How do you measure escapes and repeat findings? Measure coverage against the service inventory How do you build a dashboard that resists gaming? Check the data before you trust the chart", "key": "appsec-metrics-and-slas", "domain": "governance", "topic": "Set remediation SLAs and measure AppSec outcomes", "title": "Set remediation SLAs and measure AppSec outcomes", "path": "https://softwaresecurity.com/frameworks/appsec-metrics-and-slas/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "cra-reporting-runbook Build a runbook for CRA vulnerability and incident reporting Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform within 24 and 72 hours. Decide what is reportable, start the clock at the right moment, file through the platform and keep an evidence trail. Cyber Resilience Act Vulnerability reporting Incident reporting ENISA Single Reporting Platform CSIRT Runbook Product security Who reports what under the CRA, and from when? Is the event reportable? When does the clock start? What are the three deadlines? How do you file through ENISA's Single Reporting Platform? Who else must you tell? What should you prepare before the first case? What steps does every case follow? What evidence trail should you keep outside the platform? Which other reports might the same event need?", "key": "cra-reporting-runbook", "domain": "governance", "topic": "Build a runbook for CRA vulnerability and incident reporting", "title": "Build a runbook for CRA vulnerability and incident reporting", "path": "https://softwaresecurity.com/frameworks/cra-reporting-runbook/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "pci-dss-requirement-6 Map PCI DSS Requirement 6 to engineering practice and evidence Turn PCI DSS v4.0.1 Requirement 6 into engineering work: secure development, review, patching, web-attack protection, payment-page script control and change management, with the records an assessor samples and the parts that became mandatory on 31 March 2025. PCI DSS Requirement 6 Secure SDLC Payment page security E-skimming Change management Compliance evidence CWE-1395 V3.6 V15.1 V15.2 What changed in PCI DSS v4.0.1 and on 31 March 2025? What does Requirement 6 cover? Which practice and evidence answers each requirement? How do you build the 6.2.4 attack classes into standards and tests? How do you enforce review and release approval in the pipeline? How fast must vulnerabilities be ranked and patched? What automated attack protection do public web apps need? How do you control every script on the payment page? Where should the payment-page script inventory live? How do you detect changes the way the browser sees the page? How does the pipeline serve as change control?", "key": "pci-dss-requirement-6", "domain": "governance", "topic": "Map PCI DSS Requirement 6 to engineering practice and evidence", "title": "Map PCI DSS Requirement 6 to engineering practice and evidence", "path": "https://softwaresecurity.com/frameworks/pci-dss-requirement-6/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-champions-program Run a security champions program with protected time and outcome metrics Put a trained engineer with protected hours in every in-scope team, write the role into a one-page charter, route sensitive changes and findings through champions and AppSec, and judge the program by coverage and outcomes instead of attendance. Security champions AppSec program Security culture Training OWASP SAMM BSIMM CODEOWNERS What does a security champion do? How do you choose champions and plan for turnover? How much time do champions need? What goes in a champion charter? How should champions be trained? Route work between teams, champions and AppSec How do you measure a champions program? Compare each team with its own past Compute review reach from pull-request data Avoid the failure modes that stall programs How does the program map to SAMM, BSIMM and SSDF?", "key": "security-champions-program", "domain": "governance", "topic": "Run a security champions program with protected time and outcome metrics", "title": "Run a security champions program with protected time and outcome metrics", "path": "https://softwaresecurity.com/frameworks/security-champions-program/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "vulnerability-prioritization Prioritize vulnerabilities by exploitation, exposure and impact Rank vulnerabilities with CISA KEV, EPSS, CVSS 4.0 vectors and SSVC decision points, adjust for presence, reachability and asset value, and turn the result into due dates. Covers NVD's 2026 enrichment changes and CISA BOD 26-04. CVSS 4.0 EPSS CISA KEV SSVC NVD Reachability Remediation SLA Vulnerability management CWE-1395 EPSS CVSS KEV SSVC vulnerability prioritization Known Exploited Vulnerabilities Exploit Prediction Scoring System What does each signal tell you? How do CVSS, EPSS, KEV and SSVC compare? How do you read a CVSS 4.0 score? What changed from CVSS 3.1 to 4.0, and why do scanners disagree? How should you use EPSS? What does a KEV listing mean, and what are the 2026 due dates? Where do SSVC decision points come from? What if NVD has not enriched a CVE? Which data source answers which question? How do presence, reachability, exposure and asset value change priority? How do the signals map to an action and a due date? How do you encode the table so every finding gets the same answer? How do you keep the policy reviewable as data? Which mistakes put the wrong work first? How do you verify the process, and which tools help?", "key": "vulnerability-prioritization", "domain": "governance", "topic": "Prioritize vulnerabilities by exploitation, exposure and impact", "title": "Prioritize vulnerabilities by exploitation, exposure and impact", "path": "https://softwaresecurity.com/frameworks/vulnerability-prioritization/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "ai-assisted-development Secure AI-assisted development with coding assistants and agents Treat generated code, suggested packages, repository text and MCP servers as untrusted inputs, and confine coding agents with OS-level isolation and short-lived, narrowly scoped credentials. AI coding assistants Coding agents Slopsquatting Prompt injection MCP Sandboxing Secrets CWE-1427 What changes when an assistant writes and runs code Review generated code as an outside contribution Example: a generated helper that passes the obvious test Fix: resolve the path, then check containment Block hallucinated and freshly registered packages Add a release-age cooldown to every package manager Treat issues, PRs and repository files as untrusted instructions Contain the agent with OS-level isolation and narrow credentials Keep secrets out of what the assistant sends Install MCP servers like code and run them isolated Turn the policy into settings, owners and CI gates Controls that look stronger than they are Tooling", "key": "ai-assisted-development", "domain": "ai-emerging", "topic": "Secure AI-assisted development with coding assistants and agents", "title": "Secure AI-assisted development with coding assistants and agents", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/ai-assisted-development/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Run model-generated Python in a locked-down container", "path": "https://softwaresecurity.com/labs/#project-agent-code-sandbox", "download": "https://softwaresecurity.com/downloads/projects/agent-code-sandbox-ca88c140c78d6501.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-requirements-definition-of-done Write testable security requirements and a security Definition of Done Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done. Security requirements Definition of done Acceptance criteria OWASP ASVS Abuse cases Traceability security requirements definition of done acceptance criteria security acceptance criteria security definition of done What makes a security requirement testable? Where do security requirements come from? Which ASVS level should an application target? How do you pick ASVS requirements for one feature? How do you write security acceptance criteria? How do the criteria become automated tests? How do you trace requirements to evidence? How do you stop a story closing without its tests? What goes in a security Definition of Done? What do SSDF, SAMM and PCI DSS expect here? Where do security requirements go wrong?", "key": "security-requirements-definition-of-done", "domain": "appsec", "topic": "Write testable security requirements and a security Definition of Done", "title": "Write testable security requirements and a security Definition of Done", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/security-requirements-definition-of-done/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "abuse-case-library Abuse case library: tests and controls by feature Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC. Abuse cases Misuse cases Security testing Business logic CAPEC Security requirements CWE-307 CWE-204 CWE-640 CWE-841 CWE-345 CWE-1236 CWE-1427 CAPEC-600 CAPEC-565 CAPEC-575 CAPEC-50 CAPEC-650 CAPEC-126 CAPEC-26 CAPEC-664 CAPEC-66 CAPEC-87 CAPEC-62 abuse cases abuse case misuse cases evil user stories How do you use this library? Sign-up and login Password reset MFA enrolment Invites File upload Payments and coupons Webhooks Search Export Admin functions AI chat or agent How do you record an abuse case? What do the coupon and webhook controls look like in code? How do you automate abuse-case tests?", "key": "abuse-case-library", "domain": "appsec", "topic": "Abuse case library: tests and controls by feature", "title": "Abuse case library: tests and controls by feature", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/abuse-case-library/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "threat-pattern-library Threat pattern library for threat modeling Thirty-two recurring threat patterns grouped by identity, authorization, parsers, concurrency, integrations, data exposure, supply chain, availability and AI agents, each with where it shows up on a data-flow diagram, mitigations, a verification step and STRIDE, CWE and CAPEC links, plus a YAML catalog and a script that lists patterns per diagram element. Threat patterns Threat modeling STRIDE Data-flow diagram CAPEC Secure design CWE-290 CWE-441 CWE-436 CWE-367 CWE-294 CWE-532 CWE-1427 CAPEC-21 CAPEC-1 CAPEC-66 CAPEC-33 CAPEC-586 CAPEC-29 CAPEC-664 CAPEC-141 CAPEC-538 CAPEC-130 threat patterns threat pattern library How do you use a threat pattern library? Which identity and trust patterns recur? Which authorization and tenancy patterns recur? Which input and parser patterns recur? Which state, concurrency and replay patterns recur? Which integration and outbound-call patterns recur? Which data exposure and logging patterns recur? Which secrets and supply-chain patterns recur? Which availability patterns recur? Which AI and agent patterns recur? How do you keep the patterns machine-readable? How do you list the patterns for a diagram automatically?", "key": "threat-pattern-library", "domain": "appsec", "topic": "Threat pattern library for threat modeling", "title": "Threat pattern library for threat modeling", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/threat-pattern-library/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "secure-by-design-principles Apply CISA Secure by Design: principles, pledge goals and evidence What CISA's Secure by Design guidance and pledge ask of software manufacturers as of October 2026, and how to turn each of the three principles, the seven pledge goals and the Product Security Bad Practices into engineering actions, metrics and evidence. Secure by Design Secure by default CISA Secure by Design pledge Memory safety Product security CWE-798 CWE-1392 Secure by Design Secure by Design pledge secure by default Product Security Bad Practices CISA Secure by Design What is Secure by Design, and what is its status in 2026? What are the three Secure by Design principles? What does \"secure by default\" require of a product? What do the seven pledge goals ask, and what should engineering do? Which product security bad practices should you remove first? What does CISA expect on memory safety? How do you track evidence for each goal? How do you measure MFA adoption the way the pledge suggests? How do you check that your CVE records are complete? How does Secure by Design relate to binding obligations? Where do Secure by Design programs go wrong?", "key": "secure-by-design-principles", "domain": "governance", "topic": "Apply CISA Secure by Design: principles, pledge goals and evidence", "title": "Apply CISA Secure by Design: principles, pledge goals and evidence", "path": "https://softwaresecurity.com/frameworks/secure-by-design/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "choosing-bsimm-samm-ssdf BSIMM vs SAMM vs SSDF: what each is for and which to use How BSIMM16, OWASP SAMM 2.2.0 and NIST SSDF 1.1 differ, what each measures and does not, a chooser by situation, and a verified SSDF-to-BSIMM16-and-SAMM crosswalk with a script that reports evidence gaps. BSIMM OWASP SAMM NIST SSDF Maturity models Benchmarking Secure development BSIMM BSIMM16 Building Security In Maturity Model BSIMM vs SAMM SAMM vs BSIMM SSDF vs SAMM What are BSIMM, SAMM and SSDF? BSIMM vs SAMM vs SSDF: how do they differ? Which one should you use? How do you use them together without triple work? What does a verified crosswalk look like? How do you find SSDF tasks without evidence? Can you compare a SAMM score with a BSIMM scorecard? What about other frameworks? Where do framework choices go wrong?", "key": "choosing-bsimm-samm-ssdf", "domain": "governance", "topic": "BSIMM vs SAMM vs SSDF: what each is for and which to use", "title": "BSIMM vs SAMM vs SSDF: what each is for and which to use", "path": "https://softwaresecurity.com/frameworks/bsimm-samm-ssdf/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "developer-security-training-program Run a developer security training program that changes code Build role-based, hands-on developer security training from this site's learning paths, labs and fix cards, meet PCI DSS 6.2.2, NIST SSDF PO.2.2 and ISO/IEC 27001 A.6.3 with real evidence, and measure the effect with repeat findings instead of completion rates. Developer training Security training Secure coding PCI DSS 6.2.2 Security metrics Learning paths security training developer training secure coding training security awareness training for developers Why hands-on training instead of slides? What do PCI DSS 6.2.2, SSDF PO.2.2 and ISO 27001 A.6.3 require? What should each role learn? How do you keep the curriculum in one place? How do you train at the moment of need? Which hands-on formats work? What evidence will an auditor ask for? How do you know training worked? How do you measure repeat findings before and after training? How often, and how long? Where do training programs go wrong?", "key": "developer-security-training-program", "domain": "governance", "topic": "Run a developer security training program that changes code", "title": "Run a developer security training program that changes code", "path": "https://softwaresecurity.com/frameworks/developer-security-training/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "psirt-operating-model Set up a PSIRT: services, intake, triage, SLAs and the CNA role How to structure and run a product security incident response team on the FIRST PSIRT Services Framework: organizational models, intake channels, triage, response targets, a case record and SLA script, becoming a CVE Numbering Authority under the CNA rules 4.2.0, and coordinating with other vendors. PSIRT Vulnerability handling CVE Numbering Authority Coordinated disclosure FIRST PSIRT Services Framework Vulnerability response PSIRT CVE Numbering Authority product security incident response team becoming a CNA What does a PSIRT do, and how is it different from a CSIRT? What services does the FIRST PSIRT Services Framework define? Which organizational model fits your company? Who does what in a PSIRT case? How should vulnerability reports reach you? How do you triage a report? What response targets should a PSIRT set? What should a PSIRT case record contain? How do you check every case against its targets? Should you become a CVE Numbering Authority? How do you coordinate with other vendors? What should a PSIRT measure?", "key": "psirt-operating-model", "domain": "appsec", "topic": "Set up a PSIRT: services, intake, triage, SLAs and the CNA role", "title": "Set up a PSIRT: services, intake, triage, SLAs and the CNA role", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/psirt-operating-model/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "security-advisories-csaf-vex Publish security advisories with CSAF, VEX, CVE records and OSV What a useful security advisory contains and how to publish it in the formats tools read: a validated CSAF 2.0 VEX document, the CSAF provider files, CVE records through a CNA (CVE Record Format 5.2), and OSV records for open-source packages. Covers the status of CSAF 2.1 as of October 2026. CSAF Security advisory CVE records CVE OSV Vulnerability disclosure CWE-306 CSAF Common Security Advisory Framework security advisory OSV advisory publishing machine-readable advisories What does a useful security advisory contain? Which formats should you publish? What is CSAF, and is CSAF 2.1 final? Which product status should you use: affected, fixed or not affected? What does a valid CSAF document look like? How do customers find your CSAF documents? How do you get a CVE ID? How do you publish OSV records for open-source packages? How do you publish all formats without errors? What goes wrong when publishing advisories?", "key": "security-advisories-csaf-vex", "domain": "appsec", "topic": "Publish security advisories with CSAF, VEX, CVE records and OSV", "title": "Publish security advisories with CSAF, VEX, CVE records and OSV", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/security-advisories-csaf-vex/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "product-incident-response Respond to product security incidents: plan, tabletop and postmortem An incident response plan for product security incidents (exploited vulnerabilities, compromised releases, leaked signing keys, malicious dependencies shipped to customers), aligned with NIST SP 800-61 Rev. 3, with reporting clocks, a two-scenario tabletop exercise template and a blameless postmortem template. Incident response Postmortem Tabletop exercise Incident response plan Product security NIST SP 800-61 postmortem blameless postmortem tabletop exercise incident response plan post-incident review incident retrospective What counts as a product security incident? How does NIST SP 800-61 Rev. 3 frame incident response? Who does what during an incident? What goes in the incident response plan? What should happen in the first hour? Which reporting clocks can start? How should you communicate with customers during an incident? How do you run a tabletop exercise? What goes in a blameless postmortem? Where does product incident response go wrong?", "key": "product-incident-response", "domain": "appsec", "topic": "Respond to product security incidents: plan, tabletop and postmortem", "title": "Respond to product security incidents: plan, tabletop and postmortem", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/product-incident-response/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "appsec-careers Build an application security career: roles, skills, portfolio and certifications The main application security role tracks (AppSec engineer, product security engineer, security champion, platform security engineer, security architect), the skills expected at each level, how to build a portfolio a hiring team can verify using this site's labs, projects and fix cards, and what common certifications do and do not show. AppSec career Security engineering Certifications Security architect Product security Interview preparation AppSec career certifications security architect OSWE CSSLP application security jobs AppSec jobs security career What are the main AppSec role tracks? What skills are expected at each level? How do you find your own skill gaps? What does the gap script check? How do you build an AppSec portfolio? Which certifications are worth it, and what do they show? How do AppSec interviews work, and how do you prepare? How do developers move into AppSec? How should hiring managers assess AppSec candidates?", "key": "appsec-careers", "domain": "governance", "topic": "Build an application security career: roles, skills, portfolio and certifications", "title": "Build an application security career: roles, skills, portfolio and certifications", "path": "https://softwaresecurity.com/frameworks/appsec-careers/", "platforms": [ "Cross-platform" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "soc2-for-engineering-teams SOC 2 SOC 2 for engineering teams: CC6, CC7 and CC8 controls and the evidence auditors test What a SOC 2 report covers, which Trust Services Criteria engineering owns (CC6 logical access, CC7 system operations, CC8 change management), the controls that meet them in a modern pipeline, and how to export a complete change population for a Type 2 period. SOC 2 Trust Services Criteria Change management Access reviews Audit evidence SOC 2 Type 2 SaaS Cloud services Engineering organizations SOC 2 Trust Services Criteria change population SOC2 SOC 2 Type II SOC 2 audit What is a SOC 2 report, and what does engineering produce for it? What do the CC6 access criteria mean in engineering terms? What do the CC7 system operations criteria ask for? How does CC8 change management map to your pipeline? How do you give the auditor a complete change population? How do you keep evidence for every control? What does a SOC 2 report not cover?", "key": "soc2-for-engineering-teams", "domain": "governance", "topic": "SOC 2", "title": "SOC 2 for engineering teams: CC6, CC7 and CC8 controls and the evidence auditors test", "path": "https://softwaresecurity.com/frameworks/soc2-for-engineering-teams/", "platforms": [ "SaaS", "Cloud services", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "iso-27001-secure-development ISO/IEC 27001 ISO 27001 secure development: Annex A 8.25 to 8.33 as engineering practice and evidence How ISO/IEC 27001:2022 treats secure development, what the Annex A development controls (8.4, 8.8, 8.9 and 8.25 to 8.33) look like as engineering practice, and how to keep the Statement of Applicability and its evidence honest with checks in code. ISO 27001 ISO/IEC 27002 Annex A Secure coding Statement of Applicability ISMS Engineering organizations Cloud services SaaS ISO 27001 Annex A Statement of Applicability secure coding ISO27001 ISO/IEC 27002 How does ISO 27001 treat secure development? Which Annex A controls cover development, and what do they look like in practice? What does 8.28 secure coding mean for a team? How do you show separate environments and controlled change in code? How do you keep the Statement of Applicability honest? What does the SoA check do? How do these controls relate to SSDF, SOC 2 and the CRA?", "key": "iso-27001-secure-development", "domain": "governance", "topic": "ISO/IEC 27001", "title": "ISO 27001 secure development: Annex A 8.25 to 8.33 as engineering practice and evidence", "path": "https://softwaresecurity.com/frameworks/iso-27001-secure-development/", "platforms": [ "Engineering organizations", "Cloud services", "SaaS" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "nist-csf-2-for-product-teams NIST Cybersecurity Framework NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them Find the CSF 2.0 outcomes a product team actually owns, including GOVERN and supply-chain risk management (GV.SC), write a current and target profile for one product, and check it against NIST's own catalog in CI. NIST CSF 2.0 Cybersecurity Framework GOVERN function Supply chain risk management Organizational Profile OSCAL Engineering organizations Software products NIST CSF Cybersecurity Framework GV.SC CSF 2.0 NIST Cybersecurity Framework 2.0 What does CSF 2.0 give a product team? What does GOVERN ask of the people who build software? What does GV.SC mean for the software you build and buy? Which other subcategories does engineering evidence answer? How do you write a profile for one product? How do you keep the profile valid in CI? How do CSF, SSDF and SP 800-53 fit together?", "key": "nist-csf-2-for-product-teams", "domain": "governance", "topic": "NIST Cybersecurity Framework", "title": "NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them", "path": "https://softwaresecurity.com/frameworks/nist-csf-2-for-product-teams/", "platforms": [ "Engineering organizations", "Software products" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "gdpr-privacy-by-design-engineering Privacy engineering GDPR privacy by design for engineers: Articles 25, 32 and 35 in code Turn GDPR data protection by design and by default, security of processing and DPIA triggers into engineering work: a personal-data inventory checked in CI, defaults that collect and share less, a DPIA screen at design time, and access and erasure requests that reach every store. GDPR Privacy by design Data protection by default DPIA Data subject rights Right to erasure Pseudonymization Web & APIs Data services Engineering organizations privacy by design DPIA data subject request right to erasure data protection impact assessment DSAR Article 25 What do Articles 25, 32 and 35 ask of engineers? How do you stop new personal data slipping in unreviewed? What does the inventory check look like? What does data protection by default look like in a product? How do you show Article 32 security of processing? When does a feature need a DPIA? How do you build data subject rights into the system? How do you test that erasure really works? What is changing, and what isn't?", "key": "gdpr-privacy-by-design-engineering", "domain": "governance", "topic": "Privacy engineering", "title": "GDPR privacy by design for engineers: Articles 25, 32 and 35 in code", "path": "https://softwaresecurity.com/frameworks/gdpr-privacy-by-design-engineering/", "platforms": [ "Web & APIs", "Data services", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "nis2-dora-for-software-suppliers EU regulation NIS2 and DORA for software suppliers: what reaches you and the evidence to keep Work out whether NIS2 applies to your software company directly or only through customers, what Article 21 risk-management measures and DORA's ICT third-party rules ask of suppliers, and how to keep one assurance pack and register data sheet for both. NIS2 DORA Digital Operational Resilience Act Supply chain security ICT third-party risk Register of information EU regulation Software products Cloud services Engineering organizations NIS2 DORA register of information ICT third-party risk NIS 2 Digital Operational Resilience Act Do NIS2 and DORA apply to a software company? What do NIS2 Article 21 measures mean for engineering? What does Implementing Regulation 2024/2690 ask of development? What will NIS2 customers ask their software suppliers? What does DORA require in contracts with ICT providers? What data will a financial customer need for its register of information? How do you keep one assurance pack for NIS2 and DORA customers? What does the assurance pack check do? Where do transposition and the proposed changes stand?", "key": "nis2-dora-for-software-suppliers", "domain": "governance", "topic": "EU regulation", "title": "NIS2 and DORA for software suppliers: what reaches you and the evidence to keep", "path": "https://softwaresecurity.com/frameworks/nis2-dora-for-software-suppliers/", "platforms": [ "Software products", "Cloud services", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "uk-software-security-code-of-practice UK software security UK Software Security Code of Practice: the 14 principles as engineering practice What the UK government's voluntary Software Security Code of Practice (May 2025) asks of software vendors, each of its 14 principles mapped to engineering practice, NIST SSDF and the EU Cyber Resilience Act, and a CI check for the support-period principles. UK Software Security Code of Practice UK code of practice DSIT NCSC Secure by design End of support Vulnerability disclosure Software products Engineering organizations Software Security Code of Practice Senior Responsible Owner UK code of practice NCSC code of practice What is the Code, and who is it for? What are the 14 principles, and what do they mean in practice? How do you meet the build environment principles? What do the vulnerability and update principles need? How do you meet the support-period principles? How do you check the support policy in CI? How do you show conformance?", "key": "uk-software-security-code-of-practice", "domain": "governance", "topic": "UK software security", "title": "UK Software Security Code of Practice: the 14 principles as engineering practice", "path": "https://softwaresecurity.com/frameworks/uk-software-security-code-of-practice/", "platforms": [ "Software products", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "regulated-product-security-lifecycle Regulated products Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156 What the secure development lifecycles for industrial, medical and automotive products require, the practices they share (threat modeling, SBOM, vulnerability handling and updates), and how to build that evidence once and package it for each instrument. IEC 62443-4-1 FDA 524B Medical device cybersecurity ISO/SAE 21434 UN R155 UN R156 Product security lifecycle Embedded Software products Engineering organizations IEC 62443-4-1 ISO/SAE 21434 cyber device UN R155 FDA 524B medical device cybersecurity automotive cybersecurity IEC 62443 What do these lifecycles have in common? What does IEC 62443-4-1 require? What does FDA section 524B require for a cyber device? How do you check SBOM support information against the device's life? What does the support check do? What do UN R155, R156 and ISO/SAE 21434 require? How do you run one lifecycle for several instruments?", "key": "regulated-product-security-lifecycle", "domain": "governance", "topic": "Regulated products", "title": "Regulated product security lifecycles: IEC 62443-4-1, FDA 524B, ISO/SAE 21434 and UN R155/R156", "path": "https://softwaresecurity.com/frameworks/regulated-product-security-lifecycle/", "platforms": [ "Embedded", "Software products", "Engineering organizations" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "compliance-evidence-reuse Control mappings Compliance evidence reuse: one evidence set for SSDF, PCI DSS, ISO 27001, SOC 2 and the CRA Keep one set of release-bound engineering evidence (SBOM, provenance, review records, scan results, ASVS results and vulnerability handling) and map it to several frameworks: a worked crosswalk, an evidence index checked in CI with a CSV export, and an OSCAL component definition. Compliance evidence Crosswalk Evidence reuse OSCAL SBOM Build provenance Control mapping Engineering organizations Build systems SaaS crosswalk evidence index OSCAL control crosswalk common controls compliance automation Why keep one evidence set instead of one per framework? What makes evidence reusable? Which requirements does each piece of evidence support? How do you index the evidence? How do you check the index and export the crosswalk? How do you hand the same evidence to OSCAL tools? How do you validate the OSCAL document? Where does reuse stop?", "key": "compliance-evidence-reuse", "domain": "governance", "topic": "Control mappings", "title": "Compliance evidence reuse: one evidence set for SSDF, PCI DSS, ISO 27001, SOC 2 and the CRA", "path": "https://softwaresecurity.com/frameworks/compliance-evidence-reuse/", "platforms": [ "Engineering organizations", "Build systems", "SaaS" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "federal-software-attestation Software attestation Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement Know what is and isn't required after OMB M-26-05, then answer an agency's request statement by statement, with the SSDF tasks the form maps and release evidence for each claim. Software attestation NIST SSDF SP 800-218 Procurement Supplier risk Compliance evidence Lifecycle evidence Engineering organizations Software products attestation form M-26-05 POA&M 3PAO CISA attestation form secure software self-attestation SSDF attestation What is the legal and policy status in October 2026? What may an agency still ask for? What does the form contain, part by part? Which SSDF tasks does each statement map to, and what evidence backs it? How do you keep the evidence per statement? How do you check the index before anyone signs? What if you can't attest to every statement? What can vary from one agency to another? Who signs, and what does the signature cover? Will SSDF 1.2 change the form?", "key": "federal-software-attestation", "domain": "governance", "topic": "Software attestation", "title": "Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement", "path": "https://softwaresecurity.com/frameworks/secure-software-attestation-form/", "platforms": [ "Engineering organizations", "Software products" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "secrets-in-kubernetes-and-runtime Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS How a running workload should get its credentials: encrypt Kubernetes Secrets with a KMS v2 provider and lock down RBAC, mount from an external store with the Secrets Store CSI Driver, sync with External Secrets Operator, issue dynamic credentials with Vault and its Agent Injector, keep Git copies encrypted with SOPS, and make rotation reach the process. Secrets management Kubernetes Secrets HashiCorp Vault Vault Agent Injector Secrets Store CSI Driver External Secrets Operator SOPS etcd encryption Credential rotation Kubernetes AWS Google Cloud Azure CWE-798 CWE-522 CWE-312 CWE-732 V13.3.1 V13.3.2 V13.3.4 V13.2.1 CAPEC-37 CAPEC-560 K03:2025 Vault Agent Injector External Secrets Operator Secrets Store CSI Driver SOPS OpenBao KMS v2 Kubernetes secrets management Vault injector ESO Which delivery pattern should a workload use? Encrypt Kubernetes Secrets at rest with a KMS v2 provider Grant get on named Secrets, never list or watch Mount secrets from the store with the Secrets Store CSI Driver Sync into Kubernetes Secrets with External Secrets Operator Issue short-lived database credentials with Vault Deliver Vault secrets with the Vault Agent Injector Vault, OpenBao and the license change Keep secrets in Git only encrypted, with SOPS and age Let Flux decrypt SOPS files inside the cluster How do cloud secret managers rotate secrets? Make each rotation reach the running process Verify encryption, access and rotation", "key": "secrets-in-kubernetes-and-runtime", "domain": "identity-crypto", "topic": "Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS", "title": "Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS", "path": "https://softwaresecurity.com/domains/identity-crypto/secrets/secrets-in-kubernetes-and-runtime/", "platforms": [ "Kubernetes", "AWS", "Google Cloud", "Azure" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-lastpass-2022 Case study: the LastPass breach (2022) How an attacker went from a compromised developer laptop to a DevOps engineer's home computer, the keys to LastPass's cloud backups and a copy of customer vaults; why each vault's safety then rested on its master password and PBKDF2 iteration count; and what it teaches about backup keys, privileged endpoints, KDF upgrades and unencrypted metadata. LastPass Data breach Password managers PBKDF2 Backup security Privileged access Secrets management AWS Cloud services CWE-522 CWE-311 CWE-1104 V13.3.1 V13.3.2 V11.4.2 V14.2.4 CAPEC-568 CAPEC-55 LastPass LastPass breach LastPass hack Two linked incidents in 2022 From a developer laptop to the backup keys What the backups contained Why the iteration count decided the damage What followed Lessons for teams that hold secrets", "key": "case-study-lastpass-2022", "domain": "identity-crypto", "topic": "Case study: the LastPass breach (2022)", "title": "Case study: the LastPass breach (2022)", "path": "https://softwaresecurity.com/domains/identity-crypto/secrets/case-study-lastpass-2022/", "platforms": [ "AWS", "Cloud services" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-okta-har-2023 Case study: the Okta support-system breach and session tokens in HAR files (2023) How a service account password saved to a personal browser profile let an attacker download customers' HAR files from Okta's support system, replay the session tokens inside them against five customers, and stay unseen for two weeks; and why HAR files are credentials, admin sessions need binding, and every exposed credential must be rotated. Okta HAR files Session hijacking Session tokens Support systems Service accounts Incident response Web Cloud services CWE-522 CWE-532 CWE-294 CWE-613 V7.4.1 V7.4.2 V7.5.1 V16.2.1 CAPEC-593 CAPEC-60 CAPEC-560 Okta HAR file HAR files Okta breach Okta HAR Okta support breach A support system full of live session tokens A service-account password in a personal browser profile Why a HAR file is a credential Why the downloads went unnoticed for two weeks What stops a stolen session token Rotate everything the incident exposed Lessons for builders and support teams", "key": "case-study-okta-har-2023", "domain": "identity-crypto", "topic": "Case study: the Okta support-system breach and session tokens in HAR files (2023)", "title": "Case study: the Okta support-system breach and session tokens in HAR files (2023)", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/case-study-okta-har-2023/", "platforms": [ "Web", "Cloud services" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-certificate-expiry Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot How an expired certificate inside Ericsson's core-network software cut mobile data for millions in about 11 countries, how an expired authentication certificate took Microsoft Teams offline, how an expired inspection certificate left Equifax blind for 19 months, through its 2017 breach, and the inventory, automation and testing that prevent each. Certificate expiry Outages PKI TLS Certificate management Monitoring Incident review Web API Cloud CWE-298 CWE-324 CWE-295 V12.1.1 V12.2.2 V13.3.4 certificate expiry expired certificate Ericsson Microsoft Teams certificate outage certificate expired outage Ericsson 2018: a certificate inside the software Microsoft Teams 2020: an authentication certificate Equifax 2017: an expired certificate that blinded monitoring Let's Encrypt 2021: when a root certificate expires Why certificates still expire unnoticed What to do today: inventory, automate, monitor, test", "key": "case-study-certificate-expiry", "domain": "identity-crypto", "topic": "Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot", "title": "Case study: certificate expiry outages at Ericsson (2018) and Microsoft Teams (2020), and Equifax's blind spot", "path": "https://softwaresecurity.com/domains/identity-crypto/key-management-pki/case-study-certificate-expiry/", "platforms": [ "Web", "API", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "file-inclusion File inclusion Prevent file inclusion: LFI, RFI, dynamic imports and template names Stop request data from choosing which file, module or template your application loads: local and remote file inclusion in PHP, dynamic require() and import() in Node.js, importlib and template names in Python, Thymeleaf view names in Spring, render in Rails, and the allowlist fix that works in all of them. File inclusion Local file inclusion Remote file inclusion LFI RFI Dynamic import Template include Path traversal PHP Web APIs PHP Node.js Python Flask Spring Rails Go CWE-98 CWE-73 A05:2025 V5.3.1 V5.3.2 V1.3.2 V1.3.7 CAPEC-252 CAPEC-193 WSTG-INPV-11 WSTG-ATHZ-01 file inclusion local file inclusion remote file inclusion LFI RFI dynamic import template include directory traversal include PHP file inclusion See how a filename parameter chooses code to run Spot the vulnerable include in PHP Rate a local file inclusion as code execution Map a key to a fixed file in PHP Check the exact value you include Harden PHP so a missed include does less damage Don't build require() or import() specifiers from input Use a map of loaders in Node.js Keep importlib away from request data in Python Choose template names in code, not in the request Never return request data as a Spring view name Keep render options and template names static in Rails and Express Embed templates and look them up by name in Go Contain a path when you truly must accept one Find inclusion points with scanners and payloads Learn from real file inclusion failures", "key": "file-inclusion", "domain": "appsec", "topic": "File inclusion", "title": "Prevent file inclusion: LFI, RFI, dynamic imports and template names", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/file-inclusion/", "platforms": [ "Web", "APIs", "PHP", "Node.js", "Python", "Flask", "Spring", "Rails", "Go" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [ { "title": "File upload lab: Accept avatars without publishing pages", "path": "https://softwaresecurity.com/labs/file-upload/" } ], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "insecure-temp-files Temporary files Create temporary files safely: mkstemp, O_EXCL and private directories Stop symlink, hardlink and pre-created-file attacks on the temporary files your code writes in shared directories such as /tmp: create each file atomically with O_EXCL and owner-only permissions through mkstemp or its equivalent in shell, Python, Java, Node.js, Go, .NET and Rust, keep related files in a private directory, and treat the Linux protected_* sysctls and systemd PrivateTmp as a backstop. Temporary files Insecure temp file Temp file race Symlink attack TOCTOU mkstemp O_EXCL O_TMPFILE PrivateTmp Linux C C++ Python Java Node.js Go .NET Rust CWE-377 CWE-379 CWE-59 CWE-367 V15.4 V15.4.2 V5.3.2 CAPEC-27 CAPEC-29 insecure temp file temp file race temporary file symlink attack mkstemp O_EXCL O_TMPFILE mkdtemp TOCTOU PrivateTmp tmp race condition predictable temp file name temp directory race See how a predictable name becomes someone else's file Spot the check-then-open pattern Create the file with mkstemp and keep the descriptor Shell, Node.js, .NET, Go and Rust Use TemporaryDirectory and exclusive opens in Python Use Files.createTempDirectory and explicit permissions in Java Turn on the Linux link and file protections Keep temporary files short-lived and never reopen them by name Find insecure temp file code in review and CI", "key": "insecure-temp-files", "domain": "appsec", "topic": "Temporary files", "title": "Create temporary files safely: mkstemp, O_EXCL and private directories", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/insecure-temp-files/", "platforms": [ "Linux", "C", "C++", "Python", "Java", "Node.js", "Go", ".NET", "Rust" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "third-party-api-consumption Unsafe consumption of APIs Consume third-party APIs safely (OWASP API10:2023) Treat every upstream and third-party API response as untrusted input: validate it against a schema, set connect and read timeouts, cap the response size, refuse to follow redirects blindly, keep TLS verification on, and scope the credentials you hold for each provider. Unsafe consumption of APIs Third-party API API10:2023 Timeouts Redirects TLS verification Trust boundary Webhooks Response validation APIs Backend Python Node.js TypeScript Go CWE-295 CWE-601 CWE-522 API10:2023 V1.3.6 V13.1.1 V5.4.1 CAPEC-141 CAPEC-275 unsafe consumption of APIs third-party API upstream trust boundary API10 upstream response consuming APIs safely Treat upstream data like user input Validate the response against a strict schema Set timeouts, because the defaults often don't Don't follow redirects blindly A fixed fetch wrapper: timeout, manual redirects, size cap Validate the parsed response in TypeScript A fixed httpx client in Python Test the timeout and redirect behavior Keep TLS verification on Draw the trust boundary around each provider Retry carefully, and make writes idempotent Verify inbound callbacks from providers Log upstream failures without leaking secrets Learn from client libraries that leaked across redirects", "key": "third-party-api-consumption", "domain": "appsec", "topic": "Unsafe consumption of APIs", "title": "Consume third-party APIs safely (OWASP API10:2023)", "path": "https://softwaresecurity.com/domains/appsec/secure-features/third-party-api-consumption/", "platforms": [ "APIs", "Backend", "Python", "Node.js", "TypeScript", "Go" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "secure-design-patterns Insecure design Secure design patterns: a catalogue for insecure-design (A06) A catalogue of reusable secure-design patterns, grouped by concern, each with when to use it, a short example and the failure it prevents: choke-point authorization, capability tokens, parse-don't-validate, safe-by-default APIs, tenant scoping, fail-closed, idempotency, and more. Secure design patterns Insecure design Choke point Capability token Parse don't validate Safe by default Tenant scoping Deny by default Web APIs Backend CWE-657 CWE-636 CWE-1188 A06:2025 V1.2 V1.3 secure design patterns choke point capability token parse don't validate safe by default tenant scoping deny by default insecure design secure by design design pattern catalogue Why design patterns, not just secure coding Choke-point authorization (deny by default) Capability tokens (object capabilities) Parse, don't validate Safe-by-default APIs Tenant scoping with a backstop Fail closed, least privilege and separation of duties Idempotency keys and explicit state machines More patterns worth naming in a review", "key": "secure-design-patterns", "domain": "appsec", "topic": "Insecure design", "title": "Secure design patterns: a catalogue for insecure-design (A06)", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/secure-design-patterns/", "platforms": [ "Web", "APIs", "Backend" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "threat-model-mobile-banking Threat modeling Worked threat model: a mobile banking app A complete worked threat model for a mobile banking-style app: the data-flow diagram and its elements, STRIDE threats on the client, the transport and the backend, and the mitigations mapped to OWASP MASVS v2 controls and current Android and iOS platform APIs. Threat model Mobile banking STRIDE MASVS Device binding App attestation Certificate pinning Worked example Android iOS APIs CWE-922 CWE-295 CWE-319 CWE-308 CWE-926 MASVS-STORAGE-1 MASVS-CRYPTO-1 MASVS-AUTH-2 MASVS-AUTH-3 MASVS-NETWORK-1 MASVS-NETWORK-2 MASVS-PLATFORM-1 MASVS-PLATFORM-3 MASVS-RESILIENCE-1 A06:2025 mobile banking mobile threat model banking app threat model Describe the system and its assumptions List the elements, data and trust boundaries STRIDE on the device STRIDE on the transport STRIDE on the client-facing API Account takeover paths that bypass the app Bind money movement to the device and the transaction Record residual risk and assumptions Keep the model current", "key": "threat-model-mobile-banking", "domain": "appsec", "topic": "Threat modeling", "title": "Worked threat model: a mobile banking app", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/mobile-banking-threat-model/", "platforms": [ "Android", "iOS", "APIs" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "threat-model-llm-agent Threat modeling Worked threat model: an LLM agent with tools A complete worked threat model for an LLM agent with tools: the data-flow diagram, the threats from prompt injection, excessive agency, data exfiltration, confused-deputy and memory poisoning, and the mitigations, mapped to the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026. Threat model LLM agent Prompt injection Excessive agency Data exfiltration MCP Worked example Agentic security Agent systems APIs CWE-1427 A06:2025 LLM agent agent threat model AI agent threat model Describe the agent and its assumptions List the elements, data and trust boundaries Enumerate the agent-specific threats Enforce authority outside the model Contain prompt injection; it cannot be fully prevented Close the exfiltration channels Scope retrieval and vet memory and MCP Record residual risk and keep the model current", "key": "threat-model-llm-agent", "domain": "appsec", "topic": "Threat modeling", "title": "Worked threat model: an LLM agent with tools", "path": "https://softwaresecurity.com/domains/appsec/threat-modeling/llm-agent-threat-model/", "platforms": [ "Agent systems", "APIs" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "llm-misinformation Misinformation Contain LLM misinformation (OWASP LLM07:2026) Stop plausible but wrong model output from driving decisions and actions: ground answers in sources, verify every citation, separate generation from execution with a claim-check-act pattern, gate consequential actions on a human, and evaluate factuality on your own domain. LLM misinformation Misinformation Hallucination Overreliance Grounding Citations Factuality evaluation LLM07:2026 Agent systems Python APIs CWE-1426 LLM07:2026 LLM misinformation misinformation hallucination overreliance grounding LLM07 package hallucination fabricated citations Understand what makes misinformation a security problem Treat overreliance as the thing you are designing against Ground answers in retrieved, current sources Verify that each citation supports its claim Separate generation from execution (claim-check-act) Put a human on consequential actions Verify generated code and dependencies before trusting them Measure factuality on your own domain, not confidence Design the interface to resist overreliance Learn from misinformation that reached production", "key": "llm-misinformation", "domain": "ai-emerging", "topic": "Misinformation", "title": "Contain LLM misinformation (OWASP LLM07:2026)", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/llm-misinformation/", "platforms": [ "Agent systems", "Python", "APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "calling-llm-apis-safely Calling LLM APIs Call a hosted LLM API safely A code-first checklist for wiring up an OpenAI or Anthropic API call from a backend: keep keys server-side, redact PII before prompts and logs, choose provider retention settings deliberately, validate structured output and still treat it as untrusted, and set timeouts, retries and per-user cost caps. LLM API OpenAI API Anthropic API API key security PII redaction Zero data retention Structured outputs Cost caps Agent systems APIs Python TypeScript Node.js FastAPI CWE-798 CWE-522 CWE-532 CWE-359 V13.1.1 V1.3.6 API key zero data retention structured output PII cost cap OpenAI API key safety OpenAI API key Anthropic API key LLM API security PII redaction Put the call behind your backend Hold the key server-side, scoped and rotatable Redact PII before the prompt and before logs A pattern-based redactor in TypeScript Choose the provider's retention setting deliberately Ask for structured output, then re-validate it Validate the output again in TypeScript Bound timeouts, retries and cost Log for debugging without leaking Tie it together in a backend endpoint The same shape with the Anthropic SDK", "key": "calling-llm-apis-safely", "domain": "ai-emerging", "topic": "Calling LLM APIs", "title": "Call a hosted LLM API safely", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/calling-llm-apis-safely/", "platforms": [ "Agent systems", "APIs", "Python", "TypeScript", "Node.js", "FastAPI" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "smart-contract-defi-attacks Smart contract security DeFi attack patterns: oracles, flash loans, proxies and signatures The four smart-contract attack classes beyond reentrancy: price-oracle manipulation, flash-loan amplification, upgradeable-proxy storage collisions and uninitialized implementations, and signature replay, each with vulnerable and fixed Solidity, Foundry tests and verified incidents. Smart-contract security Oracle manipulation Flash loan Upgradeable proxy Storage collision EIP-712 Signature replay OWASP Smart Contract Top 10 Smart contracts CWE-294 CWE-665 CWE-682 oracle manipulation flash loan upgradeable proxy storage collision EIP-712 signature replay proxy upgrade EIP-712 replay DeFi exploit flash loan attack Map the attack classes to the Smart Contract Top 10 See why a spot price is manipulable Price from a manipulation-resistant oracle Understand what a flash loan amplifies Lay out upgradeable storage so it cannot collide Disable the implementation's initializer Spot a replayable signature Bind a signature with EIP-712, a nonce and a deadline Test replay, cross-chain and expiry in Foundry Learn from verified DeFi incidents", "key": "smart-contract-defi-attacks", "domain": "appsec", "topic": "Smart contract security", "title": "DeFi attack patterns: oracles, flash loans, proxies and signatures", "path": "https://softwaresecurity.com/domains/appsec/smart-contracts/defi-attack-patterns/", "platforms": [ "Smart contracts" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "agent-code-sandboxing Agent sandboxing Sandbox model-generated code and computer-use agents Run the code an agent writes, and agents that drive a browser or desktop, inside a boundary built for hostile code: a disposable runtime with no secrets and no default network, hard resource limits, and a person in front of every side effect. AI agents Sandboxing Computer use agents Containers Human approval Remote code execution Egress Agent systems Containers Python CWE-653 ASI05:2026 V15.2.5 V15.2.2 V13.2.4 sandbox computer use gVisor Firecracker Code Interpreter microVM LLM code execution sandbox code interpreter security browser agent security Treat generated code as an attacker's code Choose the isolation boundary by what the code must do Lock the container down Pass files in and out as data, not as a shared folder Keep the network off, or name the destinations Keep secrets out of the sandbox, and fail closed Bound time, memory, CPU, processes and output Keep side effects outside the sandbox, behind an approval Computer-use and browser agents: the screen is untrusted input Test escapes, not just features Why prompts, denylists and the agent's own process are not sandboxes Check the result against concrete cases", "key": "agent-code-sandboxing", "domain": "ai-emerging", "topic": "Agent sandboxing", "title": "Sandbox model-generated code and computer-use agents", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/agent-code-sandboxing/", "platforms": [ "Agent systems", "Containers", "Python" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [ { "title": "Run model-generated Python in a locked-down container", "path": "https://softwaresecurity.com/labs/#project-agent-code-sandbox", "download": "https://softwaresecurity.com/downloads/projects/agent-code-sandbox-ca88c140c78d6501.zip" } ], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "hidden-context-exposure Hidden context Keep secrets and controls out of hidden context (OWASP LLM08:2026) OWASP LLM08:2026 Hidden Context Exposure, which replaced System Prompt Leakage: why system prompts, tool schemas and retrieved policy text get extracted, what must never be in them, and how to enforce rules where a leak changes nothing. LLM security System prompt leakage Hidden context exposure Prompt injection Secrets Tool authorization Web API Agent systems CWE-497 CWE-656 CWE-798 LLM08:2026 V13.3.1 V8.3.1 system prompt leakage hidden context system prompt canary LLM08 prompt leak system prompt extraction What counts as hidden context Why hidden context cannot be kept secret Rate the exposure by what is inside and what relies on it Move credentials and sensitive data out of the context Enforce rules where a leak changes nothing Treat leak-resistant prompting as a speed bump Test what a leak would give an attacker Check the result against concrete cases", "key": "hidden-context-exposure", "domain": "ai-emerging", "topic": "Hidden context", "title": "Keep secrets and controls out of hidden context (OWASP LLM08:2026)", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/hidden-context-exposure/", "platforms": [ "Web", "API", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "agent-memory-poisoning Agent memory Defend agent memory and context against poisoning (OWASP ASI06) OWASP ASI06 Memory & Context Poisoning: how an instruction or false fact saved once in agent memory, conversation summaries or a retrieval store steers later sessions, users and agents, and the write, scope, provenance, expiry and recovery controls that contain it. Agent memory AI agents Memory poisoning Context poisoning RAG security Prompt injection Data poisoning Agent systems Data services CWE-501 CWE-349 CWE-1427 ASI06:2026 V8.2.2 V14.2.7 memory poisoning context poisoning agent memory AML.T0080 ASI06 AI memory poisoning long-term memory poisoning What memory and context poisoning is Find every way text reaches durable memory Keep memory as data, never as instructions or permission Gate every write in code Scope memory to one user and one tenant Record provenance, expire what nobody verified, and keep history Treat retrieval stores as memory too Test poisoning across sessions, not within one Check the result against concrete cases", "key": "agent-memory-poisoning", "domain": "ai-emerging", "topic": "Agent memory", "title": "Defend agent memory and context against poisoning (OWASP ASI06)", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/agent-memory-poisoning/", "platforms": [ "Agent systems", "Data services" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-air-canada-chatbot Misinformation Case study: Moffatt v. Air Canada, a chatbot that misstated the refund policy (2022-2024) How an airline's website chatbot told a grieving customer they could claim a bereavement fare after travel, what the British Columbia Civil Resolution Tribunal decided in February 2024, and the grounding, testing and correction practices that keep an automated answer consistent with the policy it describes. Misinformation Overreliance Grounding Chatbots Customer support Incident response Web Air Canada Moffatt bereavement fare Air Canada chatbot Air Canada chatbot lawsuit A chatbot answer that contradicted the policy page How the airline responded What the tribunal decided What the decision does not establish Where engineering controls would have caught it Treat every automated answer on your site as your own, and test it against your policy", "key": "case-study-air-canada-chatbot", "domain": "ai-emerging", "topic": "Misinformation", "title": "Case study: Moffatt v. Air Canada, a chatbot that misstated the refund policy (2022-2024)", "path": "https://softwaresecurity.com/domains/ai-emerging/llm-security/case-study-air-canada-chatbot/", "platforms": [ "Web" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-nx-s1ngularity Coding agents Case study: the Nx s1ngularity compromise and its AI-assisted payload (2025) How a pull-request-title injection in a GitHub Actions workflow on an outdated branch gave an attacker the Nx npm token in August 2025, how the malicious versions tried to turn developers' own AI command-line tools into file-search agents, and the workflow, publishing and agent controls that stop the same chain. Supply chain attack GitHub Actions pull_request_target Trusted publishing Coding agents AI agents Install scripts Token theft GitHub Actions Package ecosystems JavaScript Agent systems s1ngularity Nx pull_request_target Nx compromise Nx supply chain attack singularity npm A build tool that turned developers' AI tools into file-search agents A pull request title, pull_request_target and an outdated branch What the malicious versions did What comes from third parties, not from Nx How Nx and npm responded Fix the workflow: environment variables, pull_request and no default write token Check a machine and an account for the indicators Lessons: fix workflows on every branch, publish without tokens, and keep AI agents on a short leash", "key": "case-study-nx-s1ngularity", "domain": "ai-emerging", "topic": "Coding agents", "title": "Case study: the Nx s1ngularity compromise and its AI-assisted payload (2025)", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/case-study-nx-s1ngularity/", "platforms": [ "GitHub Actions", "Package ecosystems", "JavaScript", "Agent systems" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-amazon-q-extension Coding agents Case study: the Amazon Q Developer extension compromise (2025) How an over-scoped GitHub token, extracted from an AWS CodeBuild pull request build, let a threat actor commit code to the Amazon Q Developer extension for VS Code that shipped in version 1.84.0 in July 2025, why the injected code aimed at the Q Developer CLI failed, and the CI and AI-agent controls the incident argues for. Supply chain attack CI/CD Token theft Coding agents AI agents Code review CI/CD Agent systems AWS CWE-522 CVE-2025-8217 Amazon Q CodeBuild AWS-2025-015 Amazon Q hack Amazon Q Developer compromise Malicious code in an AI coding assistant's release How a pull request build exposed a write token Code aimed at an AI agent, stopped by a syntax error What comes from the press, not from AWS Where the chain could have been broken Keep write tokens away from untrusted builds, and keep AI agents from acting alone", "key": "case-study-amazon-q-extension", "domain": "ai-emerging", "topic": "Coding agents", "title": "Case study: the Amazon Q Developer extension compromise (2025)", "path": "https://softwaresecurity.com/domains/ai-emerging/agent-security/case-study-amazon-q-extension/", "platforms": [ "CI/CD", "Agent systems", "AWS" ], "guide": true, "walkthrough": true, "codeExample": false, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-storm-0558 Case study: Storm-0558 and the forged Microsoft tokens (2023) How a stolen 2016 consumer signing key and a token validation gap let Storm-0558 read enterprise Exchange Online mail in 2023, and what the review board found about rotation, logging and culture. Storm-0558 Token forgery Signing keys Key rotation JWT validation Audit logging Security culture Incident review Cloud Azure SaaS CWE-324 V9.1.3 V11.1.1 V13.3.4 V16.3.2 CAPEC-196 Storm-0558 MailItemsAccessed Microsoft Exchange Online intrusion Microsoft signing key theft CSRB Microsoft report Forged tokens, signed by a key that should have been retired Timeline Why a consumer key worked on enterprise mail Why a 2016 key was still valid in 2023 Caught by a customer, with a log most customers did not have What the review board said about culture and candor Test that each key signs only for its own issuer Alert on signing keys that outlive their rotation limit Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-storm-0558", "domain": "identity-crypto", "topic": "Case study: Storm-0558 and the forged Microsoft tokens (2023)", "title": "Case study: Storm-0558 and the forged Microsoft tokens (2023)", "path": "https://softwaresecurity.com/domains/identity-crypto/authentication/case-study-storm-0558/", "platforms": [ "Cloud", "Azure", "SaaS" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-ingress-nginx Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025) How an admission webhook open to the whole Pod network made ingress-nginx's configuration-injection bugs a 9.8 cluster-takeover risk in 2025, and what its 2026 retirement means. ingress-nginx CVE-2025-1974 Kubernetes Admission control Configuration injection Secrets Network policy Vulnerability response Kubernetes Containers CWE-653 CWE-306 CVE-2025-1974 CVE-2025-24514 CVE-2025-1097 CVE-2025-1098 CVE-2025-24513 ingress-nginx IngressNightmare ingress nginx vulnerability ingress-nginx retirement An admission webhook anyone in the cluster could call Timeline Why the webhook made injection bugs critical Why one pod meant the whole cluster Fix, interim mitigation, and the retirement Find ingress-nginx controllers and their versions Let only the control plane reach admission webhooks Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-ingress-nginx", "domain": "runtime", "topic": "Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025)", "title": "Case study: ingress-nginx CVE-2025-1974 and the exposed admission webhook (2025)", "path": "https://softwaresecurity.com/domains/runtime/containers/case-study-ingress-nginx/", "platforms": [ "Kubernetes", "Containers" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-circleci-2023 Case study: the CircleCI security incident (January 2023) How a session stolen from one engineer's laptop reached CircleCI's production systems and customers' stored secrets in 2023, and what platform operators and CI users should change. CircleCI CI/CD Session hijacking Production access Secrets management OIDC Data breach Incident response CI/CD Cloud SaaS CWE-294 CWE-522 CWE-798 V13.2.1 V13.3.1 CircleCI CircleCI breach CircleCI hack CircleCI security incident One laptop, one session, every customer's secrets Timeline Why 2FA and encryption did not stop it What it meant for customers: rotate everything Deploy with OIDC instead of stored cloud keys Restrict which jobs can assume the role Order the rotation when your CI provider is breached Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-circleci-2023", "domain": "runtime", "topic": "Case study: the CircleCI security incident (January 2023)", "title": "Case study: the CircleCI security incident (January 2023)", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/case-study-circleci-2023/", "platforms": [ "CI/CD", "Cloud", "SaaS" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-microsoft-sas-token Case study: Microsoft AI researchers' over-permissive SAS token (2023) How an over-permissive Azure Storage SAS token in a public repository for AI models exposed internal Microsoft data in 2023, and how to scope, scan for and revoke signed URLs. Azure SAS tokens Signed URLs Secret scanning Leaked secrets AI research data Cloud storage Least privilege Azure Cloud CWE-732 CWE-798 V13.3.2 V13.3.4 SAS token shared access signature robust-models-transfer Microsoft 38TB leak Microsoft AI research data exposure Azure SAS token leak A link to AI training material that opened a storage account Timeline What a SAS token is, and why this one was dangerous Found by the scanner, closed as a false positive Why AI research data needs its own boundary Find SAS URLs and grade them without printing the secret Enforce short, scoped SAS at the account Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-microsoft-sas-token", "domain": "runtime", "topic": "Case study: Microsoft AI researchers' over-permissive SAS token (2023)", "title": "Case study: Microsoft AI researchers' over-permissive SAS token (2023)", "path": "https://softwaresecurity.com/domains/runtime/cloud-posture/case-study-microsoft-sas-token/", "platforms": [ "Azure", "Cloud" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-first-american Case study: First American's EaglePro document exposure (2019) How sequential IDs in unauthenticated links exposed First American's title documents in 2019, after its own penetration test found the flaw and a clerical error let it go unfixed. IDOR BOLA Broken access control Penetration testing Remediation SLA Risk acceptance Data breach Incident review Web APIs CWE-306 V8.2.2 V8.3.1 First American EaglePro First American data breach First American SEC order A document link that opened other customers' documents Timeline The flaw: sequential IDs, no login, no expiry Found in January, lost in triage What the people making statements did not know A regression test for object-level authorization Catch a finding that lost severity or missed its deadline Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-first-american", "domain": "appsec", "topic": "Case study: First American's EaglePro document exposure (2019)", "title": "Case study: First American's EaglePro document exposure (2019)", "path": "https://softwaresecurity.com/domains/appsec/authorization/case-study-first-american/", "platforms": [ "Web", "APIs" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-citrix-bleed Case study: Citrix Bleed (CVE-2023-4966) How a NetScaler memory over-read leaked session cookies that bypassed passwords and MFA in 2023, why patching did not end hijacked sessions, and how the pattern returned in 2025. Citrix Bleed CVE-2023-4966 Memory safety Out-of-bounds read Session hijacking MFA bypass Vulnerability response Mass exploitation C Web Software products CWE-119 CWE-613 V7.4.5 CAPEC-593 CVE-2023-4966 CVE-2025-5777 Citrix Bleed CitrixBleed 2 NetScaler CitrixBleed NetScaler session hijacking Leaked memory that contained live session cookies Timeline How a memory over-read became an MFA bypass Why patching did not end the intrusion It happened again in 2025 Check appliance builds against the fixes Revoke sessions after the update, in the vendor's order Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-citrix-bleed", "domain": "appsec", "topic": "Case study: Citrix Bleed (CVE-2023-4966)", "title": "Case study: Citrix Bleed (CVE-2023-4966)", "path": "https://softwaresecurity.com/domains/appsec/vulnerability-response/case-study-citrix-bleed/", "platforms": [ "C", "Web", "Software products" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-spring4shell Case study: Spring4Shell (CVE-2022-22965) How Spring's data binding let request parameters reach the class loader on JDK 9 and later in 2022, why the denylist workaround leaked, and what it teaches about framework-level mass assignment. Spring4Shell CVE-2022-22965 Spring Mass assignment Data binding Remote code execution Vulnerability response Dependency management Java Spring Web CAPEC-242 CVE-2022-22965 CVE-2022-22968 Spring4Shell SpringShell Spring Framework RCE A framework feature that let parameters reach the class loader Timeline Data binding is mass assignment by design Why exploitability depended on how the app was deployed Why the denylist workaround leaked Find exposed services from their SBOMs Bind only the fields a form declares Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-spring4shell", "domain": "appsec", "topic": "Case study: Spring4Shell (CVE-2022-22965)", "title": "Case study: Spring4Shell (CVE-2022-22965)", "path": "https://softwaresecurity.com/domains/appsec/secure-coding/case-study-spring4shell/", "platforms": [ "Java", "Spring", "Web" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "case-study-crowdstrike-channel-file-291 Case study: CrowdStrike Channel File 291 (July 2024) How a CrowdStrike content update crashed Windows hosts in July 2024: a field-count mismatch hidden by wildcard tests, a missing bounds check, and no staged rollout. CrowdStrike Content updates Staged rollout Rollback Out-of-bounds read Kernel drivers Outages Incident review Windows Desktop Software products CWE-129 CrowdStrike Channel File 291 Falcon sensor CrowdStrike outage CrowdStrike BSOD July 2024 Windows outage A content update, not a code update, crashed Windows Timeline Configuration data that drives kernel code How 21 declared fields met 20 supplied inputs Why every sensor got it at once Recovery when the host cannot boot Check content against the code that will run it Keep a bounds check where content picks the index Which controls would have stopped or limited it? Lessons that still apply What the public evidence does not establish", "key": "case-study-crowdstrike-channel-file-291", "domain": "appsec", "topic": "Case study: CrowdStrike Channel File 291 (July 2024)", "title": "Case study: CrowdStrike Channel File 291 (July 2024)", "path": "https://softwaresecurity.com/domains/appsec/platform-security/case-study-crowdstrike-channel-file-291/", "platforms": [ "Windows", "Desktop", "Software products" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." }, { "searchText": "staged-rollout-rollback Releases and updates Staged rollout and rollback for security-critical updates Ship security fixes, detection content and configuration quickly without taking the fleet down: rollout rings and canaries, content validation, kill switches and rollback that works on a broken host. Staged rollout Canary releases Rollback Content updates Kill switches Release management Anti-rollback Secure SDLC Software products Desktop Firmware SaaS CI/CD staged rollout canary ring bake time rollback anti-rollback floor progressive delivery phased rollout ring deployment canary release Why fast security updates need a slow start Rings, canaries and bake time Content updates are code updates Validate content against the code that will run it Automate the promotion gate Kill switches: stop distribution, disable a channel Rollback that works when the update broke the host Check the rollback target before you promote Let customers choose their ring Where this sits in SSDF and the other frameworks", "key": "staged-rollout-rollback", "domain": "supply-chain", "topic": "Releases and updates", "title": "Staged rollout and rollback for security-critical updates", "path": "https://softwaresecurity.com/domains/supply-chain/releases/staged-rollout-rollback/", "platforms": [ "Software products", "Desktop", "Firmware", "SaaS", "CI/CD" ], "guide": true, "walkthrough": true, "codeExample": true, "workshops": [], "projects": [], "next": "Apply the walkthrough to your supported stack and retain the evidence." } ] }