Skip to content

CONCEPT Cited by 2 sources

Supply-chain attack response

Definition

The operational playbook for responding to a compromise that entered through a dependency or build-system supply chain rather than through direct exploitation of the organization's own code. Distinct from a standard incident response because the initial attack vector is trusted code from an upstream dependency — meaning the blast radius is defined by what that dependency has access to (runners, credentials, registries) rather than what's externally exposed.

Canonical phases

Based on the Grafana TanStack incident (2026) and the Datadog IAC-scanner incident:

  1. Detect — often delayed because the compromised code runs within a trusted CI context. Grafana: ~5 days from first exploit to detection (Source: sources/2026-06-24-grafana-post-incident-review-tanstack-npm-supply-chain-ransom).
  2. Contain — suspend all applications/integrations that may have been exposed; initiate credential rotation.
  3. Freeze — halt code merges and deployments to prevent further propagation (concepts/global-code-freeze).
  4. Audit — exhaustive review: every commit, every application permission, every accessible secret.
  5. Harden — structural remediation to eliminate the class of vulnerability (token brokers, org compartmentalization, scoped Actions).
  6. Verify — independent audit (e.g., Mandiant) to corroborate internal findings.
  7. Thaw — gradual unfreeze, gated on per-repo completion of hardening measures.

Key insight: incomplete rotation is worse than no rotation

Grafana rotated credentials on Day 0 but missed one. The overlooked credential was exploited 5 days later for full repo exfiltration. The lesson: credential inventorying is harder than credential rotation mechanics (Source: sources/2026-06-24-grafana-post-incident-review-tanstack-npm-supply-chain-ransom).

Seen in

Last updated · 559 distilled / 1,651 read