threat intelligence

Blind Spots in the Build: A Supply Chain & SBOM Security Primer

Understand the growing threat of software supply chain compromises and learn how leveraging a Software Bill of Materials (SBOM) alongside Build Provenance can remove vulnerability blind spots and secure applications.

Pulsedive Threat Research

16 Jul 2026 • 13 min read

Supply chain compromises are becoming more commonplace and serve as a valuable avenue for access to victim environments. The large blast radius offered is particularly enticing to threat actors. The reason for the growth in supply chain compromises: modern software and applications are seldom built in a vacuum but rather rely on hundreds of dependencies. These dependencies include open-source and 3rd-party code or libraries, many of which have their own dependencies. As such, a single application can have dependencies that neither the developers nor the users are aware of. When one of these libraries or components is compromised, any applications that use it are vulnerable. A Software Bill of Materials (SBOM) is one way to mitigate the threat posed by supply chain compromises. SBOMs are lists of the components that make up a software system.

This blog will cover what an SBOM is, discuss example supply chain compromises, and outline defenses that organizations can implement. Also discussed are the legislation that will assist organizations in accessing SBOMs and the advent of SBOMs for AI models. Before considering mitigations or defensive recommendations, organizations must know where the threat or vulnerability resides. This is only possible through an accurate SBOM.

What is an SBOM?

An SBOM is a list of components that make up an application or software, similar to the ingredients list on the back of food packaging. The goal is to highlight what components, libraries, or applications make up the software. This is done so that teams can query an SBOM to determine whether a vulnerable component is used in an environment, rather than relying on assumptions. While there is no limit to the information an SBOM can contain, the following fields are the minimum set out in CISA's draft document, "2025 Minimum Elements for a Software Bill of Materials (SBOM)".

Minimum Elements of an SBOM. Source: CISA

In addition to the minimum fields, CISA recommends certain processes that organizations should consider for managing SBOMs. These are:

Frequency: Each software version or update should have its own SBOM. When a new version of an application is used, the SBOM should be updated to reflect the changes to the software.
Coverage: The SBOM should list all the components that make up the software. This includes all dependencies of the libraries used in the software.
Known Unknowns: Any unknowns need to be defined in the SBOM explicitly
Distribution & Delivery: SBOMs should be accessible to the business units or groups that need them.
Updates to the SBOM Data: A process needs to be in place to correct errors.

SBOM practices and processes that organizations should follow. Source: CISA

An example of an SBOM created using the CycloneDX standard is shown below. More details about the standard are available here.

Example of an SBOM in CycloneDX format. Source: GitHub

Combining SBOMs with Exploitation Intelligence

An SBOM simply lists the components that make up an application. While useful for identifying whether a component is vulnerable, an SBOM itself does not indicate whether a vulnerability affects the finished application. For example, a vulnerable library that is never called should be treated as a lower-priority mitigation target than a library that is executed by an application. A Vulnerability Exploitability eXchange document tracks which vulnerabilities pose a risk and enables teams to make more informed prioritization decisions.

The following elements are considered the minimum requirements for Vulnerability Exploitability eXchange according to CISA.

Minimum Requirements for Vulnerability Exploitability eXchange (VEX). Source: GitHub

The flow below shows how the status value changes as more information becomes available. Once a vulnerability is disclosed, the status changes to "Under Investigation" as security teams assess its impact. Once the investigation is complete, if the component is impacted, it is shifted to "Affected". Once fixes are released, a new VEX statement is issued with a new statement version and updated modification timestamp. The status is then changed to "Fixed", with details about the fixes provided.

VEX status flow and how the different status stages interact. Source: CRA Evidence

Product and Vulnerability Details. Source: GitHub

Example of a VEX document where the application is not affected by Log4Shell. Source: GitHub

Example of a VEX document where the application is affected by Log4Shell. Source: GitHub

Examples of Supply Chain Compromises

NPM Compromises - Shai Hulud

NPM and Python packages have become recurring case studies on just how dangerous package compromise can be. Two compromise campaigns associated with the Shai-Hulud worm from late last year demonstrate the scale of the blast radius.

September 2025: Two Compromises, Same Registry

Compromise 1: The first compromise reported around September 8, 2025, targeted widely used packages, including chalk and debug, each of which is downloaded over 250 million times a week. Initial access to the packages was achieved when a maintainer was phished through an email impersonating an npm security notice, sent from a domain the attacker had registered just days earlier.

