SOFTWARE SUPPLY CHAIN
SBOM For Your Software Supply Chain: Added Visibility or Security Risk?
September 19, 2023
The Software Bill of Materials (SBOM) is the latest tool in the security world's toolbox, designed to improve third party vulnerability management and reduce the risk associated with software dependencies, but does it really accomplish this goal? SBOM artifacts are meant to be shared, and disclosing them could become required soon. Touted as a shiny new tool, SBOM requirements are more akin to a pop-quiz for the industry, and could put products at risk.
Software Bill of Materials (SBOM) artifacts are reports generated by software companies that detail the third-party dependencies leveraged by their solutions. The report is generated by directly scanning software artifacts such as source code, containers, and binaries in order to document a snapshot of all package versions included within or referenced by the product. SBOM artifacts offer insight into the security posture of the product and represent an architectural blueprint of the solution at a given point in time. Recently signed executive orders and updated NSA cyber security guidelines have increased awareness of SBOM practices, and call attention to the value of exposing third party dependencies to customers.
SBOM artifacts represent a source of truth for all applications, and third-party dependencies as well as the versions of those dependencies leveraged within a software build allowing internal security practitioners to quickly tell which vulnerabilities are exploitable within their framework. If the organization is using an active SBOM tool this analysis can be conducted in real-time, saving precious time while triaging threats.
For customers, published SBOM artifacts increase transparency, allowing the customer to assess security risks first-hand. This can expedite risk assessments for companies that rely on third party tools, and in theory can reduce back and forth between vendor and customer when new vulnerabilities are publicized.
SBOM reports are just that, reports. They are static and represent a single point in time, as published by the software provider. In short, the limited shelf life of the documents limits their value in times of incident response. For SBOM to truly represent a solution's ongoing exposure, it must also be paired with the constantly evolving list of vulnerabilities that exist for each underlying component (and their components). If SBOMs are static and only provided at purchase, customers would be wise to question their worth. Using old SBOM artifacts in a time of crisis would be a bit like executing a stock trade based on month-old market data.
So they should be a living document then right? Should a future materialize where all companies across the supply chain maintain and share accurate and up-to-date SBOM artifacts, a logical next step would be to catalog these SBOM’s. While this would have immense value for customers, it would be equally valuable for hackers, and would be quickly exploited. This can already be seen in open source packages, where updates are less frequent and visibility is public.
Shared product documentation can present a security risk to organizations, as it exposes source code architecture and potential vulnerabilities. SBOM artifacts do more than just provide direct visibility to a high level of technical product detail. They list packages used, and existing vulnerabilities. As Gartner noted in its recent paid-subscriber article “Quick Answer: What the New Software Supply Chain Security Mandates Mean for U.S. Federal”, public disclosures of new vulnerabilities kicks off a race between large organizations doing damage control and hackers looking to exploit the vulnerability before it can be patched. Hackers move quickly, and SBOM assets will improve this speed as cataloged SBOM artifacts would present hackers with a searchable "target list" for each new third-party vulnerability.
So it’s the old security through obscurity argument then right? No. Not when CVE’s are taken into account. Common Vulnerabilities and Exposures (CVE) are documented vulnerabilities known to be included within a version of a product or package. Security through obscurity is the practice of obfuscating the inner workings of a product (in this case the code) to prevent bad actors from analyzing the product with intentions of misuse or exploitation. A critical difference with the risk of SBOM cataloging is that there is no analysis necessary. Paired with CVEs, the report already includes all necessary details to launch an attack. Together they include exploit details, exploitable package versions, and a list of companies or products where the risk is actively exploitable. All the hackers need now is a laptop.
Recently proposed public SBOM artifacts would provide a literal roadmap for hackers to learn exploits, complete with links to companies who are actively vulnerable.
The race between fixing and exploiting vulnerabilities is nothing new, and security leaders have been tasked with mitigating security risks before they become security breaches for some time now. So security teams can just update the dependency and avoid becoming a footnote in CVE’s right?
No again. This challenge toughens each year. Economic pressures tighten security budgets, and increased use of software dependencies including open source software and Infrastructure as Code (IAC) contribute to steady increases in discovered CVEs each year. 2022 CVE discoveries eclipsed those of the prior year by over 25%, with 2023’s new CVE count already over 7,600 at the time of this blog’s publishing suggesting a continuation of the growth rate.
These CVE’s may be in new versions, or could be newly identified in existing versions of third party packages. Fixing them often requires refactoring of code or even complete functionality redesigns before the risk can be mitigated through version updates. Both take time.
To make matters worse, third party vulnerabilities require constant assessment to accurately determine exploitability. A CVE which was confirmed as “unexploitable” in one release can become a backdoor to your code in the next code push if exploitation requirements are now met. Old CVE’s can be reintroduced to source code without diligent checks in place to scan for the risks, and even when detected in the build process these can make it into production builds. These mitigation challenges lead to ever growing backlogs, and organizations frequently add more vulnerabilities than they mitigate month over month, with studies showing that half of organizations remediate less than 16 percent of existing vulnerabilities monthly.
SBOM is the new shiny toy, and it’s not going away any time soon. Not ready just yet? Here are some steps you can take to ensure your company is prepared for the next step in SBOM adoption.
SBOM artifacts don’t just expose code detail, they expose vulnerabilities. While SBOM artifacts represent an opportunity to increase security transparency for customers who rely on third party applications they also introduce a significant risk to solutions where mature security teams are not present. To capitalize on SBOM’s added visibility while guarding against increased risk, ensure that you have an active and comprehensive SBOM solution that not only visualizes risks, but also assists in the triage and remediation process when new risks arise to expedite mitigation and ensure you are well positioned in the race against bad actors. Without a fast, comprehensive remediation process and well supported security team in place, publishing SBOM artifacts could wind up supporting hackers targeting your source code.
.png)