Attestations

Why Attestations matter

Most organizations depend on thousands of software components they did not build. Vendors ship binary releases, cloud services rely on third party libraries, and internal systems are stitched together from open source. Yet when a vulnerability appears or an auditor asks for evidence of control, many teams discover the same uncomfortable truth: they do not actually know what they are running.

This gap is exactly what Software Bills of Materials (SBOMs) were designed to solve. An SBOM provides a machine readable list of all components inside a piece of software, together with metadata such as licenses, hashes, and dependency relationships. It is the software equivalent of an ingredient label.

Over the past few years SBOMs have moved from a niche idea to a mainstream requirement. Governments, regulators, and buyers increasingly expect transparency into the software they rely on. Suppliers that cannot provide it risk falling behind.

The shift in the market

Several forces are pushing organizations toward SBOM adoption.

Rising dependency risk
Modern software often contains hundreds of transitive dependencies. A single vulnerable library buried five layers deep can affect dozens of internal systems. Without SBOMs, you only discover exposure after the fact.

High profile supply chain incidents
Events like SolarWinds, Log4Shell, and the xz backdoor have made executives ask for visibility into their software supply chain. SBOMs give security teams the ability to answer those questions with facts instead of guesswork.

Pressure from customers and partners
Large buyers, especially in finance, critical infrastructure, and the public sector, now include SBOM requirements in tenders and vendor questionnaires. Demonstrating transparency is becoming a competitive advantage.

Maturity in tooling
Generating SBOMs used to be expensive and unreliable. Today most build systems, package managers, and security tools support SBOM generation out of the box. The cost barrier is low.

Regulatory momentum

Regulators worldwide are converging on the same idea: organizations must know what they are running, be able to prove it, and act quickly when risks change.

Examples include:

United States Executive Order 14028
Federal suppliers must provide SBOMs as part of software delivery.

EU Cyber Resilience Act (CRA)
Manufacturers must document components, vulnerabilities, and updates throughout the lifecycle of a product.

NIS2 and DORA
Operators of essential services and financial institutions must demonstrate supply chain risk management, including evidence of component visibility.

National cybersecurity centers
Across Europe and Asia, national agencies publish SBOM guidelines, encourage adoption, and increasingly expect suppliers to support it.

None of these frameworks mandate SBOMs in isolation. They require evidence. SBOMs provide the foundation for that evidence.

Why SBOMs alone are not enough

An SBOM answers a critical question: what is inside this software release?
But organizations often need more.

They need to know how the software was built, whether published vulnerabilities actually apply, and what suppliers are doing to remediate issues. This is where other types of attestations come in:

• Provenance shows how the software was created and by whom.
• VEX clarifies whether a CVE affects a product.
• VDR provides vendor guidance and timelines for remediation.

These documents extend the trust we place in the SBOM. They turn a static inventory into a living source of truth that can be used for policy enforcement, risk scoring, and compliance reporting.

Where SBOM Observer fits in

SBOM Observer is built around the idea that organizations need more than a file. They need a system that can ingest SBOMs, correlate them with other attestations, apply policies, and keep compliance up to date as new information arrives.

The core functions are simple:

• Upload SBOMs from internal builds or vendor deliveries.
• Automatically import provenance for supported ecosystems.
• Add VEX or VDR files from suppliers.
• Apply policies that evaluate evidence across all attestations.
• Produce reports and proofs for auditors and stakeholders.

SBOM Observer does not replace your development pipeline. It gives you the visibility and accountability expected by regulators, customers, and your own security team.

Getting started

You do not need to overhaul your entire development process to adopt SBOMs. Most organizations start with a few simple steps:

1. Generate SBOMs for your internally built software.
2. Request SBOMs from suppliers and vendors.
3. Track SBOMs centrally so you can search, compare, and respond to issues.
4. Add provenance, VEX, or VDR when available to build a stronger trust story.
5. Use the combined evidence for policy checks, vulnerability response, and compliance reports.

Want to see how these pieces come together in practice? Follow the SBOM Observer Quickstart for a guided tour.

The demand for transparency is only increasing. Organizations that invest in SBOMs today build a foundation that supports better security, faster incident response, and smoother regulatory compliance tomorrow.