A Software Bill of Materials can answer one of the hardest questions in software security: what is actually inside this product? That answer has real operational value. When a new vulnerability appears in a widely used library, an SBOM can help an organization determine which applications contain the affected component without manually inspecting every product. It can expose transitive dependencies developers did not knowingly select and support vulnerability response, procurement, licensing, and software supply-chain analysis.
CISA’s 2025 minimum elements for SBOMs reflect how much the concept has matured. The agency states that an SBOM should cover the components that make up the target software, including transitive dependencies, with no minimum dependency depth. CISA also states that incomplete dependency information should be identified as a known unknown rather than silently omitted. That level of transparency can give security teams a far better starting point for evaluating software than a product name and version alone.
The limitation is that software inventory and software security are not the same thing. An SBOM describes components and relationships, but it does not independently prove that every component was identified correctly, that the build process was trustworthy, that a listed vulnerability is exploitable in the deployed product, or that an unlisted vulnerability does not exist. NTIA made a similar distinction in its original minimum-elements work by describing SBOM data as a foundational layer for software transparency rather than a complete answer to software security.
That distinction becomes much more significant once organizations begin using SBOM data to prioritize remediation or make decisions about software risk.
An Inventory Can Be Wrong
The first limitation is accuracy. An SBOM provides useful security information only when the component inventory accurately represents the software it describes. A missing dependency can prevent a vulnerability-management platform from identifying an affected application, and an incorrectly listed dependency can create false positives that consume analyst time.
Research presented at NDSS 2025 tested this problem at scale through the JBomAudit project. Researchers examined 25,882 developer-published Java SBOMs alongside their associated JAR files and found that 7,907 SBOMs failed to disclose direct dependencies. Of the omitted dependencies, 4.97 percent contained known vulnerabilities. In those cases, a vulnerability scanner relying entirely on SBOM data could miss real exposure even if the scanner itself worked exactly as intended.
The problem comes partly from how SBOMs are generated. Tools can inspect package manifests, lock files, compiled artifacts, container images, build environments, or installed packages. Those approaches do not always produce identical results. A 2024 analysis of four SBOM-generation tools in the Python ecosystem found inconsistencies involving package versions, optional dependencies, remote dependencies, and package metadata. The researchers described complete and correct SBOM generation as an area that still requires improvement.
CISA’s 2025 guidance reflects that concern by stating that SBOM errors should be corrected after discovery and revised SBOMs should be generated when new information becomes available. A document can follow the correct machine-readable format and still contain an incomplete or inaccurate description of the software.
Component Presence Does Not Equal Exploitability
A second limitation appears once an SBOM successfully identifies a vulnerable component. The presence of a vulnerable library does not automatically mean the final application exposes the vulnerable behavior.
A library may provide hundreds of functions even though the application calls only a small subset. A vulnerable feature may never execute, an affected module may be excluded from the production configuration, or a dangerous code path may require conditions that are absent from the deployed environment. CISA’s software component transparency guidance discusses this distinction by noting that downstream software can include an upstream component without using every part of that component.
This is one reason Vulnerability Exploitability eXchange, or VEX, exists alongside SBOMs. VEX can communicate whether a product is considered affected, not affected, fixed, or still under investigation for a particular vulnerability. CISA’s SBOM consumption guidance notes that vulnerability matches derived from component inventories can overstate product risk and describes VEX as one mechanism for improving prioritization.
Log4Shell demonstrated the practical value of this distinction. Finding Log4j inside an application was an important first step, but defenders still needed information about versions, application behavior, exposed interfaces, configuration, deployment context, and compensating controls. The SBOM could help establish component presence, but further analysis was still required to determine actual exposure.
A mature vulnerability-management process should use the SBOM as one source of evidence rather than treating every component-to-CVE match as an equivalent security finding.
An SBOM Does Not Prove the Build Was Clean
Component inventory also says little about the integrity of the process that produced the final artifact. Two binaries can contain the same dependencies yet originate from very different build environments.
One might be compiled from reviewed source code through an approved CI/CD pipeline using controlled dependencies. Another might be built after an attacker compromises the build infrastructure and injects malicious code shortly before packaging. Their component inventories could remain very similar despite a major difference in trust.
OpenSSF has addressed this gap through its work on attestations. Traditional SBOMs describe software composition, but they do not inherently prove how an artifact was built, tested, or deployed. Signing an SBOM can help establish who produced the document and whether it was modified later, but the signature alone cannot establish the integrity of the build process that created the software.
Frameworks such as SLSA use provenance attestations to provide that missing context. Build provenance can document where an artifact came from, what source was used, and which build environment produced it. SBOM information and provenance answer related but separate security questions, and organizations gain more useful supply-chain visibility when they can correlate both.
This becomes particularly relevant during incidents involving compromised CI/CD systems, malicious build actions, or unauthorized changes introduced after normal source-code review. A dependency inventory may remain accurate even when the artifact itself should no longer be trusted.
Known Components Can Still Contain Unknown Threats
SBOM-driven vulnerability management also depends heavily on information that defenders already possess. It works particularly well after a component or version has been associated with a known vulnerability. It provides much less information before researchers identify the problem.
The XZ Utils compromise in 2024 illustrates that limit. Malicious code associated with XZ Utils versions 5.6.0 and 5.6.1 was introduced through a supply-chain compromise rather than an ordinary accidental programming flaw. After disclosure, organizations with accurate SBOM inventories could search for the affected versions and identify systems that required investigation.
Before discovery, those same component entries could have appeared normal. An SBOM identifying XZ Utils 5.6.1 could correctly report the component name, supplier, version, and integrity information without determining that the release contained intentionally malicious behavior.
Analysis of the XZ incident also found that parts of the malicious behavior depended on release artifacts and the build process rather than presenting themselves as a simple malicious source file. That distinction reinforces why software composition data works best alongside provenance, artifact verification, behavioral analysis, and threat intelligence.
An accurate inventory can identify what software is present, but determining whether that software itself is trustworthy requires other forms of evidence.
Runtime Can Change the Dependency Picture
Software does not always finish assembling itself during the build process. Applications can download plug-ins, retrieve modules, install packages, connect to external APIs, load operating-system libraries, or change behavior according to configuration and user input. These relationships can be difficult to capture through a static build-time SBOM.
Cloud and SaaS environments make this problem more visible. A traditional application package may have a relatively stable collection of files and dependencies, but a SaaS platform can change continuously and rely on external services that the customer never installs or directly manages. CISA’s 2025 SBOM minimum-elements guidance identifies cloud software, SaaS, AI systems, validation, and correlation with security advisories as areas that still require further work.
CISA’s separate work on software transparency in SaaS environments also discusses service dependencies. One application can depend on an external service, which itself relies on other platforms and services. Those relationships can create a supply chain that extends well beyond the libraries compiled into the original product.
CycloneDX has developed a SaaSBOM model that can describe service endpoints, service dependencies, data flows, and classifications. Models such as this expand software transparency beyond traditional package inventories and recognize that application dependencies increasingly include remote services in addition to local software components.
For defenders, this means a conventional SBOM can provide an accurate description of packaged software without providing a complete description of everything the application relies on during normal operation.
Deployment Configuration Changes the Risk
Software composition also lacks much of the environmental context required for risk analysis. Two organizations can deploy the same application with identical dependencies and face very different levels of exposure.
One organization might expose a vulnerable administrative interface directly to the internet. Another might disable that interface. A third could place it behind an identity-aware proxy and restrict access to administrative networks. The component inventory may remain identical across all three environments, but the attack paths are materially different.
The same issue applies to optional modules, database connectors, APIs, operating-system libraries, cryptographic functions, and management interfaces. Security risk depends on factors such as network exposure, enabled functionality, process privileges, available identities, segmentation, and surrounding controls.
NIST’s software supply-chain guidance recommends combining SBOM information with other organizational and asset data rather than evaluating it in isolation. Integration with vulnerability-management systems, asset inventories, deployment information, and security controls can help an organization determine where an affected component is actually running and how exposed it is.
An SBOM becomes more operationally useful once its component records can be associated with real systems, applications, environments, and owners.
An Old SBOM Describes Old Software
Accuracy also degrades over time. An SBOM describes a particular software state, but software changes through dependency updates, container rebuilds, plug-in installations, emergency patches, and normal CI/CD activity.
CISA’s updated minimum-elements guidance states that each software version or update should have an associated SBOM and that builds containing changed dependencies should produce new SBOM data. This turns SBOM management into an ongoing lifecycle process rather than a document that can be generated once during procurement and stored indefinitely.
The operational challenge is correlating the correct SBOM with the software that is actually running. An organization might maintain ten SBOMs for ten application versions but still struggle to identify which version is deployed on a particular server or endpoint. In that situation, the component data may be accurate without providing useful answers during vulnerability response.
Effective SBOM consumption depends on asset management. Security teams need to connect software composition records with deployed artifacts so a newly disclosed vulnerability can be traced from the affected component to the systems that actually contain it.
Valid Formatting Does Not Prove Completeness
SBOM standards such as SPDX and CycloneDX provide consistent ways to represent software component information in machine-readable formats. Format validation can confirm that required structures, fields, and relationships follow the selected schema.
That validation does not independently prove that the inventory is complete.
The NDSS JBomAudit research illustrates the distinction. The researchers analyzed developer-published SBOMs rather than random malformed dependency lists, yet thousands still omitted direct dependencies found in the associated software artifacts. The existence of a valid SBOM did not prove that the inventory contained everything defenders needed to know.
Organizations evaluating supplier SBOMs need more context about how the documents were created. Useful questions include which generation method was used, whether the finished artifact was analyzed, whether transitive dependencies were included, how unresolved components are represented, and how revised SBOMs are distributed after software changes.
CISA’s 2025 guidance places greater weight on this issue by calling for transitive dependency coverage and explicit identification of gaps. Those requirements can improve transparency, but organizations still need processes for assessing the quality of the data they receive.
SBOM adoption becomes much less meaningful if success is measured only by whether a supplier delivered a file.
AI and SaaS Are Stretching the Definition of a Component
AI-enabled applications are also forcing software security teams to reconsider what should count as a component. A modern AI application can depend on conventional software libraries, machine-learning frameworks, model weights, external inference services, retrieval databases, plug-ins, vector stores, datasets, and external tools.
A traditional SBOM format may describe the software packages involved without capturing every model, service, or data dependency relevant to the system’s risk. CISA’s 2025 minimum-elements document identifies AI software as an area where the existing model may require further data fields and component types.
SaaS introduces a related issue. An application might depend on an external identity provider, payment processor, analytics platform, content-delivery service, messaging provider, and several APIs. Those services may be operationally important to the product without ever appearing as packages inside its binary or container.
This does not make the existing SBOM model obsolete. It means organizations need to recognize that software composition increasingly includes relationships that extend beyond the contents of a build artifact.
Large Inventories Still Need Security Context
Another problem appears once SBOM adoption succeeds at scale. A large organization can collect millions of component records across thousands of products and then match those records against vulnerability databases. The resulting number of findings can become difficult to prioritize.
Some vulnerability matches represent directly exposed and actively exploitable software. Others may involve unused code paths, development-only packages, disabled functionality, systems protected by compensating controls, or versions that are no longer deployed. Ambiguous software identifiers can also create incorrect matches.
CISA and international partners addressed this issue in their 2025 shared vision for SBOM use. Their guidance describes SBOM information as data that should be correlated with vulnerability databases, security advisories, supply-chain information, project data, end-of-support information, and VEX records.
That correlation is what turns component inventory into risk information. An organization gains much more from knowing which vulnerable component is running on an internet-facing production system than from knowing that the same component name appears somewhere in a repository of historical SBOMs.
The maturity of an SBOM program should be measured by the quality of decisions the data supports rather than by the number of SBOM files collected.
Treat the SBOM as Evidence, Not the Entire Answer
These limitations do not diminish the value of SBOMs. They define where SBOMs fit within a larger software supply-chain security program. Accurate component inventories can dramatically reduce the time required to investigate newly disclosed vulnerabilities, reveal dependencies developers did not knowingly select, identify unsupported software, and expose concentrations of dependency risk across an organization.
Their value increases when component information is correlated with other evidence. VEX can provide exploitability context, provenance attestations can document build history, vulnerability intelligence can identify known flaws, runtime telemetry can show actual application behavior, and asset inventories can connect software components to deployed systems.
Taken together, those sources answer a much broader set of questions than an SBOM can answer alone. Security teams can determine which components exist, where they are deployed, whether affected code is reachable, how the artifact was produced, and what controls surround the application.
Software transparency gives defenders an important starting point for supply-chain security. The mistake is treating component identification as the end of the analysis. An SBOM can make software risk far easier to investigate, but the quality of that investigation still depends on the context surrounding the inventory.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
Netizen Blog and News 
Leave a comment