The Software Safety Label Problem: Why What Companies Ship Often Doesn't Match What They Report
A growing body of regulation now requires software makers to list every component inside their products. A Toronto-based firm says most of those lists are wrong before the ink dries, and regulators are starting to agree.
Key points
- The U.S. National Vulnerability Database recorded more than 48,000 software security flaws in 2025, roughly 130 every single day.
- A 2024 Venafi survey of 800 security decision-makers found 92% are concerned about code written by artificial intelligence tools, and 63% considered banning AI-generated code entirely over security risks.
- U.S. Executive Order 14028 and Office of Management and Budget Memorandum M-26-05 now allow federal agencies to independently verify vendor software ingredient lists rather than simply accepting a company's self-certification.
- Canada's Bill C-8 Critical Cyber Systems Protection Act takes effect in June 2026, imposing mandatory supply-chain risk rules on banks, telecoms, energy companies, and transport operators.
- Insignary, Inc. announced recognition as a Sample Vendor in the Gartner Hype Cycle for Secure Software Engineering, 2026, for a technique called reachability analysis.
When you buy packaged food, the ingredients list on the back is a legal document. Software has an equivalent: a Software Bill of Materials, or SBOM, which is a structured list of every component baked into an application. Governments on both sides of the Atlantic now require these lists. The trouble is, many of them are incomplete the moment they are produced.
Here is why. Modern software is assembled from thousands of pre-built pieces, much like a car built from parts made by dozens of suppliers. Developers declare some of those parts in a file called a package manifest. But code generated by AI writing assistants, components bundled inside third-party vendor tools, and pre-compiled libraries (software already translated into machine language) often bypass that declaration step entirely. They enter the finished product without appearing on any list.
Why does an incomplete ingredient list matter to ordinary people?
Because regulators and hospital procurement officers and bank auditors now rely on those lists to spot dangerous components before software goes live. If a known-vulnerable piece of code never appears on the list, nobody goes looking for it, and it sits inside production systems, sometimes for years.
Insignary, Inc., a Toronto-based cybersecurity company, says the fix is to scan what was actually built rather than what developers wrote down. Its platform, Insignary Clarity, reads compiled binaries (the finished, machine-readable form of software) directly, the way a customs officer X-rays a package instead of reading the packing slip. The platform then produces an SBOM that reflects what is genuinely present.
The company's CEO Taek Wan Kim put it plainly in the announcement covered by CSO Online: "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."
The regulatory pressure behind that statement is real and building. The U.S. Food and Drug Administration, under Section 524B of the relevant legislation, now requires every connected medical device submission to include a binary-verified SBOM covering all compiled software. The EU Cyber Resilience Act sets similar expectations for products sold in Europe. Canada's incoming law targets critical infrastructure operators specifically.
Insignary also offers what it calls reachability analysis. Gartner describes the technique this way: open-source components may contain a long list of vulnerabilities, but not all of them directly affect your specific code. Reachability analysis checks whether a flaw can actually be triggered inside a given application, helping security teams prioritise the dozens of daily new vulnerabilities rather than treating every one as equally urgent.
Organisations selling software to government, operating medical devices, or running critical infrastructure should treat SBOM accuracy as a compliance question, not just a technical preference. Regulators are no longer accepting a company's word for what is inside its products.
