CI/CD pipeline compromise response checklist

Freeze the pipeline first — this is not a statute

Audience: the incident commander facing a compromised CI/CD pipeline (poisoned workflow, compromised runner, stolen pipeline secret, or tampered artifact), and counsel, the insurer, and DFIR on the out-of-band bridge. The we've-been-breached page on this site is the first-moves hub. The preserve-evidence page on this site is the capture order for workflow-run logs, runner images, and artifact stores. The credential-compromise-checklist page on this site is the revoke-rotate-hunt for the identity that minted the pipeline tokens. The who-to-call page on this site is the contact order. This page is the CI/CD-compromise runbook: freeze poisoned builds, audit runners, workflows, and secrets, rotate every pipeline credential and signing key, verify artifact provenance, then check downstream releases. It does not rank GitHub Actions, GitLab CI, Jenkins, or any other pipeline product, does not rank DFIR firms, does not name any host as the source of truth, and does not start a notification clock.

CISA and NSA's Defending CI/CD Environments CSI (28 June 2023, last verified still listed on 7 September 2026) is tool-agnostic: it enumerates common CI/CD risks and attack surfaces and asks organizations to harden the pipeline without regard to the specific tools being adapted — a cybersecurity information sheet, not a statute. NIST SP 800-218 SSDF Version 1.1 is recommendations for mitigating software-vulnerability risk (PS.1 protect all forms of code from unauthorized access and tampering; PS.2 provide a mechanism for verifying software release integrity; PW.6 configure compilation, interpreter, and build processes to improve executable security) — recommendations, not a statute. NIST SP 800-204D maps those SSDF practices onto CI/CD pipeline stages and cites SLSA for provenance and attestation — strategies, not a statute. SLSA v1.2 is a specification for describing and incrementally improving supply-chain security; Build L1 is provenance exists, L2 is signed provenance from a hosted build platform, L3 is a hardened build platform — a specification, not a statute, and not a legal requirement this page will invent. Last verified 7 September 2026. Not legal advice.

• Freeze first, then audit, then rotate, then verify artifacts. A new signing key with a still-running poisoned job is not containment. CISA/NSA CSI: recognize the attack surfaces (source, build environment, secrets, artifact store) and stop the path that is still publishing.
• Do not tip the actor. No in-band 'we see you', no public status page, no mass secret rotation from a possibly compromised pipeline identity. CISA: actors watch the response. Preserve workflow-run logs and runner state before you wipe the runner to 'start clean.' The preserve-evidence page on this site is that hold.
• The credential-compromise-checklist page on this site is the revoke-rotate-hunt for the identity that minted the pipeline tokens. The cloud-account-compromise-checklist page on this site is the preserve-logs-first tenant runbook when a pipeline minted cloud keys. The repository-compromise-checklist page on this site is the access-and-token audit, planted-commit hunt, and secret-rotation runbook. The supply-chain-incident-checklist page on this site is the vendor-incident intake, blast-radius, and flow-down runbook.
• This page does not rank pipeline products, does not interpret YOUR policy, does not start a notification clock, and is not legal advice.

What to do now

Walk top to bottom. Unknowns belong on the list. Last verified 7 September 2026. Not legal advice.

• Declare the incident. Name one commander. Open an out-of-band bridge the actor cannot see (phone, a clean conference). The who-to-call page on this site is the contact order.
• Freeze the pipeline: disable workflows, cancel in-flight jobs, pause self-hosted runners, and stop deploys and publishes from the compromised path. Do not delete the run history, the runner, or the artifact to 'clean up.' This product does not freeze pipelines.
• Place the evidence hold on workflow-run logs, runner registration and audit, CI variables and secret-access records, artifact and package-registry publishes, and webhook deliveries. GitHub: if a secret appeared unredacted in a log, delete that log after you have an exported copy, then rotate the secret. GitLab: document the time of exposure and the time you revoked. The preserve-evidence page on this site is the capture list.
• Audit runners, workflows, and secrets: new or edited workflow files, reusable workflows, third-party actions pinned to a moving tag, self-hosted runner groups, privileged executors, CI variables, OIDC trusts, and webhook destinations created in the dwell window. Unexplained is persistence until an owner claims it.
• Rotate every pipeline credential and signing key: CI secrets, deploy tokens, runner registration tokens, job tokens still in logs, package-registry tokens, cloud keys the pipeline could mint, and the keys that sign artifacts, commits, or container images. A commit that deletes a leaked secret is not rotation. This product does not rotate signing keys.
• Verify artifact provenance for anything the pipeline published in the window: packages, containers, GitHub/GitLab Releases, signed blobs. SLSA: a verifier rejects an artifact whose provenance subject does not match the hash received — that check does not catch a build that honestly built planted source. This product does not verify SLSA provenance.
• Check downstream releases: who consumed a possibly poisoned artifact; yank or unpublish only after you have a copy and a consumer-notification plan. The supply-chain-incident-checklist page on this site is the vendor-incident intake and flow-down runbook. Page counsel and the insurer if YOUR plan or policy requires prompt notice. This page does not start a clock.

