Why SBOMs Alone Couldn’t Scope a Shai-Hulud Supply-Chain Incident

Summary

At an ISC2 session, an Atlassian security manager described how an outdated SBOM and hidden transitive dependency hindered response to a Shai-Hulud compromise, and urged teams to prioritize runtime visibility and incident-scoping capabilities.

Key points

The presenter described a real-world SaaS compromise but said identifying details, figures, and event sequence had been altered.
A malicious Shai-Hulud dependency was hidden three layers deep, so it did not appear in a top-level dependency audit.
A behavioral scanner flagged suspicious execution, but responders initially discounted the alert; the SBOM was two development sprints out of date.
Responders could not reliably identify affected services or the compromise’s potential reach, and manually correlated logs across more than 400 services.
The presenter recommended keeping deployed SBOMs under 72 hours old, enabling rapid detection of unknown module loads, and checking registries for lookalike package names; these were targets to calibrate, not universal benchmarks.
Researchers later attributed at least some subsequent Shai-Hulud attacks to TeamPCP; the presenter advised focusing detection on the worm’s operational behavior rather than attacker identity.

Article Details

Defense Focus: Scope and contain software supply-chain incidents using current production runtime evidence rather than relying on SBOMs and dependency inventories alone.
Detection Methods: Use behavioral scanning to flag packages performing unexpected actions.
Detect unknown module loads at runtime, with a recommended target of under 90 seconds.
Check package registries daily for lookalikes of internal package names, with a recommended detection target within 24 hours of publication.
Correlate runtime evidence and service logs to determine which code executed, what it could access, and which services may be affected.
Data Sources: Runtime telemetry, including module-load events and evidence of code execution
Service and application logs
Deployed SBOMs and dependency inventories
Package registry records, including maintainer history, publisher identities, and package names
Defensive Actions: Keep deployed SBOMs under 72 hours old; Kanjani recommended aiming for more than 98% of production services to meet that threshold, while noting that organizations should calibrate the targets to their environments.
Prioritize establishing what ran in production, what it could access, and which services were affected; do not treat a clean or stale SBOM as proof that an environment is unaffected.
Base detection on operational behaviors the worm needs to function rather than on potentially rotating attacker identity signals.
Communicate incident details directly and unambiguously, using language appropriate to the audience.