Log4j, a ubiquitous event logger, was the first supply-chain vulnerability to break into IT’s collective consciousness (and nightmares). It won’t be the last. According to OWASP, the average software project includes nearly 70 dependencies, each a potential entry point for attackers.

Every added library expands an application’s attack surface, yet few organizations truly know what’s inside them. Dependencies don’t travel alone; they drag in their own hidden companions, and thus the vulnerabilities may be buried several layers deep in the software stack.

That’s where Bills of Materials (BOMs) come in.

What is a Bill of Materials?

A BOM is a list of the components that make up a system. Unlike a grocery list, it’s recursive, that is, if one of your components has its own ingredients, those are listed too.

These “Software Bills of Materials” (SBOMs) inventory not only your code but also every library, every package, and every piece of third-party software inside it.

But BOMs aren’t limited to software. The concept applies to hardware, services, and even machine learning models. Anything that touches the system and has a risk profile belongs in a BOM.

Today’s BOMs are standardized and machine-readable, which means actions against them can be automated. They can be scanned, compared against vulnerability databases, and exchanged across organizations using shared standards such as CycloneDX.

In 2021, The National Telecommunications and Information Administration (NTIA) and The National Institute of Standards and Technology (NIST) came together to define the minimum requirements for an SBOM. This expands SBOMs from an informal list of components to a comprehensive data structure for tracking component metadata and provenance.

How SBOMs Help Manage Risk

Now that we know what SBOMs are, we can focus on how they can be applied to solve real-world problems.

1. Supply chain risk — SBOMs let us see what’s under the hood, what third-party components are in use, who built them, and whether they’re known to be vulnerable.
2. Vulnerability response — Identifying a flaw is only the start. Good tooling highlights and ranks possible fixes, prioritizing the least disruptive remediation.
3. Incident forensics — If there’s a suspected tampering event or even just weird behavior in the system, you can compare what’s running now to what was supposed to be there and spot any discrepancies.

SBOMs in RABET-V

The RABET-V program is an independent verification and validation (IV&V) solution that uses industry-approved testing standards to help state agencies and technology providers understand the security, reliability, accessibility, and risks associated with technology products. The program began as a solution to verifying non-voting election technology, including electronic pollbooks, electronic ballot transmission solutions, election night reporting systems, voter registration systems, and more. Today, the program can verify any technology product with speed, efficiency, and flexibility.

One of RABET-V’s core assessments is Architecture, which asks, “How well-designed is the architecture that underlies the product?” Instead of disclosing source code, technology providers generate SBOMs and dependency graphs using automated tools specified by the program. After a computerized processing step, assessors review the evidence. This keeps the process transparent, repeatable, and non-invasive.

Here’s how it works in practice:

1. The technology provider generates an SBOM using automated scanning tools.
2. That SBOM is fed into a Software Composition Analysis (SCA) tool.
3. Component hashes are checked against vulnerability databases like NIST’s National Vulnerability Database (NVD).
4. Vulnerabilities are flagged, scored, and prioritized.

Where available, the tool suggests mitigation options, starting with the least disruptive.

Beyond Vulnerabilities: Quality and Ecosystem Health

Not every library is vulnerable today, but every library has a different security posture. A recent report found that nation-state actors have been weaponizing open-source software by introducing malicious code. Third-party components need extreme vetting before being adopted and continuous monitoring thereafter.

That’s why RABET-V also evaluates third-party libraries across several metrics:

• Contributors — How many people are maintaining the project? Are they experienced? Is there a diverse, active contributor base, or just one person burning out quietly in a GitHub repository?
• Popularity — Popular projects tend to have more eyes on them, more bug reports, and (hopefully) more community support.
• Security practices — Does the project respond to vulnerabilities? Are they publishing advisories and fixing issues quickly?

Other Types of BOMs

Once you see the value of SBOMs, it’s natural to ask: where else can we extend this concept? As the program evolves, RABET-V is looking to increase coverage to the following areas:

• Software as a Service (SaaS) BOMs map the cloud services, Application Programming Interfaces (APIs), and data flows that power modern applications. They show what services are in play, where data moves, and how third-party providers shape risk.
• Hardware BOMs (HBOMs) trace physical components down to chips and sub-assemblies, helping detect compromised hardware or untrusted suppliers.

Both are increasingly part of supply chain risk management — especially in critical sectors like elections, where provenance is just as essential as functionality.

The Bigger Picture

Bills of Materials provide a lens through which we can see complex systems clearly. They reveal what’s inside our code, services, and hardware, giving us a foundation for trust.

Verifying the security of all materials in a software and hardware solution is crucial for technology providers to protect the safety of their customers. In the RABET-V program, BOMs enable technology providers to strengthen their products, catch issues early, and build resilient systems that elections — and the public — can rely on. The RABET-V program is committed to providing continuous, up-to-date threat monitoring of BOMs for all verified products to increase transparency and awareness of a product's threat vectors.