Software Securityhome
Fix a findingSearch
About

Coverage map

Every security outcome this site aims to cover, with its status, the guides, fix cards, labs and projects available for it, and what is still missing; planned outcomes and deliberate exclusions are listed with their reasons.

88 outcomes: 81 current, 2 historical references (counted by their status) and 5 out of scope. The material on each row is found from the content at every build. Browse every guide in the library, see the crosswalk by identifier, or download the map as JSON or CSV.

Coverage against public lists

How many entries of each list have a guide here (written about the entry, covering it in a dedicated section, or citing it), and how many have tested fix cards. SSDF counts the practices the guides name.

ListWith a guideWith fix cards
2025 CWE Top 2525 of 25 entries14 of 25
OWASP Top 10:202510 of 10 entries8 of 10
OWASP API Security Top 10 202310 of 10 entries6 of 10
OWASP Top 10 for LLM Applications 202610 of 10 entries0 of 10
OWASP Top 10 for Agentic Applications 202610 of 10 entries0 of 10
OWASP ASVS 5.0.017 of 17 chapters—
OWASP Kubernetes Top 10 202510 of 10 entries0 of 10
OWASP Top 10 CI/CD Security Risks10 of 10 entries0 of 10
OWASP MASVS 2.1.022 of 24 controls0 of 24
OWASP ASVS 5.0.0 requirements179 of 345 requirements51 of 345
NIST SSDF 1.1 practices19 of 19 practices—

88 outcomes

Application security23

APP-01Query and interpreter boundariesCovered8 guides · fix cards for 7 weaknesses · 6 labs · deepest: browser lab

Untrusted values cannot become query, command, template or expression structure.

Applies to: Node.js · Python · Java · C# · cross-platform parser design

Available material

Where coverage will grow

