The illusion of control: is your SBOM lying to you?

• Share on Facebook
• Share on LinkedIn
• Share on X

Many companies have a Software Bill of Materials (SBOM) to tick a compliance box. Their security teams feel safe with a list of components, but there is a major problem: that list is often wrong.

When testing different SBOM tools against the same codebase, we found they produced different results. This creates an “illusion of control” where a document looks official but fails to reflect the reality of the software.

The question isn’t whether you have an SBOM. It’s whether your SBOM is telling you the truth.

The four hidden SBOM gaps

1. Declared is not the same as compiled: Developer versions often differ from CI-resolved versions; actual linked version is often unknown.
2. Hidden transitive dependencies: Declared dependencies (e.g., 10) can result in many more (e.g., 50); most tools miss the underlying layers.
3. Environment-dependent builds: OS or compiler flags can change the compiled dependencies even with the same source code.
4. Invisible components: Runtime-loaded or build-time fetched libraries never appear in a manifest file.

Why standard tools miss the mark

Static analysis tools scan source files and manifests. They’re fast. But they can only tell you what was declared, not what was compiled. They simultaneously create false positives (things in the code that never made it into the artifact) and under-report (things pulled in dynamically that aren’t declared anywhere).

Binary analysis tools try to reverse-engineer the executable. They’re closer to the truth, but they lose critical context: how did this component get here, what exact version is it if the source was modified, how does it relate to the rest of the dependency tree? Furthermore, they also fail to account for dynamic and static linking dependencies that are merged in your build and not viewable in the final executable.

Neither approach answers the question that actually matters: what did the build system compile and link? That’s not something you can answer from source files. And it’s not something you can reliably reconstruct from a binary.

What it takes to actually get this right

The compiler is the only process with complete information. It cannot compile or link something it does not know about. To get a more accurate SBOM, you have to watch the build process itself.

This is why we developed Build Guard. By recording exactly what the compiler touches and what the linker resolves in real time, Build Guard eliminates the guesswork. It captures the moment when a file is read or a library is linked, providing a level of visibility that static and binary scans cannot reach.

The result? An SBOM you can actually trust during an audit, a security incident, or a regulatory review. 

So, is your SBOM lying to you? Schedule a consultation with an Incredibuild security engineer to see.