Release
Ship what you built, signed and with an SBOM, with secure defaults on hardened infrastructure, in stages you can roll back.
Is what reaches production what you built, configured safely?
Security practices in this phase
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.
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.
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.
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.
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.
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.
Guides
51 guides- Review infrastructure changes as access changes
Inspect the effective permissions, exposure, sensitive state, and recovery implications of a proposed infrastructure change.
- 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.
- 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.
- 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.
- 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.
- 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.
- Authenticate workloads and authorize their service actions
Use service identities, mutual TLS and function permissions without mistaking an encrypted connection for complete authorization.
- 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.
- Choose SBOM formats and identify components accurately
Separate schema versions, document references and package identities so inventory conversion and advisory matching preserve meaning.
- Review SBOM changes between releases
Turn inventory differences into explainable release decisions without confusing generator changes with software changes.
- 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.
- Read SLSA provenance and verify the claim you need
Connect an artifact to its build evidence while distinguishing provenance, build assurance and source controls.
- Investigate build differences and improve reproducibility
Control inputs and environment, compare artifact bytes, and explain the security properties a repeatable build can demonstrate.
- Protect package publication and the update channel
Constrain release identities, verify what consumers receive, and prepare for publisher or update-key compromise.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Also part of this phase
- 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.
- 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.
- 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.
- Keep untrusted CI work outside the release boundary
Review workflow authority, persistent state and artifact handoffs before contributor-controlled code reaches privileged jobs.
- Use VEX without losing vulnerability evidence
Produce and consume precise vulnerability status statements tied to the product, version, justification and evidence.
- 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.
- 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.
- 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.
- 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.
- Treat model releases as executable supply-chain inputs
Verify provenance, constrain loading and preserve the relationship between model weights, configuration and runtime dependencies.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.