On May 12, 2021, US Executive Order (EO) 14028 made software bills of materials (SBOMs) part of every open source risk management and software supply chain security conversation. The EO didn’t define any requirements surrounding SBOMs. However, it did ignite relevant efforts for software producers and consumers across the globe.
Since the issuing of the EO, we have seen some clarification around SBOM requirements. These include those outlined by NIST, but requirements vary across different industries, jurisdictions, and private customers. Regardless, it’s important for software producers and consumers to understand the limitations of SBOMs across the board. Doing so will help them understand how to best augment their SBOM workflows to account for those limitations.
SBOM limitations: It’s just a list of ingredients
Just like any data source, the effectiveness of an SBOM is dictated by its accuracy. If an SBOM doesn’t accurately list its components and their effective versions, then there is a chance of unaccounted risk. However, establishing complete visibility of application dependencies is harder than ever.
The 2025 Open Source Security and Risk Analysis (OSSRA) Report by Black Duck found that 70% of open source dependencies in the average commercial application are transitive. Also, only 77% of all open source dependencies can be identified by scanning package manager manifests. This means that nearly one quarter of all open source dependencies in commercial applications are introduced though other means. These include manual inclusion, AI coding assistants, non-standard package managers, and so on. Identifying all these dependencies for inclusion in an SBOM is growing increasingly difficult, emphasizing the concern of inaccurate SBOMs.
Should teams overcome the challenge of SBOM inaccuracy, then comes the task of identifying risk. Essentially, an SBOM is just a list of ingredients. It does not provide any insights into potential risk associated with the listed dependencies. For example, an SBOM could mention the inclusion of Apache 2.12.2. However, it will not tell you that component contains a critical vulnerability that has been exploited in the wild. All the SBOM generation and ingestion efforts made by teams will be for naut should they be unable to associate SBOM components with risk.
SBOMs Under Threat
Adding to the complexity is that SBOMs themselves can become targets of attack. Just like attackers can compromise a software artifact in the build or deployment stage, just as they did with SolarWinds and Codecov, respectively, they can do the same with SBOMs. Should an attacker gain access to a build environment to inject malicious packages, it wouldn’t be a far leap for them to also intercept a legitimate SBOM to remove references to the malicious package before sending it along to their unsuspecting victims. If this is done early enough in the software development lifecycle, the producer may even sign the corrupted SBOM, verifying its authenticity.
These examples of challenges and limitations represent a few among several others, like lack of standardization and compatibility, difficulty keeping SBOMs dynamic and updated, overcoming limited visibility of dependencies, and so on. All of this leads to perhaps the biggest issue, which is the overhead that this introduced to a business. Companies building software in regulated spaces have no choice but to build SBOMs and grapple with these challenges, meaning that more resources must be onboarded or shifted towards solving these problems.
Using automation to shift SBOMs from liabilities to assets
Considering that the average application contains 911 open source dependencies, manually identifying and tracking these dependencies is not a scalable approach. Leveraging the use of a tool, like software composition analysis (SCA), automates this task, among others, to bring accuracy alongside velocity.
Depending on the quality of the tool, SCA can automatically detect open source, commercial, and custom components before, during, and after builds. Additionally, some can import third-party SBOMs and automatically add the listed dependencies to the consumer’s own projects. The result is a complete and accurate SBOM, ideally exported in a standardized format like SPDX or CycloneDX.
Given the pace of modern application development, SBOM generation isn’t something that should be done on a pre-determined basis. Some studies suggest that even the slowest DevOps shops have an average cycle time of less than a week. As soon as a change is committed to a project, an SBOM is out of date. For this reason, building dependency analysis and SBOM generation directly into the software development lifecycle is crucial. This includes triggering scans and SBOM generation via integrations with CI/CD tools like GitHub, Jenkins, or Artifactory. Doing so prevents SBOMs from being static and chronically outdated.
Connecting the Dots
These same tools and integrations can be used to connect the dots between SBOMs and associated risk. An SCA tool will include a database of known vulnerabilities. This will alert teams to vulnerable components that violate custom policy. This will prevent them from getting built into projects and making it into the final SBOM.
Some solutions will even continuously monitor SBOMs long after the application has been shipped, evaluating them for newly disclosed dependencies that impact included dependencies. As a matter of fact, some software consumers require vulnerability information be included alongside SBOMs, perhaps in Vulnerability Exploitability Exchange (VEX) format, which many tools also offer support for.
Finally, SBOMs need to be treated like any other software artifact when it comes to secure sharing. There’s no shortage of free and commercial solutions available offering secure APIs and storage for public and private SBOM distribution. This enables teams to leverage automation to detect application dependencies, continuously analyze them for risk, dynamically build SBOMs at the pace of development, and make them securely accessible to key stakeholders via APIs or direct CI/CD integrations.
SBOMs: Another powerful tool to combat cyber risk
SBOMs enhance software security by improving vulnerability detection, compliance, and supply chain transparency.
They help identify risks like Log4j and manage dependencies, but they have limitations. SBOMs can be incomplete or outdated, lack exploitability context, face standardization challenges, and introduce business friction. To be fully effective, SBOMs must be paired with real-time monitoring, vulnerability management, and secure distribution. These are all challenges that teams should turn to automation to address.
- Digital Supply Chain
- Risk & Resilience