Freeze-and-audit — runners, workflows, secrets

Containment for a compromised pipeline is not 'rerun the last job and hope.' CISA/NSA CSI treats the build environment, the secrets the job can read, and the artifact store it can write as distinct attack surfaces. GitHub's secure-use reference treats self-hosted runners as persistently compromiseable by untrusted workflow code and tells you they should almost never be used for public repositories. GitLab's runner-security guide treats the shell executor and Docker privileged mode on reused machines as high-risk because a job can steal CI_JOB_TOKEN and other secrets from a compromised environment. Walk the rows. Last verified 7 September 2026. Not legal advice.

Rotate pipeline secrets and signing keys

A frozen pipeline that still holds the old signing key will sign the next artifact the actor queues. Rotate at the issuer, then revoke the old value. CISA's 28 May 2026 supply-chain alert (Nx Console / GitHub repositories) tells organizations that discover a compromise to rotate and revoke all secrets accessible to CI/CD, including API keys, cloud credentials, SSH keys, registry tokens, and GitHub/GitLab/Bitbucket tokens. GitHub's secure-use reference: if an unredacted secret is sent to a workflow-run log, delete the log and rotate the secret. NIST SP 800-218 PS.1 is protect all forms of code from unauthorized access and tampering — recommendations, not a statute. Last verified 7 September 2026. Not legal advice.

Artifact provenance — SLSA is guidance, not a statute

SLSA (Supply-chain Levels for Software Artifacts) is a specification, established by industry consensus, for describing and incrementally improving supply-chain security. It is not a statute, not a certification this product issues, and not a legal requirement this page will invent. Build L0 is no guarantees. Build L1 is provenance showing how the package was built — it can catch mistakes and is trivial to forge. Build L2 is signed provenance generated by a hosted build platform. Build L3 is a hardened build platform that resists tampering during the build. NIST SP 800-204D cites SLSA among the building blocks to integrate into CI/CD pipelines. A verifier that checks provenance is asking whether the artifact matches the signed claim about how it was built; it is not asking whether the source the builder honestly compiled was itself planted. Last verified 7 September 2026. Not legal advice.

• Inventory every artifact the compromised path published in the dwell window: packages, containers, GitHub/GitLab Releases, signed blobs, SBOMs. Unknown publishes are a gap, not a clean bill.
• If provenance is missing, write that down. Do not invent a SLSA level. This product does not verify SLSA provenance and does not issue a SLSA attestation.
• The supply-chain-incident-checklist page on this site is the vendor-incident intake and flow-down runbook. Downstream notification of a poisoned artifact is often a supply-chain question for counsel on YOUR facts. This page does not start that clock.

Downstream-release impact

A poisoned pipeline is how a source compromise becomes a consumer compromise. SLSA threat (F) is artifact publication that does not reflect the official source; threat (G) is a modified package on the registry or in transit. CISA's 28 May 2026 supply-chain alert tells organizations that discover a compromise to conduct a forensics review of CI/CD logs, cloud audit trails, and affected developer machines, and to notify proper stakeholders if necessary — a cybersecurity alert, not a statute, and not a determination that YOUR notification duty has started. The supply-chain-incident-checklist page on this site is the vendor-incident intake, blast-radius, and flow-down runbook. Last verified 7 September 2026. Not legal advice.

• Name the artifacts, registries, release channels, and downstream consumers that may have taken a build from the compromised path. Internal mirrors and 'latest' tags are in scope.
• Yank or unpublish only after you have a copy, a hash, and a consumer-notification plan. Pin consumers to a known-good digest. Rotate signing keys if the actor could have used them.
• This product's blast-radius search is over captured dependencies — transitive npm when a lockfile was fetched. That is package exposure in YOUR tree, not a finding that a release you published was poisoned and not a freeze of YOUR pipeline.
• Delivery Health is a DORA posture score (deployment frequency, lead time, change failure rate, time to restore) from connected sources, including GitHub Actions run failures and duration. A drop in deploy frequency after you freeze the pipeline is an expected measurement change, not a detector that the pipeline is compromised.

