Handling SBOM Gaps for Proprietary and Closed-Source Components

Most software today runs on code nobody wrote in-house, and the industry has spent years building tools to track that fact. But a real slice of every application still comes from proprietary and closed-source components: compiled binaries, licensed libraries, embedded firmware. That slice is exactly where source-scanning tools go dark, and no single fix closes it. Closing the gap takes a layered approach: binary analysis where source can't reach, contract language where tools can't reach, and provenance tooling that ties the whole chain together from build to deploy. Skip any one of those layers and the proprietary-component blind spot stays exactly where it was, no matter how good the rest of the stack looks.

Source-based software composition analysis tools read manifests, package files, and code text. They can't see inside a compiled binary. A statically linked proprietary library, a closed firmware blob, a vendor's.jar with no source attached: none of it gives these tools anything to parse. NetRise made the point plainly in a public comment to CISA, an SBOM that doesn't reflect the binaries actually running on a device can't be called accurate or complete. Hard-coded credentials, embedded private keys, and misconfigurations often exist only at the binary level, and there's no source-level trace for a scanner to find, because there's no source to scan.

Biswajit De, co-founder and CTO of CleanStart, put the practical consequence in blunt terms: producing an accurate SBOM is still tricky, especially for compiled and embedded software, and plenty of organizations fall back to manual processes because their tooling can't capture the full mix of what's actually shipping. That's not a minor inconvenience. Complex build systems, where source gets compiled, linked, and packaged into a final artifact, are themselves a point where risk gets introduced and where the paper trail breaks. Embedded systems make it worse: generating a real-time, complete SBOM for a resource-constrained device or a closed development environment is often just not doable. Call this what it is: operational blindness, not a paperwork gap. An organization can't monitor vulnerabilities in a component it can't even list.

What the regulatory environment now requires organizations to disclose, and where the rules still leave gaps

The regulatory arc is easy enough to trace. A federal directive in 2021 set the SBOM expectation in motion, a regional regulation extended it across another major market, and a federal compliance deadline turned SBOMs from a nice-to-have into table stakes for anyone selling software into government or major regional buyers. This isn't limited to any one country anymore. Cybersecurity agencies in Germany, India, Britain, Australia, and Canada, along with ENISA, have all put out guidance pushing transparent component inventories, and sector bodies like Auto-ISAC for automotive and IMDRF for medical devices have followed with their own versions of the same demand.

CISA's August 2025 draft Minimum Elements, which closed its public comment period on October 3, 2025, updates the original 2021 NTIA baseline with new required fields: Component Hash, License, Tool Name, and Generation Context. Component Hash matters more than it sounds like it should for the proprietary-component problem specifically, a unique hash confirms exactly which compiled artifact shipped, even when package names collide or get reused across versions. Tool Name disclosure lets a downstream consumer judge how reliable a given SBOM actually is based on how it was made, a step toward what NetRise has called Method Disclosure.

The more telling update is the new Coverage and Known Unknowns elements. This is the regulation admitting, in writing, that full coverage isn't always achievable, and that producers should say so rather than imply completeness they can't back up. CISA's 2025 draft guidance goes further and tells buyers to write SBOM delivery and depth requirements directly into procurement agreements for commercial off-the-shelf software. Where a vendor can't or won't hand over full transparency, the guidance recommends requiring VEX statements or attestations tied to NIST SP 800-218 SSDF instead, an explicit acceptance of known unknowns as a risk posture rather than a failure state.

At a 2025 government summit focused on secure software supply chain security, panels on SBOM and VEX compliance surfaced a common frustration: practitioners said they were unsure how to drive internal change without an external compliance mandate forcing the issue. That's a tell. Regulation is doing work internal culture hasn't picked up on its own, and it shouldn't take a mandate to get there. Combined with the CRA and the early wave of AI-specific transparency rules pushing this onto board agendas, the window for treating proprietary-component disclosure as optional is closing fast.

Why source scanning alone fails for closed-source components, and what binary analysis adds

Think about what actually happens to code between the repository and production. A JAR file, a Docker image, a Python wheel: each is a transformed version of source, and the transformation itself is where proprietary risk hides from anything reading manifests. Standard public container base images commonly ship with 50 to 60 known CVEs baked in; images built minimally from source can cut that down to single digits. That gap is invisible to a source manifest. It only shows up under binary-level inspection.

A few binary analysis techniques close part of the distance. Binary software composition analysis scans compiled artifacts for known library signatures, version strings, and symbol tables to spot embedded third-party components that never show up in a source tree. Firmware and embedded binary analysis serves the same purpose for IoT, medical, and industrial control systems, where source usually isn't available at all and the operating environment is tightly constrained. Dependency extraction from package metadata embedded inside compiled artifacts, Maven metadata sitting inside a JAR, wheel metadata inside a Python package, adds another layer of visibility without needing the source itself.

