Supply Chain Compromise Response Playbook: Responding to a Compromised Supplier or Component

When a trusted supplier, update or open source component turns out to be malicious, your normal defences have already let the attacker in, signed and approved. Supply chain compromises, MITRE ATT&CK T1195, reach you through software you chose to install and credentials you chose to share, so the response has to answer two questions fast: where is the bad component running, and what could it reach. This template gives [Organisation] a ready-to-adapt playbook with numbered steps, named roles, decision points and evidence to preserve. It is written for incident responders, platform and engineering leads, procurement and third-party risk teams, and the executives who must make shutdown and disclosure calls.

How to use this template

• Replace the placeholders: every [Organisation], [Role], [Tool] and [Timescale] value must be filled in before the playbook is approved. Leave none blank: an unnamed owner is the most common reason a step stalls.
• Attach it to your main plan: this is a scenario playbook that sits under the [Organisation] incident response plan. See the Incident Response Plan Template.
• Pick the right sibling playbook: use this one when the compromised thing is a product, update, package, library, container image or managed service provider that you run or depend on. Use the Vendor SaaS Breach Response Playbook when a SaaS provider holding your data or tokens is breached, and the CI/CD Pipeline Compromise Playbook when your own build system is the point of entry.
• Exercise it: run it at least once a year as a tabletop using a real past incident such as SolarWinds or XZ Utils. See the Tabletop Exercise Scenario Pack.
• Keep it aligned: the phases follow NIST SP 800-61 Rev. 3, which is a CSF 2.0 Community Profile, and the supplier coordination steps follow NIST SP 800-161 Rev. 1.

1. Scope and triggers

1.1 Scope. This playbook applies to any [Organisation] system, product or service affected by a compromise of a third-party supplier, software product, software update, open source dependency, development tool, container image, firmware or managed service provider.

1.2 Triggers. Invoke this playbook when any of the following occur:

• A supplier, CERT or government agency (for example a CISA alert or emergency directive) reports that a product or version [Organisation] uses is compromised.
• Threat intelligence or a security researcher publishes indicators for a malicious package, update or signed binary.
• [Organisation] detection finds a trusted, signed or vendor-installed process behaving unexpectedly, for example new outbound DNS domains, credential access or new accounts.
• A supplier with privileged remote access or stored [Organisation] credentials reports an intrusion (T1199 Trusted Relationship).
• A dependency scanner, SBOM tool or VEX feed reports a component flagged as malicious rather than merely vulnerable.

1.3 Severity. Classify using the table below. The incident commander may raise severity at any time.

2. Roles and contacts

2.1 Keep an out-of-band contact list (phone, Signal or a separate tenant) because a compromised management or collaboration tool may also expose your response channel.

2.2 Record supplier security contacts, contract notification clauses and escalation paths for every critical supplier in [Supplier register location] before an incident.

3. Detection and triage

1. Open the incident in [Ticketing tool] and assign the incident commander. Start a timeline log in UTC.
2. Collect the advisory facts (SOC lead): product, affected versions or hashes, indicators, first known malicious date, and whether a fixed or known-good version exists. Example: CISA's alert for CVE-2024-3094 named XZ Utils 5.6.0 and 5.6.1 and advised downgrading to an uncompromised version such as 5.4.6.
3. Find every instance (Asset and SBOM owner): query the SBOM repository, CMDB, EDR software inventory, container registries, artefact repositories and lock files for the component name, version range and hashes. Include developer laptops, build agents, golden images and backups.
4. Record VEX status for each [Organisation] product that ships the component: affected, not_affected (with a justification such as component_not_present or vulnerable_code_not_in_execute_path), fixed, or under_investigation. Publish statements to customers if [Organisation] is itself a supplier.
5. Size the blast radius: for each instance, list the identities, secrets, network paths and data the component could reach. Monitoring, identity and management tools usually hold the most privileged credentials.
6. Hunt for execution and activity (DFIR lead) from the first malicious date, not from the advisory date: new accounts or service principals, new OAuth grants or app credentials, unusual DNS and egress, token forgery, and use of credentials stored in the product.
7. Preserve evidence before changing anything where feasible: memory and disk images of affected hosts, the malicious package or binary with hash, signing certificate details, package manager and update logs, EDR telemetry, DNS and proxy logs, cloud audit logs and identity provider sign-in logs. Record chain of custody.

Decision point D1: declare and classify. Incident commander confirms severity from section 1.3. If the component is confirmed absent everywhere, record the evidence, set the VEX status and close as Low.

4. Containment

1. Stop further spread (Platform leads): block the malicious version in package proxies and artefact repositories, pin dependencies to the last known-good version, pause automatic updates for the affected product and disable auto-merge for dependency bots.
2. Isolate affected hosts: disconnect, or power down if imaging is not possible, and block external traffic to and from them. CISA Emergency Directive 21-01 for SolarWinds Orion took exactly this approach, with forensic imaging first for agencies able to do it.
3. Cut supplier access: suspend the supplier's remote access accounts, VPN, jump host and API integrations until they confirm containment.
4. Contain identities (Identity and NHI owner): disable or rotate credentials stored in or used by the component, revoke its tokens and sessions, and remove any accounts or app credentials the attacker created. If token-signing material may be exposed, treat this as an identity incident. See the Identity Incident Response Playbook.
5. Raise detection: deploy supplier and community IoCs to EDR, SIEM and DNS blocking, and add watchlists for the component's service accounts.