Provider pipeline pointers — not a ranking

Each major pipeline product publishes its own runner-security and secrets documentation. The rows below are pointers so a responder can find the current doc. They are not a comparison, not a recommendation of which CI to run, and not a finding that one provider's runner is 'enough.' Use the doc for the pipeline you actually run. If you run more than one, do the freeze-audit-rotate-verify loop in each. Last verified 7 September 2026. Not legal advice.

• The order of the rows is alphabetical by common short name, not a ranking. This page does not rank GitHub Actions or GitLab CI.
• Follow the current provider doc, not a screenshot of this table. Last verified 7 September 2026 is how you can see we have not re-checked yet.
• CISA/NSA Defending CI/CD Environments CSI remains the tool-agnostic overlay: harden source, build environment, secrets, and artifact store regardless of which product you run.

Where this shows up in ShipReady Metrics

The signed-in app does not freeze pipelines, cancel workflow runs, take runners offline, rotate pipeline secrets, rotate signing keys, verify SLSA provenance, or unpublish a poisoned artifact. It does ingest security findings, including GitHub secret-scanning alerts (exposed secrets as findings, typically critical), Dependabot alerts, and code-scanning / SAST findings. Security findings is where those land, alongside DAST. Security also has a blast-radius search over captured dependencies — transitive npm when a lockfile was fetched — which is package exposure, not a poisoned-pipeline hunt. Delivery Health is a DORA posture score (deployment frequency, lead time for changes, change failure rate, time to restore) from connected sources, including GitHub Actions workflow runs (failures, duration) and deployments where available; it is not an incident-response runbook and not a detector that YOUR pipeline is compromised. The AI-authored-code floor is a git-marker count of attributed lines — a floor, not a claim that the pipeline reviewed the model. The GitHub connector and GitHub App are read-only (Contents, Metadata, Pull requests, Actions, Administration, Dependabot/code/secret-scanning alerts; org Members) — nothing writable. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness for findings the org has classified as CRA-in-scope. That ladder is not a CI/CD-compromise runbook, it does not start a clock for you, and it is not a determination that CRA applies. A named human still submits. None of those surfaces freezes a pipeline, rotates a signing key, or verifies SLSA provenance.

Primary sources (last verified 7 September 2026)

Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.

CISA and NSA, Defending Continuous Integration/Continuous Delivery (CI/CD) Environments (Cybersecurity Information Sheet, 28 June 2023) remains the current joint CISA/NSA CI/CD-hardening CSI this page cites — tool-agnostic recommendations and best practices, not a statute, last verified still listed on 7 September 2026. CISA, Supply Chain Compromises Impact Nx Console and GitHub Repositories (alert, 28 May 2026) remains the current CISA supply-chain alert this page cites for rotating and revoking CI/CD-accessible secrets (including GitHub/GitLab/Bitbucket tokens and SSH keys) and reviewing CI/CD logs — a cybersecurity alert, not a statute. NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 (February 2022) remains the current SSDF this page cites (PS.1 protect code from unauthorized access and tampering; PS.2 verify software release integrity; PW.6 configure build processes) — recommendations, not a statute. NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (February 2024) maps those SSDF practices onto CI/CD stages and cites SLSA — strategies, not a statute. SLSA v1.2, Threats & mitigations remains the current SLSA threat model this page cites for build threats (D) external build parameters, (E) build process, (F) artifact publication, and (G) distribution channel — a specification, not a statute, and not a legal requirement. OpenSSF Source Code Management Platform Configuration Best Practices (Best Practices Working Group, 2023-08-29) is industry practice covering GitHub and GitLab equally (default workflow token read-only, workflows should not approve pull requests, runner groups limited) — not a ranking and not a statute. CNCF TAG Security, Software Supply Chain Best Practices, remains the CNCF overlay this page cites for layered controls, signing and verification, and a minimal build environment — industry practice, not a statute. GitHub, Secure use reference (Actions security hardening), and GitLab, Security for self-managed runners plus CI/CD job token, are vendor documentation, not a statute, and are not ranked. NIST SP 800-61r2 remains the current final Computer Security Incident Handling Guide this cluster cites for containment then eradication then recovery.

Frequently asked questions