SQL injection has tested fixes in all ten fix-card stacks, OS command injection in six (Express, Flask, Spring Boot, ASP.NET Core, Next.js and Go), code injection in five (Express, Flask, Spring Boot's SpEL, ASP.NET Core and FastAPI), template injection in four (Express, Flask, Spring Boot and ASP.NET Core), XPath injection in three (Flask, Spring Boot and ASP.NET Core), and NoSQL and LDAP injection in two each (Express and Flask; Spring Boot and Flask). OS command and argument injection, and code, expression-language and template injection, each have a dedicated guide, and browser labs practise SQL injection, command injection and Jinja2 template injection. Not yet covered: command, code, template, XPath, NoSQL and LDAP injection cards for Rails and Laravel (Go has command injection only), and per-stack cards for expression languages other than SpEL.

Identifiers: CWE-89 · CWE-77 · CWE-78 · CWE-88 · CWE-94 · CWE-95 · CWE-90 · CWE-643 · CWE-917 · CWE-943 · CWE-1336

Mapped to: ASVS v5.0.0-1.2.4 (Relevant to the database-query portion)

APP-02Output contexts and rich textCovered3 guides · fix cards for 1 weakness · 2 labs · deepest: browser lab

User content is rendered safely in each parser context: HTML, attributes, URLs, scripts and the DOM.

Applies to: Browser HTML and DOM · server templates

Available material

Where coverage will grow

Server-side output encoding has tested fixes in nine stacks, every fix-card stack except FastAPI. Sanitizer and Trusted Types configurations are taught with examples, without a browser-run regression suite.

Identifiers: CWE-79 · CWE-116

APP-03Object, action and field permissionsCovered6 guides · fix cards for 2 weaknesses · 5 labs · 1 project · deepest: local project

Every sensitive read or write checks the current actor, tenant, action and object relationship.

Applies to: HTTP APIs · Node.js and Express

Available material

Where coverage will grow

Add revocation tests across distributed caches and examples for policy engines other than OPA.

Identifiers: CWE-639 · CWE-862 · CWE-863 · CWE-915 · CWE-284 · CWE-285

Mapped to: ASVS v5.0.0-8.2.2 (Relevant to per-object data access) · ASVS v5.0.0-8.4.1 (Relevant to cross-tenant isolation) · WSTG v4.2 WSTG-ATHZ-04 (Supports a method for changing object references across authorized test accounts)

APP-04Browser request and response policyCovered3 guides · fix cards for 3 weaknesses · 3 labs · deepest: browser lab

Browser session authority cannot be exercised from an unauthorized origin, and responses carry the policies the page needs.

Applies to: Cookie-authenticated browsers

Available material

Where coverage will grow

Clickjacking now has tested fix cards (Express and Next.js) that set CSP frame-ancestors and X-Frame-Options. Add browser-engine tests that check SameSite, CORS preflight and CSP enforcement in current Chrome, Firefox and Safari.

Identifiers: CWE-352 · CWE-942 · CWE-346 · CWE-1021 · CWE-1275 · CWE-1385

APP-05Upload and archive lifecycleCovered2 guides · fix cards for 2 weaknesses · 3 labs · 1 project · deepest: local project

Untrusted files stay private, bounded and inside an authorized storage location.

Applies to: File services · archive extraction

Available material

Where coverage will grow

Add malware-scanner outage and image-decoder isolation cases; filesystem race tests remain environment-specific.

Identifiers: CWE-434 · CWE-22 · CWE-23 · CWE-59 · CWE-73 · CWE-646

APP-06Outbound requests and redirectsCovered2 guides · fix cards for 2 weaknesses · 4 labs · deepest: browser lab

Server-side fetches reach only intended destinations, and redirects send users only where the application allows.

Applies to: HTTP clients · DNS · network egress

Available material

Where coverage will grow

Add DNS-rebinding and redirect-chain tests against a controlled resolver and egress proxy.

Identifiers: CWE-918 · CWE-601

APP-07Business logic and concurrent effectsCovered3 guides · 3 labs · 1 project · deepest: local project

Retries, concurrent requests and unusual sequences preserve balances, stock, workflow order and one logical effect.

Applies to: Python and SQLite · signed HTTP callbacks

Available material

Where coverage will grow

Add durable outbox recovery for external payments; the SQLite project does not establish every database's locking behavior.

Identifiers: CWE-362 · CWE-367 · CWE-837 · CWE-841 · CWE-799

APP-08Threat modeling and design reviewCovered4 guides · deepest: guided practice

Designs are reviewed against named threats before implementation, and each finding becomes a requirement or a test.

Applies to: Application design

Available material

Where coverage will grow

Add worked models for more architectures, such as event-driven systems and mobile back ends.

APP-09Failure behavior and diagnostic exposureCovered2 guides · deepest: guided practice

Unexpected failures keep security decisions intact and reveal no sensitive internals.

Applies to: Request handlers and workers

Available material

Where coverage will grow

Add dependency-outage, partial-write and timing regression projects. Production debug and error-detail settings have a guide and a deployment probe, but no per-stack fix cards.

Identifiers: CWE-209 · CWE-636 · CWE-460

APP-10Security testing and review in the pipelineCovered5 guides · deepest: guided practice

Findings come with a cause, a reproduction, a fix and a regression test, and the pipeline runs the checks that block a release.

Applies to: Source review · dynamic testing · CI pipelines

Available material

Where coverage will grow

Add a downloadable reference pipeline that runs real scanners end to end, and continuous fuzzing with OSS-Fuzz or ClusterFuzzLite.

Mapped to: SSDF 1.1 PW.8.2 (Relevant to scoped testing and retained outcomes)

APP-11Framework controls and stack-specific fixesCovered3 guides · fix cards in 10 stacks · deepest: fix cards

Middleware, object mapping and response handling keep the framework's protections, and each fix is shown in the team's own stack.

Applies to: Express · Flask · Spring Boot · ASP.NET Core · Next.js · FastAPI · Django · Go net/http · Rails · Laravel

Available material

Where coverage will grow

Fix cards give tested code for ten stacks: Express, Flask, Spring Boot and ASP.NET Core for 21 to 24 of the 24 weaknesses, Go's net/http for 12, FastAPI, Next.js and Laravel for nine each, and Django and Rails for eight; each stack has a page with its supported versions and production defaults. The newer stacks still lack cards for some weaknesses, such as command injection, deserialization and template injection in Rails and Laravel, and Go web frameworks such as Gin and Echo, Symfony and NestJS have no cards of their own.

APP-12Mobile platform boundariesCovered5 guides · 2 projects · deepest: local project

Storage, deep links, platform permissions and server calls keep their intended authority on Android and iOS.

Applies to: Android · iOS

Available material

Where coverage will grow

The iOS project runs XCTest in the Simulator and the Android project runs Robolectric and Android Lint in a container, mapped to MASTG 2.0 tests. Add device and emulator runs for what those can't show: Data Protection classes, App Links and universal-link verification against live association files, runtime permission denial, and App Attest or Play Integrity checked on a server. Every MASVS 2.1 control has a page mapping it to the guides and MASTG tests here; enforced app updates (MASVS-CODE-2), dependency scanning in mobile build systems (MASVS-CODE-3) and implementing the resilience controls (MASVS-RESILIENCE-3 and -4) have no guide yet.

APP-13Desktop and device privilege separationCovered3 guides · 2 projects · deepest: local project

Client content cannot misuse desktop bridges or untrusted update paths.

Applies to: Desktop IPC · embedded devices

Available material

Where coverage will grow

Extend the Electron project to the packaged app (fuses, ASAR integrity, code signing) and its auto-updater, and add a project that runs the A/B recovery tests against a real bootloader such as MCUboot or U-Boot in an emulator.

APP-14Disclosure, bug bounty and penetration testingCovered6 guides · deepest: guided practice

Reported defects have a safe intake, an accountable response and a verified fix, and external testing is scoped and retested.

Applies to: Product security response

Available material

Where coverage will grow

Add complete mock disclosure packets and a CSAF advisory example.

APP-15HTTP framing agreementCovered1 guide · 1 project · deepest: local project

Every HTTP hop agrees on request boundaries before forwarding.

Applies to: HTTP proxies and origin servers

Available material

Where coverage will grow

Test the exact production proxy and origin versions and protocol translation; a small project does not cover every HTTP stack.

Identifiers: CWE-444

APP-16Cache identity and audienceCovered1 guide · 1 project · deepest: local project

Responses are cached only under a key and policy that keep their authorized audience.

Applies to: Reverse proxies · CDNs · application caches

Available material

Where coverage will grow

Add intermediary-specific cache normalization, Vary and invalidation tests.

Identifiers: CWE-524

APP-17Bounded parsing and deserializationCovered3 guides · fix cards for 2 weaknesses · 5 labs · 1 project · deepest: local project

Serialized input cannot select executable types, unsafe constructors or unbounded object graphs.

Applies to: Java · .NET · Python · Node.js

Available material

Where coverage will grow

Deserialization fix cards cover Node.js, Python, Java and C#, and XXE fix cards cover Python, Java and C#. Library-specific gadget-chain analysis and Go, Ruby and PHP serializers are not covered.

Identifiers: CWE-502 · CWE-611 · CWE-776 · CWE-409

APP-18Prototype pollutionCovered1 guide · 1 project · deepest: local project

Untrusted object keys cannot change inherited behavior or privileged configuration.

Applies to: JavaScript object processing

Available material

Where coverage will grow

Extend the object-processing project to the exact framework, merge library and configuration sinks used in production.

Identifiers: CWE-1321

APP-19Native memory and integer safetyCovered5 guides · 1 lab · 1 project · deepest: local project

Bounds, lengths and lifetimes cannot produce out-of-bounds access, stale pointers or integer overflow.

Applies to: C and C++ · Rust · native extensions

Available material

Where coverage will grow

Extend the C parser project to sustained fuzzing campaigns and real FFI contracts; Go and Swift unsafe code have no material.

Identifiers: CWE-787 · CWE-125 · CWE-416 · CWE-120 · CWE-121 · CWE-122 · CWE-476 · CWE-190

APP-20Spreadsheet and document exportsCovered2 guides · fix cards for 1 weakness · 1 project · deepest: local project

CSV, spreadsheet and document processors treat untrusted cells and content as data.

Applies to: CSV and spreadsheets · document conversion

Available material

Where coverage will grow

CSV and XLSX exports have a guide with code, and converting untrusted office documents and PDFs has a guide and a project whose live tests run LibreOffice and Ghostscript in a locked-down container (zip bomb, XXE, no network, deadline). CSV formula injection has tested fix cards in six stacks (Express, Flask, Spring Boot, ASP.NET Core, Django and Rails). Not yet covered: a tested pixel re-rendering pipeline (Dangerzone's design is described, not built), and a tested Kubernetes Job or gVisor variant of the sandbox.

Identifiers: CWE-1236

APP-21Input validation and regular expressionsCovered3 guides · fix cards for 1 weakness · deepest: fix cards

Input is validated against an explicit schema, and no pattern can be driven into catastrophic backtracking.

Applies to: JavaScript · Python · C# · Java

Available material

Where coverage will grow

The fix cards cover regular-expression denial of service; schema validation and Unicode normalization are taught in the guide without per-stack cards.

Identifiers: CWE-1333 · CWE-20 · CWE-1284 · CWE-1287 · CWE-235

APP-22Header and log injectionCovered1 guide · fix cards for 1 weakness · deepest: fix cards

Untrusted values cannot add HTTP headers, split responses or forge log records.

Applies to: HTTP servers · application logs

Available material

Where coverage will grow

The guide has code for nginx, Node.js and Python, and fix cards give tested fixes for Express, Flask and Spring Boot. ASP.NET Core and the newer stacks have no CRLF fix card, and there is no browser lab.

Identifiers: CWE-93 · CWE-113 · CWE-117

AI-08Smart-contract state invariantsCovered1 guide · deepest: guided practice

Adversarial calls and callbacks preserve explicitly stated economic and state invariants.

Applies to: Smart contracts

Available material

Where coverage will grow

Add a local-chain project with compiler-pinned invariant tests and separate economic assumptions.

Software supply chain11

SUP-01Release inventory completenessCovered2 guides · 1 lab · 1 project · deepest: local project

The inventory describes the packaged artifact, including bundled and generated components.

Applies to: SPDX and CycloneDX · packaged artifacts

Available material

Where coverage will grow

Add more real ecosystems and container-layer inventory comparison; no file-only checker proves completeness.

SUP-02Inventory changes and advisory applicabilityCovered3 guides · 1 lab · 1 project · deepest: local project

Dependency changes and vulnerability decisions bind to the exact release and configuration.

Applies to: Release inventories · VEX

Available material

Where coverage will grow

Add reproducible producer and consumer VEX exchanges across independently generated SBOMs.

SUP-03CI/CD trust boundaries and platform hardeningCovered8 guides · 1 lab · 2 projects · deepest: local project

Untrusted change content cannot acquire release credentials or poison trusted outputs.

Applies to: CI workflows and runners

Available material

Where coverage will grow

GitHub Actions has a hardening guide, a lab and a project, and the security pipeline project also runs on GitLab CI. Jenkins has no hardening guide yet. Against the OWASP Top 10 CI/CD Security Risks, identity inventories across CI/CD systems (CICD-SEC-2), self-managed CI servers and artifact repositories (CICD-SEC-7), reviews of connected third-party apps (CICD-SEC-8) and central pipeline audit logging (CICD-SEC-10) have no guide yet.

SUP-04Artifact identity and provenanceCovered3 guides · 1 lab · 1 project · deepest: local project

Consumers verify bytes, signer policy and build claims for the same intended artifact.

Applies to: Artifact signing and provenance

Available material

Where coverage will grow

Add transparency-log and keyless identity verification exercises beyond local signing policies.

SUP-05Deterministic and isolated buildsCovered2 guides · 1 project · deepest: local project

Unexpected output differences are explained against recorded source, inputs and environment.

Applies to: Build systems

Available material

Where coverage will grow

A full hermetic build environment and an independent rebuild service are not supplied.

SUP-06Dependency intake, confusion and malicious packagesCovered11 guides · 1 lab · deepest: browser lab

Package choice, source mapping, installation and incident containment rest on evidence about real authority and use.

Applies to: Package managers and build agents

Available material

Where coverage will grow

Add a sandbox for install hooks and a complete dependency replacement case.

Identifiers: CWE-427 · CWE-1104 · CWE-1395 · CWE-506

SUP-07Publication and update trustCovered5 guides · 1 project · deepest: local project

Only approved source and identity can publish artifacts that clients accept as updates.

Applies to: Package registries · client updates

Available material

Where coverage will grow

The staged rollout guide covers rollout rings, automatic halts, content validation and rollback with runnable checks; production-registry and client rollback exercises with disposable infrastructure are still missing.

SUP-08Supply-chain incident case studiesCovered5 guides · deepest: guided practice

Teams can trace a real supply-chain compromise from entry point to the controls that would have stopped it.

Applies to: Open-source ecosystems · CI/CD

Available material

Where coverage will grow

Each case study is current to its own date; later findings about these incidents are not tracked automatically.

SUP-09Source-control hardening and the SLSA Source TrackCovered2 guides · deepest: guided practice

Branch protection, required review and source provenance stop unreviewed changes reaching a release.

Applies to: Git hosting

Available material

Where coverage will grow

Rulesets, CODEOWNERS review, signed commits and push protection have commands and a verification check for GitHub and GitLab, mapped to the SLSA Source track. Generating and verifying source provenance attestations is not exercised yet.

Authoritative source: SLSA 1.2: Source track requirements

SUP-10Open-source baselines for producers and consumersCovered4 guides · deepest: guided practice

Maintainers and consumers apply a published baseline (OpenSSF OSPS Baseline, S2C2F) and keep evidence of it.

Applies to: Open-source projects

Available material

Where coverage will grow

OSPS Baseline v2026.08.28 has a maintainer walkthrough: its families and levels, every Level 1 requirement on GitHub with evidence, the key Level 2 and 3 controls, a tested evidence script and a validated Security Insights file. S2C2F has a consumer walkthrough: its 8 practices, 25 requirements and 4 levels, a tested level calculator and a staged plan. GitLab equivalents for the Baseline controls and a hands-on lab are not covered.

Authoritative source: OpenSSF Open Source Project Security Baseline

SUP-11License complianceCovered2 guides · deepest: guided practice

Each release meets the license obligations of what it ships, with notices and SBOM license data to prove it.

Applies to: Releases · SBOMs

Available material

Where coverage will grow

SPDX license expressions, a policy by distribution model, SBOM-based checks in pull requests and release notices are covered. Legal interpretation of individual licenses is out of scope (see OUT-01).

Authoritative source: SPDX License List

Runtime, cloud & APIs12

RUN-01Effective cloud trust and permissionsCovered6 guides · 1 lab · deepest: browser lab

Workload identities can assume only intended roles and reach only required resources.

Applies to: Cloud IAM · service-to-service identity

Available material

Where coverage will grow

A browser lab now models role trust-policy evaluation against the confused deputy (sts:ExternalId, aws:SourceArn and aws:SourceAccount). The remaining gap is disposable cloud-account labs that evaluate identity, resource and organization policies together.

RUN-02Workload privilege enforcementCovered4 guides · 2 labs · 1 project · deepest: local project

The deployed workload cannot request or inherit unnecessary host or kernel authority.

Applies to: Kubernetes · containers

Available material

Where coverage will grow

Cluster admission outcomes must be checked on the installed version; the browser lab checks policy logic only.

RUN-03Network and admission enforcementCovered2 guides · 2 labs · 1 project · deepest: local project

Allowed flows succeed and prohibited flows fail on the real cluster and policy stack.

Applies to: Kubernetes admission · NetworkPolicy

Available material

Where coverage will grow

CNI-specific probes, exception paths and upgrade regressions remain environment-dependent.

RUN-04Infrastructure intent and observed stateCovered4 guides · deepest: guided practice

Security-relevant deployment drift is detected, owned and resolved against desired policy.

Applies to: Infrastructure as code · DNS

Available material

Where coverage will grow

Add Terraform plan and state integration with cloud observation on disposable resources. Dangling DNS detection is shown with an offline-tested scanner and validated Terraform, not against live zones.

RUN-05API exposure and protocol authorizationCovered3 guides · 1 project · deepest: local project

Every exposed operation is inventoried, authenticated and authorized whatever the listener or protocol.

Applies to: HTTP, GraphQL, WebSocket and gRPC · WebRTC signaling, TURN and media servers

Available material

Where coverage will grow

Add real GraphQL, WebSocket and gRPC servers with operation-level controls and cancellation tests. WebRTC media-server robustness (ASVS V17.2) is described but not load- or fuzz-tested here.

RUN-06Bounded work and recoveryCovered4 guides · fix cards for 1 weakness · 2 projects · deepest: local project

Cost, concurrency, time and durable retries stay within explicit budgets.

Applies to: APIs · background jobs

Available material

Where coverage will grow

Unbounded resource consumption now has tested fix cards (Express and ASP.NET Core) with body-size, work and rate limits. Add queue and outbox recovery and distributed rate limiting across several processes.

Identifiers: CWE-770 · CWE-400

RUN-07Investigable security eventsCovered4 guides · deepest: guided practice

Identity, decision and effect evidence can be correlated without disclosing unnecessary secrets.

Applies to: Application and runtime telemetry

Available material

Where coverage will grow

Add an application-to-log-store detection and containment exercise that includes delivery failures.

Identifiers: CWE-778 · CWE-532

RUN-08Edge controls and origin correctnessCovered1 guide · 1 project · deepest: local project

Edge rules reduce abuse without replacing origin authorization or blocking legitimate use.

Applies to: WAF · bot controls · origin services

Available material

Where coverage will grow

Add provider-specific WAF rule tuning and false-positive measurements on representative traffic.

RUN-09Cloud provider baselinesCovered3 guides · deepest: guided practice

Each cloud account starts from a hardened baseline for identity, logging, metadata access and storage on AWS, Azure and Google Cloud.

Applies to: AWS · Azure · Google Cloud

Available material

Where coverage will grow

Add provider detection services and CIS Benchmark checks for each provider.

RUN-10Container image securityCovered3 guides · deepest: guided practice

Images are minimal, scanned, signed and rebuilt on a schedule, and the cluster admits only verified images.

Applies to: Containers · Kubernetes admission

Available material

Where coverage will grow

Add base-image update automation and rebuild cadence examples.

RUN-11Security tool categoriesCovered2 guides · deepest: guided practice

Teams know what each tool category checks (CSPM, CNAPP, CIEM, ASPM, IAST, RASP) and how to evaluate one without vendor claims.

Applies to: Tool evaluation

Available material

Where coverage will grow

Application testing categories (SAST, DAST, IAST, SCA, secrets, IaC, container and API scanning, ASPM) and cloud categories (CSPM, CWPP, CIEM, DSPM, CNAPP) each have an explainer and an evaluation protocol on a seeded target. RASP is only mentioned, in the edge and PCI DSS guides, without an evaluation.

RUN-12Hardening benchmarksCovered3 guides · 1 project · deepest: local project

The images and nodes the team builds and runs (container base images, golden VM images, Kubernetes node images and the container runtime), and the clusters and managed services they use, are configured against a published benchmark, with deviations recorded, approved and expiring.

Applies to: Container images · VM and node images · Kubernetes · cloud services

Available material

Where coverage will grow

Container images are scanned with OpenSCAP and the SCAP Security Guide in a tested project with a deviation register enforced in CI; managed Kubernetes is checked with kube-bench and the cloud baselines name the CIS Foundations Benchmarks. Golden VM images and running nodes are covered in prose with the tools to use, not in a tested exercise; the worked example uses a CIS profile, not a DISA STIG, and Windows images are not covered. Of the OWASP Kubernetes Top 10 2025 risks, K06 Overly Exposed Kubernetes Components is covered only for the managed API endpoint: exposed kubelets and etcd, and control planes you run yourself, have no guide.

Authoritative source: CIS Benchmarks

Identity & cryptography10

ID-01Authentication, passwords and session stateCovered4 guides · fix cards for 2 weaknesses · 1 lab · 3 projects · deepest: local project

Login, password storage, renewal, logout and revocation keep a coherent authenticated session.

Applies to: Sessions · password verifiers

Available material

Where coverage will grow

Missing authentication for a critical function (CWE-306) now has tested fix cards (Express, Next.js, Spring Boot and ASP.NET Core). Add session-store failover and sign-out-everywhere integration tests across stacks.

Identifiers: CWE-384 · CWE-613 · CWE-614 · CWE-1004 · CWE-916 · CWE-759 · CWE-521 · CWE-257

ID-02Federated login and token lifecycleCovered6 guides · fix cards for 1 weakness · 3 labs · 1 project · deepest: local project

Callback binding, exact token validation and key rollover keep issuer and audience trust.

Applies to: OAuth, OIDC and JWT

Available material

Where coverage will grow

Add configurations for several real identity providers and a refresh-token compromise exercise.

Identifiers: CWE-347 · CWE-287

ID-03Enterprise SSO assertion validationCovered1 guide · 1 project · deepest: local project

Assertions are accepted only for the intended issuer, recipient, request and replay state.

Applies to: SAML enterprise SSO

Available material

Where coverage will grow

Provider-specific XML signature libraries and metadata rollover still need integration testing.

ID-04Provisioning and deprovisioningCovered1 guide · 1 project · deepest: local project

Identity changes promptly remove effective access across sessions, groups and queued work.

Applies to: SCIM · directory lifecycle

Available material

Where coverage will grow

Add a complete SCIM connector with retry and reconciliation, and provider contract tests.

ID-05MFA, passkeys and account recoveryCovered3 guides · 1 lab · deepest: browser lab

Second factors, passkey enrollment and replacement, and account recovery cannot bypass the intended identity proof.

Applies to: Passkeys · MFA · account recovery

Available material

Where coverage will grow

Add real WebAuthn browser and authenticator tests, and recovery support-tool controls.

Identifiers: CWE-308 · CWE-640

ID-12Account takeover and credential attacksCovered3 guides · deepest: guided practice

Credential stuffing, enumeration and brute force are detected and slowed without locking out legitimate users.

Applies to: Login endpoints · edge controls

Available material

Where coverage will grow

Add measured rate-limit and bot-detection tuning on representative login traffic.

Identifiers: CWE-307 · CWE-204

ID-06Secrets and workload identity lifecycleCovered9 guides · fix cards for 1 weakness · 1 lab · deepest: browser lab

Credential issuance, use, rotation, leak detection and revocation keep least privilege and allow recovery.

Applies to: Application secrets · workload identities

Available material

Where coverage will grow

Add vault and KMS integration with expiry, outage and revocation tests.

Identifiers: CWE-798 · CWE-260 · CWE-522 · CWE-312

ID-07Authenticated encryption and algorithm choiceCovered3 guides · fix cards for 1 weakness · 2 labs · 1 project · deepest: local project

Encryption binds each record to its context with unique nonces, and every algorithm and parameter is chosen for its job.

Applies to: Web Crypto AES-GCM · encrypted records

Available material

Where coverage will grow

Add durable distributed nonce and key allocation and recovery from storage corruption.

Identifiers: CWE-327 · CWE-326 · CWE-328 · CWE-330 · CWE-338 · CWE-323 · CWE-1240

ID-08Key rotation, TLS and post-quantum migrationCovered6 guides · fix cards for 1 weakness · 1 project · deepest: local project

Keys and certificates can be rotated, restored and retired, TLS is configured from a tested baseline, and the cryptographic inventory supports migration.

Applies to: KMS · TLS and PKI · crypto inventory

Available material

Where coverage will grow

Add KMS and PKI renewal and restore exercises, and protocol-specific post-quantum migration tests.

Identifiers: CWE-295 · CWE-297 · CWE-319

ID-11Data minimization and privacy transformationsCovered2 guides · deepest: guided practice

Collection, linkage, retention and deletion decisions keep documented purposes and boundaries.

Applies to: Application data lifecycle

Available material

Where coverage will grow

Add a deletion and backup lifecycle project and measured re-identification examples.

Identifiers: CWE-359

Governance & frameworks15

GOV-01Accountable product security practiceCovered8 guides · deepest: guided practice

Owners and risk-based practices produce repeatable engineering decisions across the lifecycle.

Applies to: Product development lifecycle

Available material

Where coverage will grow

The operating plan and assurance packet need organization-specific ownership and observed adoption.

GOV-02Requirement-bound verificationCovered3 guides · 1 lab · 1 project · deepest: local project

A claim joins a scoped requirement, its implementation, a repeatable test and evidence from the exact candidate.

Applies to: Application assurance

Available material

Where coverage will grow

Coverage is selective; full ASVS level assessments and cross-framework equivalence are not asserted.

Mapped to: SSDF 1.1 PO.4.1 (Relevant to defining security check criteria) · SSDF 1.1 PW.8.2 (Relevant to scoped testing and retained outcomes)

GOV-03Maturity models and framework selectionCovered8 guides · deepest: guided practice

Teams choose the framework that answers their question and assess evidence with stated confidence.

Applies to: Security program assessment

Available material

Where coverage will grow

BSIMM, SAMM and SSDF have a comparison guide with a worked crosswalk, and SAMM an assessment guide; Microsoft SDL has no explainer or comparison yet.

GOV-04Exceptions, metrics and remediation SLAsCovered4 guides · 1 lab · deepest: browser lab

Unmet controls keep risk ownership and expiry, and the program measures outcomes rather than activity.

Applies to: Release decisions · risk registers

Available material

Where coverage will grow

Templates need real acceptance authority, dates, compensating-control tests and reporting data.

GOV-05Supplier assuranceCovered2 guides · 1 project · deepest: local project

Supplier evidence applies to the actual product, artifact, use and contractual boundary.

Applies to: Procurement · third-party software

Available material

Where coverage will grow

Add supplier evidence challenge-and-response cases and contract-specific follow-up examples.

GOV-06Privacy and regulated data scopeCovered5 guides · deepest: guided practice

Engineering evidence follows documented product, market, data and organizational applicability.

Applies to: Personal and health data

Available material

Where coverage will grow

The guides scope GDPR, CCPA and HIPAA for engineering; jurisdiction-specific legal conclusions are out of scope (see OUT-01).

GOV-07EU Cyber Resilience ActCovered2 guides · deepest: guided practice

Products with digital elements meet CRA vulnerability handling and reporting duties with evidence ready for the deadlines.

Applies to: Products sold in the EU

Available material

Where coverage will grow

Reporting (from 11 September 2026) has a runbook; Annex I conformity evidence and support-period decisions have no dedicated guide yet.

Authoritative source: Regulation (EU) 2024/2847 (Cyber Resilience Act)

GOV-08PCI DSS secure development and payment pagesCovered2 guides · deepest: guided practice

Requirement 6 and 11.6.1 evidence comes from real engineering records for each release.

Applies to: Cardholder data environments

Available material

Where coverage will grow

Requirement 6.2.2 role-based training has no dedicated guide yet.

GOV-09ISO/IEC 27001 and SOC 2 engineering evidenceCovered4 guides · deepest: guided practice

Engineering supplies evidence for ISO/IEC 27001:2022 Annex A secure-development controls and SOC 2 change and operations criteria.

Applies to: Certified organizations

Available material

Where coverage will grow

Annex A 8.25 to 8.33 and SOC 2 CC6 to CC8 each have a control-to-evidence guide with a check script, and one evidence set serves both. The SOC 2 criteria outside access, operations and change management (availability, confidentiality, processing integrity and privacy) are not covered.

Authoritative source: ISO/IEC 27001:2022

GOV-10NIS2 and DORA obligations for software teamsCovered1 guide · deepest: guided practice

Teams in scope of NIS2 or DORA know which duties reach software development and suppliers.

Applies to: Organizations in the EU

Available material

Where coverage will grow

The guide covers who is in scope, Implementing Regulation 2024/2690, DORA contract terms and the register of information, with one assurance pack for both. National NIS2 transpositions are not tracked country by country.

Authoritative source: Directive (EU) 2022/2555 (NIS2)

GOV-11Vulnerability prioritizationCovered3 guides · deepest: guided practice

Remediation order and due dates follow exploitation, exposure and impact evidence, not a single score.

Applies to: Vulnerability management

Available material

Where coverage will grow

Scores change over time; recompute priorities on a schedule as EPSS and KEV data update.

GOV-12Security champions and developer trainingCovered3 guides · deepest: guided practice

Champions have protected time and measured outcomes, and developers get training matched to their role.

Applies to: Engineering organizations

Available material

Where coverage will grow

Champions and role-based training each have a guide, with the training evidence PCI DSS 6.2.2 and SSDF PO.2.2 ask for; the team plans on /learn/teams/ supply sessions and exercises. There is no material for running live hands-on events such as capture-the-flag days.

GOV-13Secure by Design commitmentsCovered2 guides · deepest: guided practice

Products ship secure by default, and the maker can show progress on the CISA Secure by Design goals.

Applies to: Software manufacturers

Available material

Where coverage will grow

The three principles and the seven pledge goals have engineering actions and evidence checks, and the UK code of practice maps its 14 principles. Secure-by-design guidance from other national agencies is not compared.

Authoritative source: CISA Secure by Design

GOV-14Software attestation for public-sector buyersCovered2 guides · deepest: guided practice

Producers can state which SSDF practices an attestation covers and back each claim with release evidence.

Applies to: US federal suppliers

Available material

Where coverage will grow

The attestation guide walks through each part of the CISA form, the SSDF 1.1 tasks its appendix maps to each statement, the release evidence to keep with a tested check, the POA&M and third-party assessor options, and the status after OMB M-26-05 and the withdrawn FAR case. Agency-specific terms are covered only where public sources show them, such as GSA's copy of the form; other agencies' contract clauses are not tracked.

GOV-15Careers and certificationsCovered1 guide · deepest: guided practice

Readers can see what each security role does and what each certification demonstrates.

Applies to: Practitioners

Available material

Where coverage will grow

Application and product security roles have tracks, a skills matrix, portfolio advice and what each certification shows. Adjacent careers such as security operations, governance and risk, and penetration testing are only touched on.

Authoritative source: NICE Workforce Framework for Cybersecurity

AI security10

AI-01Untrusted instruction containmentCovered5 guides · 1 lab · 1 project · deepest: local project

Retrieved text and tool messages cannot grant authority or redirect privileged application behavior.

Applies to: LLM apps · MCP · multi-agent systems

Available material

Where coverage will grow

Add interoperable MCP transports and delegated-token integration across several services.

Identifiers: LLM01:2026 · ASI01:2026

AI-02Retrieval and memory isolationCovered5 guides · 1 lab · 1 project · deepest: local project

Documents and memory cross no unauthorized tenant or user boundary before reranking, generation or caching.

Applies to: RAG · tenant memory

Available material

Where coverage will grow

Add real vector-store ACL enforcement, deleted-document propagation and cache invalidation tests, and a runnable project that poisons agent memory across sessions and exercises the write gate, quarantine and rollback.

Identifiers: LLM02:2026 · LLM09:2026 · ASI06:2026

AI-03Tool authority and side effectsCovered8 guides · 1 lab · 1 project · deepest: local project

Current access, exact approval, budget and durable execution jointly authorize each agent action.

Applies to: Agent tools · concurrent workers

Available material

Where coverage will grow

Add external API side effects with outbox reconciliation and distributed approval consumption.

Identifiers: LLM03:2026 · LLM06:2026 · ASI02:2026 · ASI03:2026 · ASI09:2026

AI-04Generated output handlingCovered2 guides · 1 lab · 1 project · deepest: local project

Generated content stays untrusted at every rendering, parsing and command boundary.

Applies to: Model output consumers

Available material

Where coverage will grow

Add browser DOM and downstream parser tests beyond the current encoder checks. Run the code-sandbox project under gVisor or a microVM, and add a computer-use exercise with injected on-screen instructions; both are described but not yet tested here.

Identifiers: LLM10:2026 · ASI05:2026

AI-05AI security evaluation and red teamingPartial5 guides · 1 project · deepest: local project

Evaluations observe actual disclosure, effects and resource use across adversarial test sets.

Applies to: AI application evaluation

Available material

What is missing

Publish regression results from real models and providers. The versioned corpus, harness and regression gate exist, but the only recorded A-versus-B comparison comes from a deterministic simulator. Running the corpus against at least two real model versions or providers needs API access (or a local server with tool calling, such as vLLM or Ollama), permission to test them and about 300 trials per model; then commit both results files and the regression report.

Identifiers: LLM07:2026 · LLM08:2026

AI-06Model and data integrityCovered5 guides · deepest: guided practice

Model artifacts and training or retrieval data keep trustworthy provenance and targeted-failure evaluation.

Applies to: Model supply chains · training data

Available material

Where coverage will grow

Add isolated model-deserialization and dataset-poisoning projects with measured targeted outcomes.

Identifiers: LLM04:2026 · LLM05:2026 · ASI04:2026

AI-07Privacy attack measurementCovered2 guides · deepest: guided practice

Privacy claims account for the attacker's knowledge, base rates and measured error rates.

Applies to: Model privacy evaluations

Available material

Where coverage will grow

Add a reproducible small-model membership-inference evaluation with documented consent and data provenance.

Identifiers: LLM02:2026

AI-09AI-assisted developmentCovered3 guides · deepest: guided practice

Code from assistants and coding agents passes the same review, dependency and secret controls as human code, and agents run with bounded authority.

Applies to: Coding assistants and agents

Available material

Where coverage will grow

Add measured comparisons of assistant-generated code against the fix cards' regression tests.

AI-10Agent failure containmentCovered1 guide · deepest: guided practice

A compromised or failing agent cannot cascade through other agents or keep acting outside its mandate.

Applies to: Multi-agent systems

Available material

Where coverage will grow

Add a runnable multi-agent project that trips the kill switch, circuit breaker and run limits under injected faults, and a lab on compensating rollback from an operation log.

Authoritative source: OWASP Top 10 for Agentic Applications 2026

Identifiers: ASI08:2026 · ASI10:2026

AI-11AI governance and regulationCovered2 guides · deepest: guided practice

Teams map AI features to the NIST AI RMF and Generative AI Profile, ISO/IEC 42001 and the EU AI Act timeline.

Applies to: AI features

Available material

Where coverage will grow

Add a worked Annex IV technical documentation and conformity-assessment example. Revisit when the high-risk classification guidelines are final, harmonised standards are cited in the Official Journal and NIST publishes its AI RMF revision.

Authoritative source: NIST AI 600-1: Generative AI Profile

Historical failures (reference)2

Case studies and failure mechanisms of retired cryptography. They explain past incidents and are counted apart from current practice.

ID-09Cryptographic failure mechanismsCovered6 guides · deepest: guided practice

Engineers can tell deterministic leakage, oracles, weak keys, collisions and downgrade conditions apart.

Applies to: Historical constructions

Available material

Where coverage will grow

These references explain why constructions failed; current choices are in the cryptography quick reference.

ID-10Historical incident lessonsCovered10 guides · deepest: guided practice

Incident prerequisites are connected to present inventory and retirement decisions.

Applies to: Legacy protocol and key incidents

Available material

Where coverage will grow

Add migration case studies that show discovery, replacement and verified removal in a modern system.

Out of scope5

Subjects this site deliberately does not cover, with the reason.

OUT-01Legal advice and compliance conclusionsOut of scopeNot covered by design

Readers know where engineering guidance ends and legal advice begins.

Applies to: All

Why it is out of scope

The guides explain engineering duties and evidence, not whether a law applies to a particular organization. Ask counsel for jurisdiction-specific conclusions.

OUT-02Product reviews and vendor rankingsOut of scopeNot covered by design

Readers can evaluate tools against their own requirements.

Applies to: All

Why it is out of scope

The site is vendor-neutral and does not rank or review commercial products; guides give selection criteria and test methods instead.

OUT-03Exploit development and offensive toolingOut of scopeNot covered by design

Exploits shown here demonstrate a weakness well enough to prove the fix.

Applies to: All

Why it is out of scope

Weaponized exploits, exploit chains against real products and offensive tooling. Labs and fix cards include only the minimal exploit a regression test needs.

OUT-04Enterprise IT and network security operationsOut of scopeNot covered by design

Software teams know which controls their own code and pipelines must provide.

Applies to: All

Why it is out of scope

Endpoint protection, email security, corporate network perimeter and SOC staffing. The runtime guides cover the workloads that teams build and run.

OUT-05Hardware and physical securityOut of scopeNot covered by design

Firmware and update paths that software teams own are covered; silicon and physical access are not.

Applies to: All

Why it is out of scope

Chip design, hardware side channels and physical access controls. Firmware updates and secure boot are covered under APP-13.

Baseline standards

Mapped identifiers refer to these versions; the standards page lists their status and dates. Outcomes without material stay listed as planned.

Find your next answer

Type to search. Search runs in your browser.

Searches run in your browser, but the host can infer them from the index files they load. The address shows your search so you can bookmark or share it.