DevSecOps Breach Response Checklist
A poisoned dependency ran in your builds, a pipeline secret leaked, or a release does not match its hash. Twenty-seven steps to freeze, revoke, rebuild and tell the people who consume your software.
Template & sample only — a structured starting point with sample content, not legal, audit, certification or investment advice.Customise it with your own details for free; exporting the generated document is part of Pro.
A working checklist for a CI/CD or software supply chain incident: freeze pipelines, revoke CI tokens, deploy keys and OIDC trust, audit runner hosts, verify artefacts (hashes, signatures, provenance), check lockfiles, rebuild from clean, notify downstream consumers and publish an advisory. Mark each step and generate a record for the incident file.
Your context
1. Freeze and preserve
Stop the pipeline from producing or shipping anything new until you know it can be trusted — and keep the records that tell you what it already did.
Pause release and deploy pipelines for the affected repositories, and stop auto-publishing to registries and app storesmaterial
Export CI/CD audit logs, workflow run logs, runner logs and source-host audit logs before they age outmaterial
List every pipeline-definition change, new runner, new integration, new webhook and new deploy key in the suspected window
Start a timeline: first malicious commit, dependency version or run; first and last affected build; when you became aware
2. Revoke pipeline access
Anything the pipeline could reach, the attacker could reach. Cut access in order of power, and verify each replacement before revoking the old credential.
Revoke and reissue CI tokens, personal access tokens used by automation, and registry publish tokens, starting with the most powerfulmaterial
Rotate deploy keys and SSH keys used by pipelines; remove any you do not recognisematerial
Review cloud OIDC trust policies for CI: restrict to specific repositories, branches and environments, and remove wildcard subjectsmaterial
Rotate secrets stored in the CI platform (repository, organisation and environment secrets) that affected jobs could read
Review installed CI and source-host apps, OAuth grants and webhooks; remove unused ones and anything added in the window
Check maintainer and admin accounts for compromise: MFA status, new SSH/GPG keys, recent sign-ins and session tokens
3. Audit runner hosts
Take affected self-hosted runners offline, image them for evidence, then rebuild them from a clean imagematerial
Move build jobs to ephemeral runners that start clean for each job
Purge build caches, dependency caches and container layer caches that affected jobs could write to
Restrict runner network egress to the registries and endpoints builds actually need
4. Verify artefact integrity
Prove that what you shipped is what you meant to ship. If you cannot prove it, rebuild it.
List every artefact built in the window: packages, container images, binaries, installers, infrastructure templatesmaterial
Compare artefact hashes against independent rebuilds or known-good records, and verify signatures and build provenanceSLSAmaterial
Check dependency lockfiles and manifests for unexpected versions, new dependencies, changed registries or changed integrity hashesmaterial
Rebuild affected artefacts from verified source, pinned dependencies and clean runners; publish as new versionsmaterial
If signing keys or their passphrases were reachable, revoke them, issue new keys and re-sign the rebuilt artefacts
5. Notify downstream and disclose
Notify downstream consumers (customers, internal teams, partners) which versions are affected, what to do and how to verify the fixmaterial
Report malicious packages to the registry and deprecate or yank your own affected versions
Publish a security advisory and request a CVE where your own product was affected
Have counsel assess regulatory and contractual notification duties, especially if exposed secrets gave access to personal dataGDPR Art. 33
6. Recover and harden
Re-enable pipelines only after secrets are rotated, runners rebuilt and pipeline definitions reviewedmaterial
Harden dependency intake: committed lockfiles, clean installs in CI, install scripts disabled by default, a registry proxy with a delay on brand-new versions
Give each job only the secrets it needs, prefer short-lived OIDC credentials, and protect release environments with required reviewers
Hold a post-incident review and track fixes with owners and datesNIST SSDF
What this template gives you
- Twenty-seven steps in six sections: freeze and preserve, revoke pipeline access, audit runners, verify artefacts, notify downstream, recover and harden.
- Access is cut in order of power: registry publish tokens and cloud deploy credentials before low-value keys, and every new credential verified before the old one is revoked.
- OIDC is not automatically safe: a short-lived token expires, but a loose trust policy lets an attacker mint new ones.
- Artefacts built in the window are proven clean (hashes, signatures, provenance) or rebuilt and published as new versions.
- The summary tells you whether it is safe to unfreeze pipelines yet.
Frequently asked questions
A malicious package ran in our CI. What do we rotate?
Every secret any affected job could read, not only the ones you think were used. Work out which jobs installed the bad version in the window, list the secrets available to each job (repository, organisation and environment secrets, cloud credentials, registry tokens), and rotate them in order of power. Short-lived job tokens may already have expired; check that before spending time on them, and review the trust policies that issue them.
Do we have to rebuild artefacts if the payload only stole secrets?
Usually yes for anything shipped to others. Payload analysis is rarely complete in the first days, and a second stage could have changed build output. Rebuilding from verified source on clean runners and publishing new versions is cheaper than proving a negative to every customer.
Should we tell customers if we are not sure they are affected?
Tell them what you know: the affected versions, how to check, what to do and when you will update them. A short, factual notice early is better than a complete one late, and "these versions are not affected" is useful news too. Coordinate wording with counsel.
Is this a finished document I can rely on?
No. Every tool in this suite is a template with sample content. It gives you a structured, editable starting point and generates a document from your own answers, but it is not legal, audit, certification, investment or professional advice. Review and adapt the output, and have it checked by the appropriate specialist before you rely on it.
Who can use it?
Anyone. Using it and customising it with your own details is free, and your work is saved in your own browser. Exporting the generated document (Word, PDF, Markdown, CSV) is part of any PlayCISO paid plan.
More free security tools
The tools people use most on PlayCISO.
Catch injected instructions hiding in content your AI agent should only read.
Score your readiness against the first international standard for AI security threats.
Critical CVEs across 21 major vendors, month by month — and what the 2026 surge means.
Build an ordered ruleset, replay labelled packets and catch shadowed and any-to-any rules.
Self-assess all six Functions, from Govern to Recover, and see your weakest one.
Search 172 threat actors across Microsoft, CrowdStrike, Mandiant and community names.