Supply Chain Attack Response Quickstart

Pull the vendor advisory and record the exact affected product name, affected version range, published IoCs (file hashes, C2 domains, C2 IPs, certificate thumbprints), and earliest known malicious release timestamp. If the advisory is incomplete, request private IoC sharing through an ISAC or trusted vendor channel under NDA. Do not wait for a public disclosure to begin scoping.

Run a first-pass sweep across the estate for vendor-published hashes and C2 indicators. Focus on the fastest-return sources first: EDR file-event index for hashes, proxy and firewall logs for outbound C2 domains and IPs, DNS logs for resolution hits. The goal at this stage is breadth, not depth -- confirm whether you have any hits before investing in deeper scoping.

Convene a bridge with security, platform/SRE, application engineering, vendor management, and legal. Designate a single scope lead and establish a single affected-asset inventory; avoid parallel team-by-team lists that diverge over the next hours. Publish the vendor-advisory version being followed so everyone tracks the same source.

Query SBOMs (Syft, Trivy output) and package-manager manifests across build systems and runtime hosts for the affected package and version range. Query internal artifact registries (JFrog, Nexus, internal PyPI/npm mirrors, ECR/GCR/ACR) for download counts and upload timestamps of the affected package. Produce a first-pass affected-asset list within this step.

A package present in node_modules or in a Docker image layer does not necessarily mean the malicious payload ran. Query EDR process-creation events for the malicious hashes (not only file events) to identify hosts where the payload actually executed. Query outbound network events for C2 contact to identify hosts that the payload reached out from. These three cohorts have very different response requirements.

Freeze CI/CD pipelines that could redeploy infected containers or re-install the compromised package version: disable auto-deploy on affected repositories, add a temporary admission check that rejects images built from the malicious release window, and block the malicious versions in internal package registries with deny rules.

Pin a verified safe version in package manifests and lockfiles across affected services. Sequence rollback: customer-facing production first, internal production second, non-production last. Coordinate with SRE on blast radius; a panicked rollback to an older vulnerable version makes the incident worse. Track rollback status in a live dashboard, not in a chat thread.

Before removing the malicious artifact from hosts and registries, copy the binary, its config, and any dropped persistence artifacts to a chain-of-custody evidence store with hashes. Do not silently delete the malicious artifact from internal registries; mark it blocked and preserve a forensic copy. Analysis starts from this preserved copy, not from a re-download.