Once account takeover was accomplished, the attacker published trojanized versions of the maintainer's packages. The injected code was a cryptocurrency clipper: it hooked into functions such as fetch and XMLHttpRequest, as well as wallet APIs, to intercept transactions and replace the destination wallet address with one of several attacker-controlled addresses hardcoded in the file, covering Bitcoin, Bitcoin Cash, Litecoin, TRON, and Solana.

Compromise 2: The second, larger compromise, active around roughly September 15–16, 2025, introduced the Shai-Hulud worm, built to steal credentials rather than crypto. Once running inside a compromised package, it deployed the open-source secret-scanning tool TruffleHog to sweep the environment for GitHub tokens; Azure, AWS, and GCP credentials; cloud metadata endpoints; and npm authentication tokens. Collected secrets were staged and exfiltrated through a GitHub Actions workflow embedded directly in the malicious file, which posted the harvested data to a webhook[.]site endpoint.

The malware converted private repositories to public and tagged them with the description "Shai-Hulud Migration" Propagation was fully automated: the worm queried the npm registry for every package owned by the compromised maintainer, wrote its payload into each one, and republished it. GitHub removed more than 500 compromised packages from the registry in response, and npm began blocking new uploads that matched known indicators of compromise.

In response to these compromises, GitHub initiated several measures to reduce the impact of compromised maintainer accounts. Measures include requiring phishing-resistant MFA solutions for local publishing, reducing token lifetimes to seven days, and OIDC-based Trusted Publishing to reduce reliance on longer tokens.

To read more, including an analysis of the malware, check out our previous deep dive into these compromises.

November 2025: The Return

Second Wave: A second campaign that leveraged the Shai-Hulud worm was identified on November 24, 2025, and compromised popular packages, including those maintained by organizations including Zapier, ENS Domains, PostHog, and Postman. This campaign disguised itself as tooling for the Bun JavaScript runtime, shipping two files:

setup_bun.js, which impersonated legitimate Bun setup code.
A roughly 10 MB obfuscated payload named bun_environment.js is used for credential harvesting.

The malware added a GitHub workflow file that could execute commands by opening a GitHub discussion, collect system and cloud credentials from AWS, GCP, and Azure, and exfiltrate them to a newly created public repository with the description "Sha1-Hulud: The Second Coming." Within a day, close to 22,600 GitHub repositories bore that description. Propagation was via an automated updatePackage() routine: once the worm located a valid npm token, it fetched up to 100 packages owned by that maintainer, inserted the malicious files, added a preinstall script to each package's manifest, increased the patch version, and republished them.

This version also introduced a destructive fallback: if the worm couldn't locate a GitHub or npm token to steal, it attempted to erase evidence and deny recovery instead. On Windows, it used cmd.exe to delete the contents of the user's profile directory and then ran cipher /w to overwrite the freed disk space. On Linux and macOS, it located the user's writable files, overwrote them with the shred command, and deleted the resulting empty directories.

Read more about the second Shai-Hulud campaign in our blog Return of Shai-Hulud: The “Second Coming” of the NPM Supply Chain Compromise.

Log4Shell (CVE-2021-44228)

Disclosed on December 9th, 2021, Log4Shell (CVE-2021-44228) is one of the more memorable recent supply chain vulnerabilities with widespread industry impact. This was a critical remote code execution vulnerability in Apache Log4J, a Java logging library utility used by many applications. Threat actors exploited this vulnerability to get the vulnerable software or system to download and execute malicious payloads. A blog post from Qualys reported that 1 million exploitation attempts were observed in the 72 hours following the disclosure of the Log4Shell vulnerability. Moreover, 98 distinct Log4j2 versions were identified as in use, with 55% of them vulnerable. Security firm Arctic Wolf noted that the vulnerability was widely exploited in ransomware intrusions, with 60% of Log4Shell incident response cases attributed to three groups: LockBit, Conti, and ALPHV/BlackCat.

A major reason Log4Shell is so widely discussed is that it revealed how little information organizations had about the software they were running. Some organizations were unaware that they were even using Log4J, as it was a transitive dependency for a library used in 3rd-party products, applications, and services. Without concrete information about what libraries were being used inside an organization, security teams were forced to manually check applications to determine if Log4J was present. This delayed patching and remediation efforts, as there wasn’t a generic patch that could be applied to every vulnerable instance; rather, organizations needed to release new software versions that included the patched version of Log4j.