Decision point D2: shut down or keep running? The incident commander and executive sponsor decide. Keep running only with compensating controls (egress blocked, credentials rotated, enhanced monitoring) when the business impact of shutdown is greater than the risk, and record who accepted the residual risk. For critical components with evidence of attacker activity, isolation is the default.

5. Eradication

1. Remove the malicious component and replace it with a version the supplier confirms as clean, verified by hash, signature and, where available, provenance attestation.
2. Rebuild, do not clean, hosts where the malicious code ran with privilege. Rebuild from trusted images and media, not from backups taken during the exposure window.
3. Remove persistence: attacker-created users, service principals, OAuth apps, federation trusts, scheduled tasks, SSH keys and CI secrets.
4. Rotate everything reachable: all credentials used by or stored in the product, plus secrets on hosts it managed. In Active Directory environments where domain credentials were exposed, ED 21-01 also called for resetting the KRBTGT password twice.
5. Revoke trust in compromised signing material: remove the supplier certificate or key from allow lists if the supplier's signing was abused (T1553.002 Code Signing), and accept only re-signed releases.

Decision point D3: clean enough to restore? DFIR lead confirms no active indicators for [e.g. 72 hours] of enhanced monitoring, persistence removed and credential rotation complete.

6. Recovery

1. Restore services in priority order from [Business impact analysis], starting with identity and security tooling.
2. Re-enable supplier access with reduced scope, short-lived credentials and logging of every session.
3. Resume updates for the product only after the supplier explains the root cause and what changed in its build and release process.
4. Keep enhanced monitoring for [e.g. 30 to 90 days]; supply chain attackers often return through credentials stolen during the window.
5. Update SBOMs, VEX statements, the CMDB and the supplier risk rating.

7. Communication and notification

Decision point D4: external disclosure. Executive sponsor approves on Legal's advice. Do not name or blame the supplier publicly before facts are confirmed, and keep statements consistent with what the supplier has published.

8. Post-incident review

1. Hold the review within [e.g. 10 business days] of closure with all roles and, where possible, the supplier.
2. Produce a timeline: first malicious date, advisory date, detection, containment, eradication and recovery times.
3. Ask: could we answer "where is it?" within an hour? Which credentials did the component hold that it did not need? Did contract terms give us the notification and evidence we needed?
4. Feed findings into supplier risk ratings, procurement requirements, SBOM coverage targets and this playbook. Record changes in the version history below.

Implementation guidance

Prepare before you need it

• SBOM coverage: generate SBOMs for every build and collect them from suppliers, stored in a searchable repository. See the SBOM Guide.
• VEX handling: adopt a VEX format (CSAF VEX or OpenVEX) so not_affected decisions carry a justification and can be shared at scale.
• Contract clauses: require supplier breach notification within a fixed period, IoC sharing and cooperation with investigations (NIST SP 800-53 SR-8 Notification Agreements).
• Least privilege for supplier software: inventory the service accounts and secrets every supplier product holds. A monitoring tool with domain admin rights turns a supplier breach into a domain compromise. See the Software Supply Chain Security Guide.
• Package controls: route dependencies through an internal proxy that can block versions centrally, with a minimum package age before adoption.

Small vs large organisations

A small organisation can merge roles (one person as incident commander and supplier owner) and rely on an incident response retainer for forensics, but must still name owners for identity rotation and supplier contact. Large organisations should pre-assign platform leads per business unit and automate the "where is it?" query across SBOM, EDR and registries, because manual searches across thousands of repositories take days.

Framework mapping

Measuring readiness

• Time to locate: minutes from advisory to a complete list of affected instances (target: [under 1 hour]).
• Time to contain: from declaration to malicious version blocked and hosts isolated.
• Credential rotation completeness: percentage of credentials reachable by the component rotated within [Timescale].
• SBOM coverage: percentage of production applications and critical supplier products with a current SBOM.
• Contract coverage: percentage of critical suppliers with notification and IoC-sharing clauses.

Common failure patterns

• Scoping from the advisory date: the hunt window must start at the first malicious release. In the SolarWinds compromise, trojanised updates had been distributed for months before disclosure.
• Removing the package but not rotating: credentials stolen during the window stay valid. The Codecov breach harvested CI secrets that had to be rotated by every affected customer.
• Trusting the maintainer by default: a long-standing maintainer identity introduced the XZ Utils backdoor, so reputation is not a containment control.
• Forgetting non-production: developer laptops, build agents and golden images keep the malicious version and reinfect production.
• Waiting for the supplier: containment of your own access paths and credentials should not depend on the supplier's investigation.

Version history

[Organisation] playbook version [1.0], approved by [Role] on [Date], next review [Date].

Standards and references

• NIST: SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA: Emergency Directive 21-01, Mitigate SolarWinds Orion Code Compromise
• CISA: Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094
• MITRE ATT&CK: T1195 Supply Chain Compromise
• OpenVEX: Specification
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · CI/CD Pipeline Compromise Playbook · Vendor SaaS Breach Response Playbook · NIST SP 800-161 Cyber Supply Chain Risk Management Guide · Top 10 Supply Chain Attacks