# Secure SDLC checklist

From https://softwaresecurity.com/. Each practice says what to do and how to tell it is done, links its page (what it is and the first steps) and the guides and tools that show how, and names the NIST SSDF 1.1 practices it carries out. Text CC BY 4.0. To score your team against it, use https://softwaresecurity.com/gap-check/.

## 1. Planning

_What does this change handle, and what must it never allow?_

- [ ] **[Security requirements](https://softwaresecurity.com/planning/security-requirements/).** Turn the feature's risks into testable requirements, such as who may do what, to which data and how often, and add them to the acceptance criteria.
  - Done when: Each requirement names the test or review that proves it, and the Definition of Done says which changes need a security review.
  - [Tool: ASVS 5.0 checklist export](https://softwaresecurity.com/tools/asvs-checklist/)
  - [Workflow: Secure a feature](https://softwaresecurity.com/workflows/secure-a-feature/)
  - [Write testable security requirements and a security Definition of Done](https://softwaresecurity.com/domains/appsec/threat-modeling/security-requirements-definition-of-done/)
  - [Abuse case library: tests and controls by feature](https://softwaresecurity.com/domains/appsec/threat-modeling/abuse-case-library/)
  - NIST SSDF: PO.1, PW.1
- [ ] **[Abuse cases](https://softwaresecurity.com/planning/abuse-cases/).** For each story, describe how it could be misused: replayed, enumerated, raced, scripted or used against another user's data.
  - Done when: Abuse cases sit in the backlog with the control and the test that answer each one, or a recorded risk acceptance.
  - [Workflow: Secure a feature](https://softwaresecurity.com/workflows/secure-a-feature/)
  - [Browser labs](https://softwaresecurity.com/labs/)
  - [Abuse case library: tests and controls by feature](https://softwaresecurity.com/domains/appsec/threat-modeling/abuse-case-library/)
  - [Prevent business-logic flaws with server-side invariants](https://softwaresecurity.com/domains/appsec/business-logic/business-logic-flaws/)
  - [Write testable security requirements and a security Definition of Done](https://softwaresecurity.com/domains/appsec/threat-modeling/security-requirements-definition-of-done/)
  - NIST SSDF: PO.1, PW.1
- [ ] **[Data classification](https://softwaresecurity.com/planning/data-classification/).** Record which personal, payment, health or secret data the change touches, how long it is kept, and which laws or contracts apply, before choosing controls.
  - Done when: The ticket names the data classes, their retention and the obligations in scope.
  - [Workflow: Secure a feature](https://softwaresecurity.com/workflows/secure-a-feature/)
  - [GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls](https://softwaresecurity.com/frameworks/privacy-and-health-data-scope/)
  - [GDPR privacy by design for engineers: Articles 25, 32 and 35 in code](https://softwaresecurity.com/frameworks/gdpr-privacy-by-design-engineering/)
  - [Data minimization and retention: collect less and prove that deletion works](https://softwaresecurity.com/domains/identity-crypto/privacy/data-minimization-retention/)
  - [Tokenization, pseudonymization and privacy transformations: choose deliberately](https://softwaresecurity.com/domains/identity-crypto/privacy/tokenization-privacy-engineering/)
  - NIST SSDF: PO.1, PW.1

## 2. Design

_Where are the trust boundaries, and what can go wrong at each?_

- [ ] **[Threat modeling](https://softwaresecurity.com/design/threat-modeling/).** Draw the data flow, mark the trust boundaries and list what can go wrong at each, with a method that fits the team, such as STRIDE or attack trees.
  - Done when: Each threat has an owner and a decision: mitigate with a named control and test, accept with an expiry date, or change the design.
  - [Workflow: Review a design](https://softwaresecurity.com/workflows/review-a-design/)
  - [Choose a threat modeling method and turn its findings into tests](https://softwaresecurity.com/domains/appsec/threat-modeling/threat-modeling-methods/)
  - [Threat pattern library for threat modeling](https://softwaresecurity.com/domains/appsec/threat-modeling/threat-pattern-library/)
  - [Review tenant boundaries before implementation](https://softwaresecurity.com/domains/appsec/threat-modeling/multitenant-design-review/)
  - [Worked threat model: an LLM agent with tools](https://softwaresecurity.com/domains/appsec/threat-modeling/llm-agent-threat-model/)
  - NIST SSDF: PW.1
- [ ] **[Secure design patterns](https://softwaresecurity.com/design/secure-design-patterns/).** Use proven patterns and components for authentication, authorization, tenancy, secrets and input handling instead of designing them again for each feature.
  - Done when: The design names the pattern used at each boundary, and any departure is a recorded decision.
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Secure design patterns: a catalogue for insecure-design (A06)](https://softwaresecurity.com/domains/appsec/threat-modeling/secure-design-patterns/)
  - [Authorization models: RBAC, ABAC, ReBAC and policy as code you can test](https://softwaresecurity.com/domains/identity-crypto/identity/authorization-models/)
  - [Review tenant boundaries before implementation](https://softwaresecurity.com/domains/appsec/threat-modeling/multitenant-design-review/)
  - [Preserve framework security controls across the request lifecycle](https://softwaresecurity.com/domains/appsec/secure-coding/framework-security-patterns/)
  - NIST SSDF: PW.1, PW.4
- [ ] **[Security design review](https://softwaresecurity.com/design/security-design-review/).** Have someone who did not design the change check it against the requirements and the threat model, especially authorization, data exposure and failure handling.
  - Done when: Review findings are tracked like bugs and resolved before the affected part is built.
  - [Workflow: Review a design](https://softwaresecurity.com/workflows/review-a-design/)
  - [Review tenant boundaries before implementation](https://softwaresecurity.com/domains/appsec/threat-modeling/multitenant-design-review/)
  - [Choose a threat modeling method and turn its findings into tests](https://softwaresecurity.com/domains/appsec/threat-modeling/threat-modeling-methods/)
  - [Secure design patterns: a catalogue for insecure-design (A06)](https://softwaresecurity.com/domains/appsec/threat-modeling/secure-design-patterns/)
  - [Authorization models: RBAC, ABAC, ReBAC and policy as code you can test](https://softwaresecurity.com/domains/identity-crypto/identity/authorization-models/)
  - NIST SSDF: PW.2

## 3. Development

_Does the code keep untrusted input, secrets and privileges where they belong, and can the pipeline that builds it be trusted?_

- [ ] **[Secure coding](https://softwaresecurity.com/development/secure-coding/).** Use the safe API for each sink: bound parameters for SQL, argument arrays for commands, context-aware encoding for HTML, and allowlists for redirects and outbound requests.
  - Done when: Each weakness class the change touches has a test that fails on the vulnerable pattern.
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Browser labs](https://softwaresecurity.com/labs/)
  - [Workflow: fix a finding](https://softwaresecurity.com/workflows/fix-a-finding/)
  - [Tool: ReDoS checker](https://softwaresecurity.com/tools/redos-checker/)
  - [Keep untrusted values out of executable syntax](https://softwaresecurity.com/domains/appsec/secure-coding/injection-parser-boundaries/)
  - [Prevent XSS at the output boundary](https://softwaresecurity.com/domains/appsec/secure-coding/xss-output-encoding/)
  - [Fix SQL injection in Python sqlite3](https://softwaresecurity.com/domains/appsec/secure-coding/sql-injection-python-sqlite3/)
  - [Run external programs without command or argument injection](https://softwaresecurity.com/domains/appsec/secure-coding/os-command-injection/)
  - [Preserve framework security controls across the request lifecycle](https://softwaresecurity.com/domains/appsec/secure-coding/framework-security-patterns/)
  - [Constrain server-side fetches to their intended destinations](https://softwaresecurity.com/domains/appsec/secure-features/ssrf-egress-boundaries/)
  - [Redirect users only to destinations you control](https://softwaresecurity.com/domains/appsec/secure-features/open-redirect/)
  - NIST SSDF: PW.5
- [ ] **[Secrets out of code](https://softwaresecurity.com/development/secrets-out-of-code/).** Load credentials at runtime from a secrets manager or the platform, and scan every commit for secrets.
  - Done when: No secret is in the repository or its history, and a leaked one can be rotated without changing code.
  - [Practice: Runtime secrets](https://softwaresecurity.com/release/runtime-secrets/)
  - [Practice: CI security checks](https://softwaresecurity.com/development/ci-security-checks/)
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Secrets management: storage, rotation and leaked-secret response](https://softwaresecurity.com/domains/identity-crypto/secrets/secrets-lifecycle/)
  - [Contain a leaked secret, then investigate and clean up](https://softwaresecurity.com/domains/identity-crypto/secrets/leaked-secret-response/)
  - [Workload identity federation: short-lived, scoped identities for services and CI](https://softwaresecurity.com/domains/identity-crypto/identity/workload-identity-models/)
  - NIST SSDF: PW.5
- [ ] **[Dependency selection](https://softwaresecurity.com/development/dependency-selection/).** Check a new package’s maintenance, provenance and install scripts before adding it, pin it with a lockfile, and install only from the registry you intend.
  - Done when: New dependencies are reviewed in the pull request, and the lockfile pins every one.
  - [Tool: OSV dependency lookup](https://softwaresecurity.com/tools/osv-lookup/)
  - [Tool: SBOM checker](https://softwaresecurity.com/tools/sbom-checker/)
  - [Practice: Dependency patching](https://softwaresecurity.com/maintenance/dependency-patching/)
  - [Review dependency health without treating a score as a guarantee](https://softwaresecurity.com/domains/supply-chain/dependencies/project-health-and-intake/)
  - [Stop dependency confusion and typosquatting at install time](https://softwaresecurity.com/domains/supply-chain/dependencies/dependency-confusion/)
  - [Adopt the OpenSSF S2C2F as a consumer: the eight practices, the four maturity levels and a staged plan with evidence](https://softwaresecurity.com/domains/supply-chain/dependencies/s2c2f-adoption/)
  - [Case study: the Shai-Hulud npm worm (2025-2026)](https://softwaresecurity.com/domains/supply-chain/dependencies/case-study-shai-hulud/)
  - NIST SSDF: PW.4
- [ ] **[Security code review](https://softwaresecurity.com/development/security-code-review/).** Review pull requests for the boundaries they touch: input parsing, authorization checks, output encoding, secrets and error handling.
  - Done when: Branch rules require an approving review from someone other than the author before merge.
  - [Workflow: secure a feature](https://softwaresecurity.com/workflows/secure-a-feature/)
  - [Tool: GitHub Actions workflow analyzer](https://softwaresecurity.com/tools/actions-analyzer/)
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Review a code change through its trust boundaries](https://softwaresecurity.com/domains/appsec/code-review/security-code-review/)
  - [Protect the source repository: rulesets, reviews and signed commits](https://softwaresecurity.com/domains/supply-chain/ci-cd/source-repository-protection/)
  - [Enforce authorization for every object action](https://softwaresecurity.com/domains/appsec/authorization/object-level-authorization/)
  - [Secure AI-assisted development with coding assistants and agents](https://softwaresecurity.com/domains/ai-emerging/agent-security/ai-assisted-development/)
  - NIST SSDF: PW.7, PS.1
- [ ] **[AI coding assistants](https://softwaresecurity.com/development/ai-coding-assistants/).** Review assistant output like any other contribution, keep secrets out of prompts and context, and limit what coding agents may run or change.
  - Done when: Generated code goes through the same review and checks, and agents run with scoped permissions.
  - [Secure AI-assisted development with coding assistants and agents](https://softwaresecurity.com/domains/ai-emerging/agent-security/ai-assisted-development/)
  - [Secure the developer workstation: extensions, package managers, secrets and AI agents](https://softwaresecurity.com/domains/supply-chain/ci-cd/developer-workstation-security/)
  - [Case study: the Nx s1ngularity compromise and its AI-assisted payload (2025)](https://softwaresecurity.com/domains/ai-emerging/agent-security/case-study-nx-s1ngularity/)
  - NIST SSDF: PO.5, PW.5, PW.7
- [ ] **[CI security checks](https://softwaresecurity.com/development/ci-security-checks/).** Run static analysis, secret scanning and dependency checks on every pull request, and decide in advance which findings block a merge.
  - Done when: The blocking criteria are written down, findings are triaged within an agreed time, and exceptions expire.
  - [Tool: OSV dependency lookup](https://softwaresecurity.com/tools/osv-lookup/)
  - [Workflow: Fix a finding](https://softwaresecurity.com/workflows/fix-a-finding/)
  - [Place each security control in the pipeline and decide what it blocks](https://softwaresecurity.com/domains/appsec/testing/devsecops-pipeline/)
  - [Choose and evaluate application security testing tools](https://softwaresecurity.com/domains/appsec/testing/appsec-tool-categories-and-evaluation/)
  - [Approve, expire and measure security exceptions without hiding risk](https://softwaresecurity.com/frameworks/risk-exceptions-and-metrics/)
  - NIST SSDF: PO.3, PO.4, PW.7
- [ ] **[Pipeline hardening](https://softwaresecurity.com/development/pipeline-hardening/).** Pin actions to commit SHAs and images to digests, give jobs least-privilege tokens, keep untrusted pull-request code away from secrets, and protect release branches.
  - Done when: Workflow permissions are read-only by default, and release jobs cannot be triggered from forks.
  - [Tool: GitHub Actions workflow analyzer](https://softwaresecurity.com/tools/actions-analyzer/)
  - [Harden GitHub Actions against workflow and supply-chain attacks](https://softwaresecurity.com/domains/supply-chain/ci-cd/github-actions-hardening/)
  - [Keep untrusted CI work outside the release boundary](https://softwaresecurity.com/domains/supply-chain/ci-cd/untrusted-workflow-boundaries/)
  - [Protect the path from pull request to release](https://softwaresecurity.com/domains/supply-chain/ci-cd/build-integrity/)
  - [Protect the source repository: rulesets, reviews and signed commits](https://softwaresecurity.com/domains/supply-chain/ci-cd/source-repository-protection/)
  - [Case study: the tj-actions/changed-files compromise (CVE-2025-30066)](https://softwaresecurity.com/domains/supply-chain/ci-cd/case-study-tj-actions/)
  - NIST SSDF: PO.3, PO.5, PS.1

## 4. Testing

_Does the running software resist what the threat model predicted?_

- [ ] **[Automated security tests](https://softwaresecurity.com/testing/automated-security-tests/).** Test authorization for each role and tenant, rejected inputs, limits and error handling, and add a regression test for every vulnerability you fix.
  - Done when: Security tests run in CI with the other tests and fail the build when a control regresses.
  - [Workflow: Test an application](https://softwaresecurity.com/workflows/test-an-application/)
  - [Tool: ASVS 5.0 checklist export](https://softwaresecurity.com/tools/asvs-checklist/)
  - [Abuse case library: tests and controls by feature](https://softwaresecurity.com/domains/appsec/threat-modeling/abuse-case-library/)
  - [Write testable security requirements and a security Definition of Done](https://softwaresecurity.com/domains/appsec/threat-modeling/security-requirements-definition-of-done/)
  - [Enforce authorization for every object action](https://softwaresecurity.com/domains/appsec/authorization/object-level-authorization/)
  - [Authorize functions and fields as well as objects](https://softwaresecurity.com/domains/appsec/authorization/function-property-authorization/)
  - NIST SSDF: PW.8
- [ ] **[SAST and DAST](https://softwaresecurity.com/testing/sast-and-dast/).** Tune static analysis to your own code, scan a deployed test build as a logged-in user, and confirm each finding with a request that reproduces it before fixing it.
  - Done when: Confirmed findings have a reproducing test, and suppressed false positives have a recorded reason.
  - [Workflow: Fix a finding](https://softwaresecurity.com/workflows/fix-a-finding/)
  - [Workflow: Test an application](https://softwaresecurity.com/workflows/test-an-application/)
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Combine static and dynamic tests around a verified finding](https://softwaresecurity.com/domains/appsec/testing/sast-dast-workflow/)
  - [Choose and evaluate application security testing tools](https://softwaresecurity.com/domains/appsec/testing/appsec-tool-categories-and-evaluation/)
  - [Place each security control in the pipeline and decide what it blocks](https://softwaresecurity.com/domains/appsec/testing/devsecops-pipeline/)
  - NIST SSDF: PW.7, PW.8
- [ ] **[Fuzzing](https://softwaresecurity.com/testing/fuzzing/).** Fuzz code that parses untrusted files, archives and protocols, and keep every crashing input as a regression test.
  - Done when: Fuzzing runs on a schedule, and each crash it finds becomes a test.
  - [Workflow: Test an application](https://softwaresecurity.com/workflows/test-an-application/)
  - [Fuzz a parser and turn crashes into lasting regressions](https://softwaresecurity.com/domains/appsec/testing/parser-fuzzing/)
  - [Find, fix and contain memory-safety bugs in C and C++](https://softwaresecurity.com/domains/appsec/platform-security/memory-safety-c-cpp/)
  - [Place each security control in the pipeline and decide what it blocks](https://softwaresecurity.com/domains/appsec/testing/devsecops-pipeline/)
  - NIST SSDF: PW.8
- [ ] **[ASVS verification](https://softwaresecurity.com/testing/asvs-verification/).** Choose the ASVS level that fits the application and record, for each requirement in scope, the test or review that shows it is met.
  - Done when: Every requirement in scope has evidence another engineer can repeat.
  - [Tool: ASVS 5.0 checklist export](https://softwaresecurity.com/tools/asvs-checklist/)
  - [Workflow: Test an application](https://softwaresecurity.com/workflows/test-an-application/)
  - [ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat](https://softwaresecurity.com/frameworks/asvs-verification-evidence/)
  - [Write testable security requirements and a security Definition of Done](https://softwaresecurity.com/domains/appsec/threat-modeling/security-requirements-definition-of-done/)
  - NIST SSDF: PW.7, PW.8
- [ ] **[Penetration testing](https://softwaresecurity.com/testing/penetration-testing/).** Scope penetration tests with the threat model for major releases and new attack surface, and track their findings like any other bug.
  - Done when: Each test has a written scope, and its findings are fixed or accepted with an owner.
  - [Tool: ASVS 5.0 checklist export](https://softwaresecurity.com/tools/asvs-checklist/)
  - [Tool: CVSS v4.0 calculator](https://softwaresecurity.com/tools/cvss-calculator/)
  - [Start with a VDP, then add bug bounties and penetration tests](https://softwaresecurity.com/domains/appsec/vulnerability-response/vdp-bug-bounty-pentest/)
  - [ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat](https://softwaresecurity.com/frameworks/asvs-verification-evidence/)
  - NIST SSDF: PW.8

## 5. Release

_Is what reaches production what you built, configured safely?_

- [ ] **[Artifact signing](https://softwaresecurity.com/release/artifact-signing/).** Sign packages and images, and verify signatures and provenance against an explicit trust policy before deploying.
  - Done when: The deploy step rejects unsigned artifacts and artifacts signed by an unexpected identity.
  - [Labs: practice in the browser](https://softwaresecurity.com/labs/)
  - [Verify artifact signatures against an explicit trust policy](https://softwaresecurity.com/domains/supply-chain/provenance/artifact-signature-policy/)
  - [Harden container images from Dockerfile to admission](https://softwaresecurity.com/domains/runtime/containers/container-image-hardening/)
  - [Protect package publication and the update channel](https://softwaresecurity.com/domains/supply-chain/releases/trusted-publishing-and-updates/)
  - [Read SLSA provenance and verify the claim you need](https://softwaresecurity.com/domains/supply-chain/provenance/read-and-verify-slsa/)
  - NIST SSDF: PS.2
- [ ] **[SBOM and provenance](https://softwaresecurity.com/release/sbom-and-provenance/).** Generate an SBOM for what you actually ship, and provenance from the build platform, and keep both with each release.
  - Done when: Every release has an SBOM and verifiable provenance that consumers can check.
  - [Tool: SBOM checker](https://softwaresecurity.com/tools/sbom-checker/)
  - [Tool: OSV dependency lookup](https://softwaresecurity.com/tools/osv-lookup/)
  - [Generate an SBOM for the software you actually release](https://softwaresecurity.com/domains/supply-chain/sbom/generate-release-inventory/)
  - [Read SLSA provenance and verify the claim you need](https://softwaresecurity.com/domains/supply-chain/provenance/read-and-verify-slsa/)
  - [Choose SBOM formats and identify components accurately](https://softwaresecurity.com/domains/supply-chain/sbom/formats-and-identifiers/)
  - [Review SBOM changes between releases](https://softwaresecurity.com/domains/supply-chain/sbom/release-diff-and-distribution/)
  - [Use VEX without losing vulnerability evidence](https://softwaresecurity.com/domains/supply-chain/vex/producer-and-consumer-decisions/)
  - NIST SSDF: PS.3
- [ ] **[Secure defaults](https://softwaresecurity.com/release/secure-defaults/).** Turn off debug modes, verbose errors and sample content, set the security headers, and make the safe configuration the default one.
  - Done when: A pre-release check of the deployed system confirms the headers, error pages and exposed paths, and a failure blocks the release.
  - [Tool: security headers analyzer](https://softwaresecurity.com/tools/security-headers/)
  - [Tool: CSP evaluator](https://softwaresecurity.com/tools/csp-evaluator/)
  - [Ship without debug modes, verbose errors or exposed files](https://softwaresecurity.com/domains/appsec/secure-coding/information-disclosure-misconfiguration/)
  - [Configure HTTP security headers from a tested baseline](https://softwaresecurity.com/domains/appsec/browser-security/security-headers/)
  - [Handle failures without leaking internals or weakening controls](https://softwaresecurity.com/domains/appsec/secure-coding/secure-error-handling/)
  - [Apply CISA Secure by Design: principles, pledge goals and evidence](https://softwaresecurity.com/frameworks/secure-by-design/)
  - NIST SSDF: PW.9
- [ ] **[IaC and containers](https://softwaresecurity.com/release/iac-and-containers/).** Review infrastructure changes as access changes, build minimal images that run as non-root, and enforce admission policies in the cluster.
  - Done when: Policy checks run on IaC and manifests in CI, and the cluster rejects workloads that break them.
  - [Browser labs](https://softwaresecurity.com/labs/)
  - [Review infrastructure changes as access changes](https://softwaresecurity.com/domains/runtime/cloud-posture/iac-security/)
  - [Harden container images from Dockerfile to admission](https://softwaresecurity.com/domains/runtime/containers/container-image-hardening/)
  - [Run Kubernetes workloads with only the privileges they need](https://softwaresecurity.com/domains/runtime/containers/kubernetes-workload-security/)
  - [Test infrastructure policy and detect security-relevant drift](https://softwaresecurity.com/domains/runtime/cloud-posture/iac-policy-drift/)
  - NIST SSDF: PW.9
- [ ] **[Runtime secrets](https://softwaresecurity.com/release/runtime-secrets/).** Give workloads short-lived credentials through workload identity or a secrets manager, rather than baking secrets into images or environment files.
  - Done when: Each workload can read only its own secrets, and they rotate without a code change.
  - [Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS](https://softwaresecurity.com/domains/identity-crypto/secrets/secrets-in-kubernetes-and-runtime/)
  - [Workload identity federation: short-lived, scoped identities for services and CI](https://softwaresecurity.com/domains/identity-crypto/identity/workload-identity-models/)
  - [Secrets management: storage, rotation and leaked-secret response](https://softwaresecurity.com/domains/identity-crypto/secrets/secrets-lifecycle/)
- [ ] **[Staged rollout](https://softwaresecurity.com/release/staged-rollout/).** Release to a small group first, watch health and security signals, and keep a rollback you have practiced.
  - Done when: Rollback has been exercised, and a bad release can be stopped before it reaches everyone.
  - [Staged rollout and rollback for security-critical updates](https://softwaresecurity.com/domains/supply-chain/releases/staged-rollout-rollback/)
  - [Case study: CrowdStrike Channel File 291 (July 2024)](https://softwaresecurity.com/domains/appsec/platform-security/case-study-crowdstrike-channel-file-291/)
  - [Design firmware updates that can recover safely](https://softwaresecurity.com/domains/appsec/platform-security/embedded-update-security/)

## 6. Maintenance

_Will you notice an attack, and can you fix a vulnerability quickly?_

- [ ] **[Security logging](https://softwaresecurity.com/maintenance/security-logging/).** Log sign-ins, authorization failures, administrative actions and rejected input with enough context to investigate, without secrets or unnecessary personal data.
  - Done when: Alerts exist for the events the threat model cares about, and the logs have been used in an exercise.
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Create security logs someone can investigate](https://softwaresecurity.com/domains/runtime/detection/security-event-logging/)
  - [Turn runtime events into a tested investigation and containment path](https://softwaresecurity.com/domains/runtime/detection/runtime-detection-response/)
  - [Prevent CRLF header injection, log forging and CSV formula injection](https://softwaresecurity.com/domains/appsec/secure-coding/crlf-header-log-injection/)
  - NIST SSDF: PW.1
- [ ] **[Vulnerability intake](https://softwaresecurity.com/maintenance/vulnerability-intake/).** Monitor advisories for your dependencies, and run a vulnerability disclosure program so outsiders can report what they find.
  - Done when: Reports and component advisories reach a named owner within days, and a security.txt file on every public host says where to report.
  - [Tool: security.txt validator](https://softwaresecurity.com/tools/security-txt/)
  - [Tool: OSV dependency lookup](https://softwaresecurity.com/tools/osv-lookup/)
  - [Workflow: Respond to a vulnerability](https://softwaresecurity.com/workflows/respond-to-a-vulnerability/)
  - [Start with a VDP, then add bug bounties and penetration tests](https://softwaresecurity.com/domains/appsec/vulnerability-response/vdp-bug-bounty-pentest/)
  - [Run coordinated vulnerability disclosure from report to advisory](https://softwaresecurity.com/domains/appsec/vulnerability-response/coordinated-disclosure/)
  - [Set up a PSIRT: services, intake, triage, SLAs and the CNA role](https://softwaresecurity.com/domains/appsec/vulnerability-response/psirt-operating-model/)
  - NIST SSDF: RV.1
- [ ] **[Risk-based prioritization](https://softwaresecurity.com/maintenance/risk-based-prioritization/).** Prioritize by known exploitation, exposure and impact rather than by CVSS score alone, and fix within deadlines you measure.
  - Done when: Each confirmed finding has an owner and a due date from a written policy, and overdue findings are visible.
  - [Workflow: Respond to a vulnerability](https://softwaresecurity.com/workflows/respond-to-a-vulnerability/)
  - [Tool: CVSS v4.0 calculator](https://softwaresecurity.com/tools/cvss-calculator/)
  - [Prioritize vulnerabilities by exploitation, exposure and impact](https://softwaresecurity.com/frameworks/vulnerability-prioritization/)
  - [Set remediation SLAs and measure AppSec outcomes](https://softwaresecurity.com/frameworks/appsec-metrics-and-slas/)
  - [Approve, expire and measure security exceptions without hiding risk](https://softwaresecurity.com/frameworks/risk-exceptions-and-metrics/)
  - NIST SSDF: RV.2
- [ ] **[Dependency patching](https://softwaresecurity.com/maintenance/dependency-patching/).** When an advisory lands for a dependency you ship, check whether it applies and whether the vulnerable code is reachable, then upgrade or record why not.
  - Done when: Each dependency finding has a recorded decision with evidence, and known-exploited ones are fixed first.
  - [Tool: OSV dependency lookup](https://softwaresecurity.com/tools/osv-lookup/)
  - [Tool: SBOM checker](https://softwaresecurity.com/tools/sbom-checker/)
  - [Workflow: Respond to a vulnerability](https://softwaresecurity.com/workflows/respond-to-a-vulnerability/)
  - [Triage new dependency vulnerability findings](https://softwaresecurity.com/domains/supply-chain/dependencies/evidence-based-triage/)
  - [Respond to an exploited or malicious dependency](https://softwaresecurity.com/domains/appsec/vulnerability-response/dependency-vulnerability-response/)
  - [Use VEX without losing vulnerability evidence](https://softwaresecurity.com/domains/supply-chain/vex/producer-and-consumer-decisions/)
  - NIST SSDF: PW.4, RV.2
- [ ] **[Advisories and incidents](https://softwaresecurity.com/maintenance/advisories-and-incidents/).** When a vulnerability affects users, publish an advisory that says who is affected and what to do, and follow an incident plan you have rehearsed.
  - Done when: The incident plan has a named owner and has been exercised, and advisories go out in a standard, machine-readable format.
  - [Workflow: Respond to a vulnerability](https://softwaresecurity.com/workflows/respond-to-a-vulnerability/)
  - [Tool: CVSS v4.0 calculator](https://softwaresecurity.com/tools/cvss-calculator/)
  - [Publish security advisories with CSAF, VEX, CVE records and OSV](https://softwaresecurity.com/domains/appsec/vulnerability-response/security-advisories-csaf-vex/)
  - [Respond to product security incidents: plan, tabletop and postmortem](https://softwaresecurity.com/domains/appsec/vulnerability-response/product-incident-response/)
  - [Set up a PSIRT: services, intake, triage, SLAs and the CNA role](https://softwaresecurity.com/domains/appsec/vulnerability-response/psirt-operating-model/)
  - [Build a runbook for CRA vulnerability and incident reporting](https://softwaresecurity.com/frameworks/cra-reporting-runbook/)
  - NIST SSDF: RV.1, RV.2
- [ ] **[Root cause analysis](https://softwaresecurity.com/maintenance/root-cause-analysis/).** After each significant vulnerability, find out why it was possible, and change the requirements, patterns, checks or training so the same class does not return.
  - Done when: Each significant vulnerability has a recorded root cause, and the changes it calls for are owned backlog items for the earlier phases.
  - [Workflow: Fix a finding](https://softwaresecurity.com/workflows/fix-a-finding/)
  - [Fix cards: tested fixes by stack](https://softwaresecurity.com/fix/)
  - [Respond to product security incidents: plan, tabletop and postmortem](https://softwaresecurity.com/domains/appsec/vulnerability-response/product-incident-response/)
  - [Set remediation SLAs and measure AppSec outcomes](https://softwaresecurity.com/frameworks/appsec-metrics-and-slas/)
  - [Write testable security requirements and a security Definition of Done](https://softwaresecurity.com/domains/appsec/threat-modeling/security-requirements-definition-of-done/)
  - [Run a developer security training program that changes code](https://softwaresecurity.com/frameworks/developer-security-training/)
  - NIST SSDF: RV.3

## Security program

_Who owns security, and how do you know the practices are working?_

- [ ] **[Owners and champions](https://softwaresecurity.com/program/owners-and-champions/).** Give each product an accountable owner for its security work, and support a security champion in each team with protected time.
  - Done when: Every product, finding and exception has a named owner, and each team's champion has protected time and takes part in design reviews.
  - [Workflow: Build an AppSec program](https://softwaresecurity.com/workflows/build-an-appsec-program/)
  - [Run a security champions program with protected time and outcome metrics](https://softwaresecurity.com/frameworks/security-champions-program/)
  - [Start a minimal AppSec program with owners, triggers and metrics](https://softwaresecurity.com/frameworks/appsec-program/)
  - [Run an AppSec program: owners, finding states, deadlines and champions](https://softwaresecurity.com/frameworks/program-operations/)
  - NIST SSDF: PO.2
- [ ] **[Role-based training](https://softwaresecurity.com/program/role-based-training/).** Train developers on the weaknesses their stack produces, with hands-on practice, and measure the effect on the code rather than course completion.
  - Done when: Each team's training topics come from the findings it actually gets, and its repeat findings are compared before and after.
  - [Browser labs](https://softwaresecurity.com/labs/)
  - [Fix cards by stack](https://softwaresecurity.com/fix/)
  - [Learning paths](https://softwaresecurity.com/learn/)
  - [Workflow: Fix a finding](https://softwaresecurity.com/workflows/fix-a-finding/)
  - [Run a developer security training program that changes code](https://softwaresecurity.com/frameworks/developer-security-training/)
  - [Run a security champions program with protected time and outcome metrics](https://softwaresecurity.com/frameworks/security-champions-program/)
  - NIST SSDF: PO.2
- [ ] **[Exceptions and metrics](https://softwaresecurity.com/program/exceptions-and-metrics/).** Track time to fix and recurring weakness classes, and give every accepted risk an owner and an expiry date.
  - Done when: Metrics are reviewed on a set schedule, and every open exception has a risk owner and an expiry date.
  - [Workflow: Build an AppSec program](https://softwaresecurity.com/workflows/build-an-appsec-program/)
  - [Workflow: Respond to a vulnerability](https://softwaresecurity.com/workflows/respond-to-a-vulnerability/)
  - [Approve, expire and measure security exceptions without hiding risk](https://softwaresecurity.com/frameworks/risk-exceptions-and-metrics/)
  - [Set remediation SLAs and measure AppSec outcomes](https://softwaresecurity.com/frameworks/appsec-metrics-and-slas/)
  - [Run an AppSec program: owners, finding states, deadlines and champions](https://softwaresecurity.com/frameworks/program-operations/)
  - NIST SSDF: PO.1, PO.4, RV.2
- [ ] **[SSDF and SAMM mapping](https://softwaresecurity.com/program/framework-mapping/).** Map what you do to NIST SSDF or OWASP SAMM, so gaps and the evidence for attestations come from one place.
  - Done when: Each SSDF practice or SAMM activity you claim links to current evidence, and each gap has an owner and a date.
  - [Workflow: Build an AppSec program](https://softwaresecurity.com/workflows/build-an-appsec-program/)
  - [Standards and identifiers](https://softwaresecurity.com/standards/)
  - [Apply NIST SSDF (SP 800-218) to one product: practices, evidence and attestation in 2026](https://softwaresecurity.com/frameworks/ssdf-product-lifecycle/)
  - [Run an OWASP SAMM assessment with evidence and a practical roadmap](https://softwaresecurity.com/frameworks/samm-assessment/)
  - [BSIMM vs SAMM vs SSDF: what each is for and which to use](https://softwaresecurity.com/frameworks/bsimm-samm-ssdf/)
  - [Answer a US federal secure software attestation request in 2026: the CISA form, its SSDF mapping and the evidence behind each statement](https://softwaresecurity.com/frameworks/secure-software-attestation-form/)
  - [Control mapping between frameworks: state the relationship without overstating equivalence](https://softwaresecurity.com/frameworks/control-mapping-and-evidence/)
  - NIST SSDF: PO.1