Supply Chain Incident Response Playbook

What This Playbook Covers

Supply chain attacks are categorized under MITRE ATT&CK T1195 (Supply Chain Compromise), with sub-techniques for software (T1195.002), hardware (T1195.003), and code repositories (T1195.001)
This playbook covers three common supply chain scenarios: software dependency compromise, third-party vendor/data breach, and CI/CD pipeline backdoor
Supply chain incidents require a different response than direct breaches because the attacker’s initial access point is outside your control — you are detecting the downstream effect

Supply Chain Attack Types

Type	Attack Vector	Detection Challenge
Software dependency	Malicious package in npm, PyPI, Maven, or NuGet	Dependency scanning may not detect compromised packages
Vendor compromise	Attacker gains access through a trusted vendor/VPN/MSP	Traffic from the vendor looks legitimate (trusted IP, valid VPN)
CI/CD pipeline	Attacker backdoors the build pipeline to inject malicious code	The code passes all automated checks because it comes from the build system
Hardware/firmware	Compromised hardware or firmware at manufacturing	Extremely difficult to detect — no software signature

Phase 0: Determine the Supply Chain Attack Type (0-15 minutes)

Software Dependency Compromise Indicators

Indicator	Where to Check	What It Means
Unexpected network connections from build processes	Build logs, Sysmon Event 3 — unusual outbound connections from CI/CD runners	The compromised dependency is beaconing
New dependencies in lock file	`package-lock.json`, `requirements.txt`, `go.sum`	A dependency was swapped or added without a corresponding PR review
Anomalous code in build artifact	SAST, code review — unexpected code in the compiled output	The dependency injected code during the build
CVE for a direct or transitive dependency	Dependency scanning (Snyk, Dependabot, Trivy)	Known-vulnerable dependency — may already be exploited
Unexpected file writes during build	Build system logs — artifacts writing to unexpected paths	Malicious package modifying the build environment

SPL query — detect anomalous network connections from build servers:

index=endpoints EventCode=3
| search ComputerName IN ("build-server*", "jenkins*", "gitlab-runner*")
| stats values(DestinationIp) as DstIPs, values(DestinationPort) as DstPorts by ComputerName, SourceIp
| where mvcount(DstIPs) > 3 AND NOT DstIPs IN (known_build_registry_ips)
| eval alert = "HIGH — build server " . ComputerName . " connected to " . mvjoin(DstIPs, ",") . " outside known registries"

Vendor Compromise Indicators

Indicator	Where to Check	What It Means
Suspicious activity from vendor VPN	VPN logs — vendor connects at unusual times, from unusual IPs	Vendor credentials compromised
Anomalous vendor access to sensitive data	File audit, cloud logs — vendor accessing data outside their scope	Lateral movement within the vendor’s network
Vendor support ticket escalation	Ticketing system — vendor requesting privileges outside their scope	Social engineering via support channel
Unexpected vendor software update	Change management — vendor pushing an “emergency” patch	Attacker using vendor update mechanism as delivery vector
Zero-day in vendor product	CVE database, vendor advisory	The vendor’s software itself is compromised

SIEM detection — vendor VPN anomalous access:

index=vpn VendorName="*" AND ConnectionType="VPN"
| eval is_off_hours = if(date_wday == 0 OR date_wday == 6 OR (date_hour < 6 OR date_hour > 18), 1, 0)
| stats count by VendorName, AccountName, is_off_hours, SourceIP
| where is_off_hours == 1 AND SourceIP NOT IN (known_vendor_ips)
| eval alert = "MEDIUM — vendor " . VendorName . " account " . AccountName . " connected from new IP " . SourceIP . " during off-hours"
| table _time, VendorName, AccountName, SourceIP, alert

CI/CD Pipeline Compromise Indicators

Indicator	Where to Check	What It Means
Build process modification without PR	CI/CD audit logs — pipeline config changed without code review	Pipeline configuration attack
Unexpected build output change	Artifact hash comparison — output hash changed without source code change	Attacker modified the build output independently of source
CI/CD credential usage anomalies	Secret vault logs — CI/CD service account accessing unusual resources	Stolen CI/CD credentials
Pre-built binary in repository	Code review — committed binary files that should be built from source	Backdoor injected via binary artifact
Compromised maintainer account	GitHub/GitLab audit logs — maintainer account with anomalous activity	Attacker can push directly to the repository

Phase 1: Immediate Containment (15-30 minutes)

Critical Actions — Do These First

For software dependency compromise:

Pin the affected dependency version — lock the dependency to the last known good version
Stop the CI/CD pipeline — prevent further builds from using the compromised dependency
Block outbound connections from build servers — temporary network ACL to contain beaconing
Remove the malicious package — npm uninstall, pip uninstall, or go module removal
Scan the dependency tree — check for other packages from the same author or registry

For vendor compromise:

Disable the vendor’s VPN access — temporary revocation pending investigation
Disable vendor service accounts — revoke any service accounts or API keys the vendor uses
Review vendor access scope — determine what data, systems, and networks the vendor could reach
Change shared secrets — rotate any shared credentials, API keys, or certificates
Contact the vendor — inform the vendor’s security team of suspected compromise

For CI/CD pipeline compromise:

Freeze the pipeline — prevent all deployments, not just production
Rotate all CI/CD secrets — every API key, token, and password stored in the CI/CD system
Reset CI/CD credentials — change the CI/CD service account and access tokens
Review recent builds — compare build output hash with source code hash for every build in the compromise window

What NOT to Do

Action	Why It’s Dangerous
Continue builds from the same pipeline	Every build may produce compromised output
Assume only production is affected	If the pipeline is compromised, staging, test, and dev artifacts are also compromised
Roll back without verifying the previous build	The “last good build” may also have been compromised
Ignore transitive dependencies	The vulnerability may be in a dependency-of-a-dependency (indirect)

Phase 2: Evidence Preservation (30-60 minutes)

Evidence to Capture

Evidence	Method	Why Important
Build logs (90+ days)	CI/CD system logs — all pipeline runs, commit hashes, output artifacts	Timeline of when the compromised code was introduced
Dependency lock files	`package-lock.json`, `requirements.txt`, `go.sum` at every point in time	Shows when the malicious dependency was introduced
Vendor VPN logs (90+ days)	VPN logs showing all vendor connections	Timeline of vendor access — shows when the vendor was compromised
Artifact hashes	SHA256 hashes of all build artifacts in the compromise window	Compare with known-good hashes from registry
Repository audit logs	GitHub/GitLab push, PR, and merge audit	Shows who pushed code and when
Secrets usage logs	HashiCorp Vault, AWS Secrets Manager, Azure Key Vault usage logs	Determine which secrets were accessed by the compromised system

Phase 3: Investigation — Determine Blast Radius (1-4 hours)

Questions to Answer

Question	Evidence Source	How to Determine
When was the supply chain compromised?	Build logs, dependency lock file history, vendor VPN logs	First evidence of anomalous activity
What systems received the compromised code?	Deployment logs, release tags, build artifact distribution	Every system that ran code built during the compromise window
What data was accessed?	File audit logs, cloud logs, database query logs	Data accessed by processes running the compromised code
Is the attacker still active in the environment?	EDR alerts, network detection, authentication logs	Look for post-deployment C2, lateral movement, data access
Are there other organizations affected?	Vendor advisory, CISA alert, threat intelligence	Check if the same vendor/dependency is in the news or CISA alerts
Can we prove the scope?	All collected evidence	Document for legal, regulatory, and PR response

Phase 4: Recovery and Remediation

Action	Timeline	Owner
Remove compromised dependency	1-2 hours	Dev team
Rebuild all artifacts from clean state	2-4 hours	CI/CD team
Redeploy all services with clean builds	4-8 hours	DevOps
Rotate all secrets used by affected services	2-4 hours	Security team
Restore from known-good backup on any compromised systems	4-8 hours	IR team
Notify affected customers	Legal to determine	PR/Legal
Post-incident review	1-2 weeks	Engineering + Security

Long-Term Hardening

Control	What It Prevents	Implementation
Software Bill of Materials (SBOM)	Dependency-based supply chain visibility	Generate SBOM for every build: `cyclonedx-bom` or `syft`
Dependency pinning	Accidental malicious dependency upgrade	Pin all dependencies to specific versions in lock files
Package registry mirroring	Registry compromise	Run a private proxy registry (Sonatype Nexus, JFrog Artifactory)
Code signing	Compromised build artifact injection	Sign all builds with hardware-backed keys. Verify signature at deployment.
Vendor access reviews	Vendor credential compromise	Quarterly review of vendor access scope. JIT vendor access.
SLSA (Supply chain Levels for Software Artifacts)	Build integrity	Implement SLSA Level 2+ for all critical builds
Reproducible builds	Verification of build output	Build should produce identical output from identical source

Supply Chain Attack — detection and response for T1195 techniques
Zero Day & CVE Response — detection and response for T1588.006 techniques
Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
Container and Kubernetes Threats — detection and response for T1611, T1525, T1574.002 techniques
Incident Response — step-by-step incident response response procedures