Imagine walking into a grocery store and picking up a can of soup. Before it goes into your cart, you read the ingredient label. You expect to know exactly what's inside, where it came from, and that the manufacturer has verified its quality.
Now imagine that same label listed:
🥫 Soup
Most consumers wouldn't buy it.
We expect complete transparency about the food we consume. Unknown ingredients introduce unnecessary risk. The same expectation should apply to software.
Modern applications aren't written from scratch. They're assembled from open source, third-party libraries, proprietary code, containers, AI-generated code, APIs, and increasingly, AI agents.
Those components bring their own dependencies, creating software supply chains that routinely stretch more than 20 levels deep and span over 100 programming languages.
Every dependency becomes another ingredient in your application. But an ingredient label tells you what's inside your food. It doesn't tell you whether the ingredients are authentic.
The challenge isn't understanding that software has ingredients. It's knowing whether every one of those ingredients can be trusted.
Lineaje research found that 6.96% of open-source components are of unknown or dubious origin. That means nearly 1 in every 14 open-source components cannot be confidently verified.
That doesn't mean those components are malicious. It means their provenance cannot be confidently established.
Organizations spend millions securing applications while deploying software built from components whose origin they cannot fully verify.
Yet in software, we've largely accepted it as normal.
Software Bills of Materials have fundamentally improved software supply chain security by answering an important question:
What's in my software?
Like an ingredient label on food, an SBOM provides visibility into the components that make up an application. That visibility is essential for compliance, vulnerability management, and operational awareness. However, visibility alone isn't the same as trust.
Knowing an ingredient exists doesn't tell you whether it was substituted, modified, or tampered with before it reached your organization.
An SBOM tells you which components exist in an application. It does not verify that those components originated from their claimed source, remained untampered throughout the software supply chain, or can be trusted.
Inventory tells you what's inside.
Integrity tells you whether you should trust it.
Those are different questions that require different capabilities.
Recent software supply chain attacks have demonstrated that the biggest failures aren't always caused by missing inventories. They're caused by broken trust.
Attackers increasingly target upstream packages, build systems, repositories, and dependencies because compromising one trusted component can affect thousands of downstream organizations.
As software becomes more dependent on open source and AI-generated code, verifying software integrity becomes just as important as documenting software composition.
Organizations will always need SBOMs. Increasingly, they'll also need confidence that every component in those SBOMs is authentic, untampered, and trustworthy.
Trust Is the Next Frontier
The future of software supply chain security isn't better inventories. It's a verifiable trust. Because the most important question isn't:
What's in my software?
It's:
Can I trust every ingredient?
Because knowing what's in your software is only the beginning. Knowing you can trust every ingredient is what comes next.
Software entering production should include both a Software Bill of Materials (SBOM) and software integrity verification for all open-source components and their transitive dependencies.
