From Our CEO: Would You Build a Car Without Knowing What’s In It?

Why software teams must adopt supply chain thinking — and go beyond today’s SBOMs — to ensure reliability, security, and compliance. 

When building a car, manufacturers obsess over every component — not just the major assemblies like the engine or transmission, but every screw, chip, sensor, and subassembly. Why? Because even a single defective part can bring the entire system to a halt, create a safety hazard, or trigger a massive recall. 

This isn’t just common sense — it’s grounded in well-established principles like the Theory of Constraints (Goldratt, 1984) and Reliability Engineering. In any interconnected system, the weakest part — or the most constrained resource — determines the overall performance and reliability of the whole. 

So here’s the question: if the auto industry treats every part as a potential point of failure, why have we, in software, accepted a lower standard? 

The Software Supply Chain: A System You Don’t See 

Modern applications aren’t built — they’re assembled. We install a few packages, import some code, and instantly inherit a vast and complex supply chain of open source components. A typical project may have hundreds or thousands of transitive dependencies, many of which are never directly declared or visible to developers. 

This creates what Reliability Engineering describes as a series system — where every part must function correctly for the whole to operate. And just like in a series circuit, overall reliability is constrained by the least reliable component. 

Yet in software, most teams still believe they're covered because they’ve generated a Software Bill of Materials (SBOM). Unfortunately, that confidence is often misplaced. 

The SBOM Illusion: Why Most Are Not Fit for Purpose 

Today, nearly 100% of SBOMs are generated from declared dependencies — those explicitly listed in package manifests, build/config scripts and the like. But this approach is fundamentally flawed for several reasons: 

• They miss undeclared dependencies of dependencies. 

• They ignore code written in “non-declarative” ecosystems like C/C++. 

• They overlook copy-pasted files and code fragments, including those introduced by AI coding assistants. 

In other words, the software BOM most teams rely on is like a car manufacturer tracking only the parts they sourced directly, while ignoring what their suppliers and subcontractors included upstream. It gives the appearance of control — without any real assurance. 

As a CEO, I see this gap as one of the most under-recognised risks in modern software development. We talk about shifting left and DevSecOps — but without full transparency into the code and components we deliver, all of these efforts are built on shaky ground. 

This brings us back to the Theory of Constraints: your organisation’s ability to manage software risk is constrained by the visibility provided by your tooling. If your SBOM can’t see beyond the surface, it can’t protect you. 

Log4Shell Was the Warning. We’re Still Not Listening. 

The Log4Shell vulnerability didn’t hit because people declared Log4j as a dependency. It hit because they didn’t know it was in their stack at all. It was included as a transitive dependency, buried inside another package, and silently shipped into production across thousands of systems. 

The weakest link wasn’t just a vulnerable library — it was an unknown vulnerable library. 

And this is the core principle of systems thinking: in a complex system, failure often emerges not from what you know, but from what you don’t. 

The Automotive Industry Doesn’t Make This Mistake 

In the automotive world, traceability isn’t optional. Every screw and chip are accounted for in the Bill of Materials, because if a defect is discovered, manufacturers must know which vehicles used it, how many are affected, and initiate targeted recalls with precision. 

Standards like IATF 16949 demand it. 

In software, we face similar stakes — safety, security, and accountability — but we lack the discipline. That has to change. 

It’s time for software to hold itself to the same standard. That means: 

• Generating complete SBOMs that include not only declared dependencies, but transitive, undeclared, and even embedded code. 

• Analysing all code — including C, C++, and hand-written or AI-generated fragments — to detect third-party code. 

• Applying the principles of reliability engineering to software architecture: model your system like a chain, and identify the weakest link before it fails. 

Know What You’re Shipping — Or Prepare for Impact 

We would never accept a vehicle built from unknown parts. We shouldn't accept software built that way either. 

If we accept that software systems are series systems, reliability is constrained by the weakest or least visible component, and most SBOMs today fail to expose those hidden components, then the only responsible path forward is to evolve our tools and practices to meet the complexity of the systems we build. 

Because what you don’t see can — and eventually will — hurt you. 

At SCANOSS, we’re building that next generation of visibility — from the code up. We don’t just analyse what you declared. We inspect the code itself, detect fragments, track provenance, and build a complete SBOM you can trust. 

This isn’t about checking boxes. It’s about creating traceability, trust, and transparency — the fundamentals of any safe and secure supply chain. 

– Alan Facey, CEO of SCANOSS