None of this is a complete fix, and pretending otherwise is the mistake most teams make. Fully custom proprietary code with no recognizable library signature just doesn't match anything, and a scanner returning no match isn't the same as a scanner confirming safety. That distinction gets lost constantly: no match means no data, not a clean bill of health. A vendor's own internal transitive dependencies, the libraries their proprietary component depends on internally, stay invisible unless the vendor chooses to disclose them. And confidence varies by case: even well-regarded binary analysis tools have real limits, and whatever accuracy they achieve against known libraries still leaves unknown or heavily customized code exactly as opaque as before.

NetRise's proposed Method Disclosure principle addresses this directly: producers should state how an SBOM was generated, whether from source, from a manifest, from build attestation, or from binary analysis, so a consumer can judge the actual coverage rather than assume the document is complete just because it exists. Binary analysis belongs layered on top of source-level and build-time SBOM generation, not swapped in for either. It fills gaps other methods leave open. It doesn't erase them.

Using supplier contracts and procurement terms to reach what technical tools cannot

Once a vendor declines to hand over full SBOMs for the internal or transitive dependencies inside a proprietary component, no tool downstream can reconstruct that information on its own. There's no scanning workaround for a vendor that simply won't disclose. The only lever left is the contract, and any organization treating procurement as an afterthought here is giving away the one point of leverage it actually had.

CISA's 2025 guidance treats procurement as the primary tool for handling COTS software specifically, and the recommendations are concrete. Specify SBOM delivery, format, and depth before the contract is signed, not after. Require machine-readable formats, SPDX or CycloneDX, with the mandatory fields from the 2025 Minimum Elements, Component Hash and License included, built into the delivery requirement. And where a vendor genuinely can't or won't provide full transparency, require a VEX statement identifying which known vulnerabilities aren't exploitable in the shipped product, or require an attestation of secure development practice tied to NIST SP 800-218 SSDF.

Documenting a known unknown contractually is worth doing on its own terms. Recording explicitly, in the agreement, what a vendor will and won't disclose lets an organization's SBOM reflect that boundary honestly instead of quietly implying a completeness it doesn't have.

Contracts can do more than set delivery terms at the point of sale. Require updated SBOMs with every new release or patch, not just once at purchase. Build in audit rights or third-party attestation requirements for the components that matter most. And tie contract renewal to demonstrated SBOM compliance over time, leverage buyers have gained as regulatory expectations around software transparency have hardened.

Presence isn't the same as usefulness, either. A technically complete SBOM riddled with inconsistent data, missing fields, or broken component relationships is functionally useless, so procurement language needs to specify validation requirements alongside delivery requirements, not just demand a document and call it done. SLSA, Supply-chain Levels for Software Artifacts, is worth considering as a parallel term: requiring a vendor hit a defined SLSA level gives build-system assurance that complements SBOM disclosure without duplicating it.

Provenance attestation and the standards stack that connects supplier claims to verifiable evidence

An SBOM is only as trustworthy as the process that produced it. A document asserting "this is what's inside" carries no weight on its own if there's no way to check the claim, and a consumer with no attestation mechanism can't tell an accurate SBOM apart from a speculative one filled in to satisfy a compliance checkbox.

The stack forming to solve this fits together in layers. CycloneDX or SPDX handles the SBOM document itself. In-toto and SLSA provide build provenance attestation, proof of what build system produced an artifact and under what conditions. Sigstore signs and verifies artifacts, linking a binary back to its provenance record. VEX supplies exploitability statements, which matter enormously for proprietary components where a consumer has no way to independently judge whether a known flaw is even reachable. OSV normalizes vulnerability data across ecosystems so none of this breaks down at the data layer.

Identifiers matter just as much as the standards wrapped around them, because an SBOM entry that can't be resolved years later is worthless for compliance purposes. Package URLs give components a canonical identity. CPE codes handle platform enumeration. Software Heritage IDs use content hashes instead of location-based references, so a link inside an SBOM stays resolvable even after the original repository disappears, a detail that matters a great deal for long-lived compliance records and for legacy proprietary components that outlive their vendor's own infrastructure. Per ENISA's December 2025 SBOM landscape analysis, both SPDX and CycloneDX already support SWHIDs.

Put together, this lets an SBOM entry trace back through a repository URL, a commit identifier, and a provenance attestation, all the way from the shipped binary to its source. That's the exact chain that proprietary-component SBOMs break today. A parallel is forming for AI components too: the ML-BOM, documenting training data, architecture choices, and safety benchmarks the same way an SBOM documents code, is becoming expected as AI models get embedded inside otherwise proprietary products. Choosing open standards over proprietary formats here isn't a stylistic preference. It avoids vendor lock-in, lets evidence travel across customers and regulators in different jurisdictions, and keeps the record usable as a product changes hands.

