The Hidden Gap in Software Bills of Materials
Every day, development teams ship software that contains components their own security tools cannot see. Traditional Software Composition Analysis (SCA) tools work by reading package manifests — the declared lists of dependencies that developers write. But what actually runs in production is often a very different story. AI-generated code, precompiled vendor libraries, and third-party binaries routinely bypass package managers entirely, leaving no trace in any manifest. The result is an SBOM — a Software Bill of Materials — that is technically complete on paper but dangerously incomplete in practice. For developers, IT decision-makers, and compliance officers operating under tightening European and global regulations, SBOM binary analysis is quickly moving from a nice-to-have to a non-negotiable requirement.
Toronto-based cybersecurity company Insignary, Inc. has built its platform, Insignary Clarity, specifically around this structural problem. Its patented binary fingerprint technology scans compiled binaries directly — without requiring access to source code or package managers — to surface open-source components, license obligations, and known vulnerabilities that would otherwise remain invisible. The company has now been recognised as a Sample Vendor for Reachability Analysis in the Gartner Hype Cycle for Secure Software Engineering, 2026, adding to citations in three previous Gartner reports covering application security, AI-augmented vulnerability remediation, and open-source software assessment.
Why AI Coding Assistants Are Making the SBOM Problem Much Worse
The arrival of AI coding assistants has dramatically accelerated the pace at which untracked open-source components enter production software. When a developer uses an AI assistant to generate a function, that assistant may incorporate patterns, snippets, or entire libraries drawn from its training data — often without explicit attribution or package declaration. The resulting code compiles and runs, but the underlying dependencies are invisible to traditional SCA tools that scan only declared manifests.
The scale of concern is documented. A 2024 Venafi survey of 800 security decision-makers across the U.S., UK, Germany, and France found that 92% are concerned about AI-generated code, and 63% have considered banning it outright over security risks. Meanwhile, the U.S. National Vulnerability Database recorded more than 48,000 CVEs in 2025 — approximately 130 new vulnerabilities disclosed every single day. According to research from NIST's cybersecurity programme, the velocity of new vulnerability disclosures has consistently outpaced organisations' ability to triage and remediate them, making accurate visibility into deployed components a prerequisite — not a luxury.
The challenge is not simply one of volume. It is structural. If your security tooling reads declarations rather than binaries, you are auditing intent rather than reality. And in regulated industries — medical devices, financial services, critical infrastructure, government procurement — the gap between those two things carries real legal and operational consequences.
"SBOMs are increasingly becoming a regulatory requirement around the world. However, software transparency is only as reliable as the accuracy of an SBOM itself. You cannot verify an SBOM by reading the manifest that created it. You verify an SBOM by examining the software that was actually built, shipped, and deployed."
— Taek Wan Kim, President & CEO, InsignaryHow Binary-First SBOM Analysis Actually Works
The distinction between source-based and binary-based software composition analysis is fundamental. Source-based SCA tools parse code files and configuration manifests — they rely on what developers have explicitly declared. Binary-based SCA tools, by contrast, analyse the compiled output: the actual executable files that get deployed to servers, embedded devices, or cloud infrastructure. Insignary Clarity's approach uses patented binary fingerprinting to match code fragments within compiled binaries against a database of known open-source components, identifying what is present regardless of whether it was declared.
This matters particularly in several common enterprise scenarios. A vendor delivers a compiled library with no accompanying source. A build process incorporates a legacy component whose manifest was never updated. An AI assistant generates code that incorporates a vulnerable cryptography pattern. In each case, source-based tools see nothing. Binary analysis surfaces the actual component, its version, its known vulnerabilities, and its licence obligations.
Insignary Clarity's key capabilities address each layer of this problem:
- Binary SCA: Identifies open-source components, vulnerabilities, and licence obligations directly from compiled binaries, without requiring source code or package manifests.
- AIBOM Generation: Produces an AI Bill of Materials for software containing AI-generated or AI-assisted code, covering components that bypass traditional dependency declarations.
- Reachability Analysis: Determines which disclosed vulnerabilities actually reach executable code paths, enabling risk-based prioritisation rather than raw CVE-count triage.
- Continuous Vulnerability Alerting: Monitors stored SBOMs against updated vulnerability databases and delivers automated alerts when newly disclosed CVEs match deployed components — without requiring a rescan.
The reachability analysis capability is particularly significant. Not every vulnerability in an open-source component is exploitable in every application that uses it. Gartner notes that "open-source and third-party components may contain a long list of vulnerabilities, but not all of them directly impact your code base. Reachability analysis helps in triaging the vulnerabilities based on their exploitability." For security teams drowning in CVE alerts, the ability to filter for vulnerabilities that actually reach live code paths transforms triage from a theoretical exercise into a practical workflow.
Which Regulations Now Require Verified SBOMs — and What That Means for European Organisations
For European organisations and those selling software into regulated markets, the regulatory pressure around SBOMs is accelerating rapidly. The frameworks now requiring or strongly encouraging verified SBOMs span multiple jurisdictions and sectors.
| Regulation / Framework | Jurisdiction | SBOM Requirement | Key Sectors |
|---|---|---|---|
| EU Cyber Resilience Act | European Union | SBOM documentation for products with digital elements | All connected hardware/software products |
| U.S. Executive Order 14028 / OMB M-26-05 | United States | Federal agencies may independently verify vendor SBOMs | Federal government software procurement |
| FDA Section 524B | United States | Binary-verified SBOM required for medical device premarket submissions | Connected medical devices |
| Canada Bill C-8 (CCSPA) | Canada | Mandatory supply chain risk management, effective June 2026 | Banking, telecoms, energy, transport |
| NIST SSDF / CISA Guidance | United States | SBOM best practice guidance for software producers | Critical infrastructure |
The EU Cyber Resilience Act (CRA) is the framework with the broadest implications for European developers and vendors. It requires manufacturers of products with digital elements — from connected devices to enterprise software — to maintain documentation of their software components, manage vulnerabilities, and provide security updates throughout a product's lifecycle. According to analysis from the European Union Agency for Cybersecurity (ENISA), the CRA's component transparency requirements effectively mandate the kind of verified SBOM that binary analysis tools produce — not simply the kind that manifest-reading tools can generate.
A critical shift in U.S. federal procurement is also worth noting for European software exporters. Under OMB Memorandum M-26-05, federal agencies are now empowered to independently verify vendor SBOMs rather than simply accepting attestation forms. This raises the bar significantly: a vendor whose SBOM is generated from manifests alone may find it cannot withstand independent binary verification. European software companies selling into U.S. government markets need to take note.
For connected medical devices, FDA Section 524B now mandates a binary-verified SBOM covering all compiled software components as part of premarket submissions — a requirement that makes binary-level analysis not just preferable but legally obligatory for medical device manufacturers.
BearingPoint, European Distribution, and the Global Supply Chain Security Market
Insignary's go-to-market structure reflects the global nature of software supply chain security requirements. BearingPoint — one of Europe's leading management and technology consulting firms and a strategic investor in Insignary — serves as the company's exclusive distributor across Europe. This makes BearingPoint the primary channel for European enterprises and government organisations looking to deploy binary SBOM analysis as part of their EU Cyber Resilience Act or GDPR-adjacent compliance programmes.
In Japan, Cybertrust Japan (another strategic investor) and
Originally reported by CSO Online. Summarised and curated by European Purpose.
