DisasterLab
PlaybooksSoftware dependency compromised
Vendorcritical50 minutes to prepare

Software dependency compromised

A library, container, plugin, action, SDK, or build dependency may contain malicious or unauthorized code.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Stop installing or executing the suspect dependency, determine which builds included it, and replace artifacts from a known-good dependency graph.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Preserve lockfiles, package-manager metadata, registry responses, integrity hashes, SBOMs, build logs, cache contents, images, and the exact malicious package archive.
  • List every build by dependency version, transitive path, build time, runner, artifact digest, environment, and deployment destination.
  • Capture install scripts, runtime network calls, file changes, environment-variable reads, and credentials available to build and production processes.
  • Record registry ownership, maintainer, release, signing, provenance, and advisory changes during the affected window.

Decisions that change the response

QuestionAct whenAction
Pause builds or production?Install-time code saw CI secrets, runtime code is deployed, or behavior is unknown.Stop affected pipelines and isolate deployed workloads until exposure and execution are understood.
Downgrade or remove?A known-good version exists and its archive and maintainers can be verified.Pin the trusted digest; otherwise remove or replace the dependency and its transitive path.
Rotate credentials?The package executed where credentials, source, signing keys, or cloud metadata were available.Revoke at every issuer and rebuild from clean runners. Do not only change CI variables.

Proof that recovery worked

  • The dependency graph and artifact SBOM contain no affected package version or digest.
  • Clean runners reproduce signed artifacts whose hashes match the reviewed build output.
  • Network, endpoint, cloud, registry, and signing logs show the full effect of package execution.
  • Old artifacts are removed from deployment, caches, registries, releases, and rollback targets.

Controls to put in place

  • Commit lockfiles, verify integrity, restrict install scripts, and review dependency ownership changes.
  • Generate SBOMs and provenance for releases, then map advisories to deployed artifact digests.
  • Give build jobs short-lived, job-specific credentials and isolate signing from dependency installation.
  • Use dependency update review, internal mirrors for critical packages, and reproducible clean builds.
Tabletop drill

Flag a harmless transitive package version as compromised. Find every build containing it, pause one pipeline, rebuild without network access from a clean cache, rotate a test credential, and remove old artifacts.

Escalate when

Use specialist incident response and contact the registry when malicious code executed in CI or production, signing material was accessible, customer software was distributed, or the affected package scope is still evolving.

What this means

Compromised code may execute during install, build, deployment, or production. It can steal environment secrets without changing your own repository.

Warning signs

  • A maintainer or registry reports a malicious version.
  • Lockfiles or artifact hashes change unexpectedly.
  • Build systems make unexplained network calls or access secrets.
  • New processes, files, or outbound traffic appear after an update.

Recover now

First 15 minutes

  1. Stop builds, deployments, and installs that can fetch the dependency.
  2. Identify affected versions, environments, install times, and reachable secrets.
  3. Preserve lockfiles, artifacts, caches, logs, and system evidence.
  4. Isolate affected builders and workloads.

Today

  1. Pin or remove the compromised component using official remediation guidance.
  2. Rebuild in a clean environment from trusted dependencies.
  3. Rotate credentials the component could access and inspect their provider logs.
  4. Notify downstream users if you distributed affected artifacts.

Verify recovery

  • Builds resolve only trusted versions and expected hashes.
  • Clean artifacts have known provenance.
  • Exposed credentials fail and logs show no ongoing use.
  • Affected customers have exact detection and upgrade guidance.

Prepare now

Access

  • Build dependencies cannot reach unnecessary production secrets.

Backups and evidence

  • Lockfiles, SBOMs, hashes, and released artifacts are retained.

Contacts and ownership

  • Critical dependencies have owners and security advisory monitoring.

Practice

  • A dependency can be blocked, replaced, and rebuilt from clean cache.

Common mistakes

  • Changing only the direct dependency while a transitive copy remains.
  • Reusing contaminated build caches.
  • Ignoring install-time code on developer machines.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.