Building SBOM generation into the development workflow so gaps are caught before they compound

Most SBOMs generated today get produced once, at the end of a build, filed somewhere, and never looked at again. Per Cloudsmith, practitioners describe this "compliance snapshot" pattern as a hard ceiling on what an SBOM can realistically deliver by 2026: a static list can't tell anyone anything about a vulnerability disclosed the week after the snapshot was taken. Anyone still treating SBOM generation as a one-time deliverable at ship date is building on a foundation that's already stale by the time it's filed, and that habit is the single most fixable mistake in this whole picture.

The fix is generating SBOMs as a native part of the build, not as an audit step bolted on at the end. The Yocto Project's OpenEmbedded build system already includes native SBOM generation, proof this works at real ecosystem scale rather than remaining a theoretical goal. Python and Perl both started exploring build-native SBOM proposals in 2024, per Anchore's 2025 research, Python's effort driven by SSDF and CRA pressure, Perl's driven mainly by the CRA. Brandon Lum, SBOM Lead at Google, framed the underlying goal well: the software industry needs its build tools to propagate software metadata on their own, so producers generate SBOMs as a standard part of the pipeline instead of forcing every downstream consumer to reverse-engineer composition after the fact.

A workable CI/CD pattern follows from that goal directly. Generate and maintain SBOMs continuously inside the pipeline, not as a one-off audit. Scan dependencies against vulnerability databases on an ongoing basis, including nightly re-scans of versions already deployed, so a newly disclosed vulnerability against a proprietary component that shipped months ago doesn't sit unnoticed. Sign and verify artifacts with SLSA and Sigstore at build time rather than after the fact. And enforce license and component policy as code, with automated rules, instead of manual review gates that just become bottlenecks nobody trusts to catch anything.

Environment reproducibility underpins all of it. If a developer's local build environment drifts from what CI actually runs, the SBOM CI generates doesn't reflect what actually got built on that developer's machine, and any proprietary component introduced through an environment-specific path quietly disappears from the record. Shared staging environments where several developers apply manual hotfixes make this worse: every undocumented change is a potential gap that never makes it into any SBOM. Provenance-aware tooling built into the development environment itself, where every package, proprietary components included, gets declared and resolved the same deterministic way every time, closes this class of gap right at the source instead of trying to catch it later.

One more thing worth flagging: MCP servers, which let AI agents interact with organizational data and systems, are a new category of software supply chain asset in their own right. Per Cloudsmith's 2026 supply chain security guidance, they need the same SBOM and provenance governance as any other pipeline component, not an exemption because they're new. And build infrastructure itself needs the same scrutiny as the application code it produces. StepSecurity disclosed an incident on March 14, 2025 in which attackers modified historical Git tags on a GitHub Action used by more than 23,000 repositories, exposing CI/CD secrets in public build logs. The build pipeline was the vulnerable asset there, not the application it was building.

Closing the remaining gap: managing the known unknowns that no tool or contract will fully eliminate

CISA's Known Unknowns element in the 2025 draft is the clearest formal admission yet that complete SBOM coverage isn't always achievable, and that producers should mark scope boundaries honestly rather than let a document imply completeness it doesn't have.

Pick the honest gap over the false sense of completeness, every time. Any organization still chasing a "complete" SBOM for a product with proprietary components is chasing something that doesn't exist. Knowing a component isn't covered lets a consumer apply a compensating control, adjust its own risk tolerance, or push harder on procurement terms for that specific piece. An SBOM that quietly implies full coverage when it doesn't have it leaves an organization defending a blind spot it doesn't know exists, which is worse than having no SBOM at all.

Even a fully accurate SBOM runs into a separate, quieter problem: mapping it to what's actually deployed. Plenty of organizations struggle to tie a specific SBOM to the exact hardware, firmware, or software version running in production, which breaks vulnerability monitoring even when the underlying document is correct. An SBOM filed in isolation, disconnected from a live asset inventory, doesn't do much good no matter how accurate it is.

Data quality is the quiet failure mode underneath all of this. A technically complete SBOM with inconsistent fields, missing data, or broken component relationships causes import errors, breaks automated tooling downstream, and wears down trust between supplier and consumer over time. A low-quality SBOM and no SBOM at all end up functionally identical from an operational standpoint, so volume of documentation was never the goal in the first place. Closing the proprietary-component gap isn't about finding the one tool or the one contract clause that solves it. Binary analysis, procurement leverage, provenance attestation, and build-native tooling have to work together, with honest documentation of what still can't be seen sitting underneath all of it.