SBOMs Alone Can’t Reveal the Scope of a Supply Chain Attack

A recent Shai-Hulud attack shows defenders need real-time visibility into production code and affected services to respond to supply chain compromises.

ISC2 Strategic Congress 2026 — Denver — Depending on a software bill of materials (SBOM) to determine what happens when a malicious package slips past security checks can leave defenders struggling to establish what code actually executed, which systems it touched, and how far the compromise spread.

In a session at the ISC2 Security Congress 2026 this week, Atlassian product security manager Deepam Kanjani used a real-world compromise involving the Shai-Hulud worm to highlight incident response challenges, including gaps in runtime visibility, transitive dependency ownership, and attacker attribution.

A War-Room View of a Shai-Hulud Attack

In the session, Kanjani said he had altered all identifying details, figures, and the sequence of events to protect confidentiality though his first-person, war-room narrative of underlying attack techniques, technical behaviors and challenges were based on real events at a large-scale software-as-a-service (SaaS) environment.

Kanjani described the incident as involving a package that appeared legitimate, with a matching SHA hash, more than 3,400 GitHub stars, and a repository that looked credible to the company’s security tooling. But hidden three layers deep in the package was a malicious transitive dependency named shai-hulud, after the giant sandworms in the Dune movie series. Because it was not a direct dependency, it did not surface in a top-level dependency audit.

The first inkling that something was wrong came when a behavioral scanner flagged the package as running something it shouldn’t have been running. Incident responders initially dismissed the alert as a likely false positive because the hash matched and there was no other obvious indication of the package being malicious.

Additionally, the SBOM reported the environment as clean when the security team consulted it. What they did not realize at the time was that the SBOM was two development sprints out of date, Kanjani said.

As the response unfolded, the team could not say with confidence which services used the package. Indicators of compromise (IOCs) provided initial clues but could not establish which services were affected or how far the compromise had spread. Responders needed runtime evidence to determine what code had actually executed and what it could access.

Without that runtime telemetry, they had to correlate logs manually across more than 400 services, leaving them without a reliable picture of the compromise’s potential reach. An initial Slack message from the incident response handler to enterprise stakeholders made matters worse by being too vague and prompting a set of parallel investigations into the still unfolding event.

The security team’s efforts to identify the attacker by tracing registry ownership, npm maintainer history, publisher identities, and GitHub records quickly led them to dead ends. The repository had been copied from a legitimate project and the publisher’s identity and account history appeared to have been fabricated, Kanjani said.

Researchers subsequently have attributed at least some of the later Shai-Hulud attacks to a threat actor tracked as TeamPCP.

Lessons for Incident Responders

The key takeaway, according to Kanjani, is that organizations need to look beyond SBOMs and dependency inventories and instead base incident response around what actually runs in production. The focus should be to equip security teams to identify, scope, prioritize, and contain incidents and enabling real-time visibility into affected services and the potential scope of a compromise.

“You are triaging a runtime graph. Not a dependency file. Your tools must reflect that,” he said.

Kanjani recommended that organizations keep deployed SBOMs under 72 hours old and try to ensure that more than 98% of production services meet that threshold. He also recommended enabling runtime capabilities to detect unknown module loads in under 90 seconds and daily registry checks to detect lookalikes of internal package names within 24 hours of publication.

Kanjani described these as targets that organizations should calibrate for their own environments rather than as universal benchmarks. In addition, security teams should focus on the operation rather than the operator, Kanjani said. “Identity signals rotate. Operational necessities don’t. Build detection around what the worm must do to function — not who’s driving it.”

All communications with stakeholders regarding a security incident also needs to be direct and unambiguous. The key is to be honest, he said, while making sure to present the details in language appropriate for the intended audience.

“Don’t bullsh-t. Tell them the reality in a way they can absorb it,” he said. “You don’t want to sell panic.”