Example of a request that contains a base64-encoded command in the JNDI lookup. Source: Palo Alto Networks

Teams with SBOMs had a clear advantage. They were able to quickly query SBOMs to determine whether Log4J was listed as a dependency and generate a list of potentially vulnerable applications that needed patching. An SBOM coupled with a VEX would have been the gold standard for defenders, providing a prioritized list of applications to patch. In the aftermath of CVE-2021-44228, guidance from many security experts included generating SBOMs for applications.

A list of applications that may be vulnerable to Log4Shell. Source: GitHub

Defending Against Supply-Chain Compromises

Software Bill of Materials

As supply chain compromises become increasingly common, defenders need to adapt. The first thing organizations should do is invest in SBOMs and VEX lists for applications. This will reduce the time taken to respond to supply chain compromises. SBOMs and VEXs have shown their value time and again by clearly highlighting which software components may be vulnerable and require patching.

💡

GitHub allows developers to export an SBOM for repositories using the dependency graph.

💡

Similarly, Amazon Inspector can generate an SBOM for supported AWS resources.

Build Provenance

Another solution to help mitigate supply chain compromises is Build Provenance. Build Provenance comprises comprehensive metadata describing how a component or artifact was built. This includes authenticated documentation that captures the history of how software components were created.

The Supply-chain Levels for Software Artifacts (SLSA) is a security framework that focuses on answers:

Can you prove what built the software?
Can you prove what source it originated from?

The build track of SLSA focuses on the provenance of an artifact and consists of four levels:

Summary of the different Build Levels. Source: SLSA

Build L0

This level does not provide provenance of how the software was built.

Build L1

This level consists of Provenance only and describes how the package was built. The build process may be fully scripted or automated. While provenance at Level 1 does not protect against tampering, it can help with vulnerability management.

Build L2

Level 2 requires the use of version control and a hosted build service that generates authenticated provenance. At this level, the provenance prevents tampering, as a trusted build service generates it.

Build L3

At Level 3, the source and build platforms meet specific standards to guarantee the auditability of the source and integrity of the provenance.

SLSA also specifies a fifth build level, called L4. Level 4 requires a two-person review of any change and a reproducible build process. This process is the most cost-effective and can also be used to identify unauthorized changes.

Charting the Way Forward

Regulations to the Rescue

While SBOMs have been shown to provide value, creating and maintaining them can be tedious. Organizations often start from the group up and can quickly be overwhelmed when trying to identify transitive dependencies. Organizations can take solace in the fact that government regulations may come to reduce this burden.

Legislation in both the U.S. and Europe mandates organizations to maintain SBOMs. Executive Order 14028, issued by the Biden administration, requires any software vendors that sell to the US government to provide an SBOM for their products. Additionally, the European Union’s Cyber Resilience Act (CRA) is a regulation that establishes mandatory standards for products, both hardware and software, and requires manufacturers to maintain an SBOM. As a result, organizations may now have access to SBOMs for the applications they use, which can be used to expand or augment knowledge about those applications.

SBOM for AI

In addition to traditional software-focused SBOMs, CISA and G7 partners have released guidance on Software Bill of Materials for AI. This guidance is similar to that one CISA published on the minimum elements of an SBOM, with a focus on AI systems. AI systems contain several components that do not fall under the minimum elements of an SBOM. These components include data models and training data. As such, new guidance is needed to ensure an accurate inventory of AI models is maintained.

The AI-SBOM is split into 7 components:

Metadata
- Author
- Version
- Data format
- Timestamp
System Level Properties
- Software dependencies
- How components interact
Models
- Name
- Identifier
- Version
- Producer
- Input/Output Properties
- License
Dataset Properties
- Content
- Identifier
- Hash
Infrastructure
- The infrastructure that the models run on
  - Can also link to a Hardware Bill of Materials
Security Properties
- Security controls
- Compliance information
Key Performance Indicators
- Performance and security metrics for the system

Conclusion

Going back to supply chain compromises, we need to answer two key questions: What was built and who built it? SBOMs can help us answer the first one. With accurate component inventories, organizations can determine what an application is made of. Provence and Build Integrity help us answer the second question: who built it? This becomes vital for identifying unauthorized changes to packages and libraries. By coupling the visibility SBOMs provide with the verifiable integrity of Build Provenance, organizations can remove blind spots in their software supply chain and achieve faster, more proactive vulnerability management.