supply chain compromise — methodology

what evidence exists and how fast it dies

the first 10 minutes

1. halt auto-deploy and customer-facing download of the suspect release tag — manual gate only.
2. sha-256 hash the suspicious binary and copy it offline before quarantine or registry GC deletes it.
3. pull artifact registry exports for the affected version range — include prior known-good build for diff.
4. export CI job logs for the build that produced the release — full stdout, env snapshot if available.
5. clone or archive git state for build-agent and release repos — do not pull on the compromised runner.
6. preserve SBOM, lockfile, and dependency manifest pinned to the release tag.
7. capture code signing certificate chain and timestamp token from the signed artifact.
8. pull MFT csv or recursive file listing from deploy staging and build-agent output dirs.
9. isolate the build agent host — snapshot memory if the runner is still live.
10. begin the path below.

the path

1. 1. yara scanner

   custom rules from your threat hunt plus the suspicious binary. write or paste rules for backdoor strings, injection API imports, and actor-specific markers — scan the release artifact and build-agent drop paths.why first: supply-chain poison often hides behind a valid signature. string and byte rules catch what reputation feeds miss on day zero.

2. 2. yara rule scanner

   same binaries against built-in rule packs plus your org rules. confirms matches across poisoned updater, build-agent staging dir, and any sibling releases in the inventory.why second: a second rule engine pass with different built-ins catches gaps before you deep-dive PE headers.

3. 3. pe analyzer

   drop poisoned and known-good PE side by side. sections, imports, exports, entropy per section, packer hints, imphash preview.why third: you need a baseline diff — same product version with different import tables is the supply-chain tell.

4. 4. pe static analyzer

   deeper static pass on the suspicious .exe / .dll. suspicious API categories, section anomalies, packer fingerprint, export report for handoff.why fourth: static flags (process injection, credential access imports) survive even when the binary is signed.

5. 5. PE compile timestamp vs filesystem timestamp conflict detector

   MFT csv or file listing with PE headers from the deploy path and artifact store. surfaces compile-time after filesystem create, impossible clusters, timestomp indicators.why fifth: actors timestomp poisoned builds to look like last month's release — compile vs SI/FN conflict is hard to fake.

6. 6. imphash calculator

   import hash on poisoned binary vs baseline and any historical builds you preserved. list imports for pivoting to other compromised artifacts.why sixth: imphash clusters poisoned builds even when file hash and version string differ — good for scope across customers.

7. 7. binary compiler and language identifier

   PE/ELF from build output. identifies compiler, language runtime strings, version metadata — compare poisoned release to prior clean toolchain fingerprint.why seventh: a release compiled with a different toolchain than your CI image is evidence the build agent or compiler slot was swapped.

8. 8. source code style forensic fingerprinter

   trojanized build-agent source vs vendor baseline or last-known-good commit. indentation, naming, comment density, API usage stylometry.why last: when the binary is signed and timestomped, source diff may be the only proof the repo was touched — not a dependency typo.

common false leads

• valid code signature means the binary is clean — stolen keys, compromised build agents, and post-sign tamper all produce legitimate signatures on poisoned output.
• same version string means same build — semver can be reused; compare imphash and compile metadata, not labels alone.
• compile timestamp predates the incident — PE compile time is attacker-controlled and commonly timestomped.
• clean VirusTotal on release day — supply-chain samples are novel; reputation lags hours to days.
• npm audit / dependency scan passed — typosquat and build-time injection are different failure modes than known CVEs in lockfiles.
• only the updater binary matters — trojanized build-agent source poisons every downstream artifact from that runner.

what we can tell you, what we can't

we can tell you:

• YARA matches on backdoor strings and suspicious API import patterns in release binaries
• PE static anomalies — section entropy, import table drift vs known-good baseline
• compile timestamp vs filesystem timestamp conflicts indicating timestomping
• imphash clustering across poisoned builds for scope enumeration
• compiler and language fingerprint drift vs your expected CI toolchain
• source stylometry divergence between trojanized and baseline build-agent code

we can't tell you:

• who compromised the pipeline without your CI logs, identity exports, and vendor telemetry
• whether customers were exploited — that requires their endpoint and network evidence
• live CVE correlation against NVD without your SBOM export in scope
• revoke trust in a code signing certificate — CA and vendor process
• attribution to a named threat actor — intel and law enforcement territory

handing it off

• platform / devsecops: affected version range, imphash list, YARA rules that fired, CI job ids, blocked release tag, clean rebuild hash.
• customers / downstream: ioc list (file hash, imphash, cert thumbprint), replacement build version, detection guidance — coordinate timing with counsel.
• code signing CA: certificate chain export, evidence of key misuse if build signing key was exfiltrated from the agent.
• CISA / CERT: signed artifact sha-256, build timeline, scope of distributed releases.
• outside counsel: preservation log — what you hashed, when, chain of custody on binary copies and git archives.

further reading

• CISA · secure software development framework (SSDF)
• NIST SP 800-218 (SSDF)
• MITRE ATT&CK · supply chain compromise
• SLSA · supply-chain levels for software artifacts
• ENISA · threat landscape for supply chain attacks

reference investigation