We talk a lot about SBOMs these days. The U.S. government’s Cybersecurity Executive Order along with other industry and U.K. mandates launched the discussion to the front of the line. And, while SBOMs do provide a consistent and clear insight into the software that you’re using, they’re far from the ultimate fix when managing software security.
Once you’ve compiled a comprehensive SBOM, you need to then put that data to use by coupling it with other tools. Using SBOMs as an entry point for further analysis will allow you to coordinate more effective security management.
Let’s break down how you can use SBOMs to facilitate the management of your security, demonstrating exactly which areas they cover and where you’ll need to bring in additional tools.
What Does an SBOM Provide?
An SBOM acts as an identification matrix. It’s a detailed list of open-source, third-party, and commercial components used in a piece of software, enabling software-producing organizations to provide transparency to customers and downstream supply chain partners by disclosing the composition of their applications to support better management of licensing and security risk within their applications.
Generating an SBOM is vital because it provides you with the details and relationships of various components used in building software. Having a complete and accurate SBOM allows you to gain further insight into what’s in your code. When distributing open source software, you must comply with the attribution conditions of most licenses. While an SBOM doesn’t guarantee that you comply, it does signal which conditional licenses you need to take into account when passing on compliance information to your customers.
There is a lot you can do with this insight, which is why creating an SBOM should be an initial part of your structured solution. However, the error arises when companies treat the simple fact of having an SBOM as enough of a security effort. Box checked, right?
With insight into the software that you’re using, you can then use it to facilitate additional research and security measures. Without putting this information to good use, you can say you’re only part way there.
Take the Extra Step
Once you have a full list and the details behind the software you’re using, keep going. Utilize VDRs (Vulnerability Disclosure Reports) and VEXs help you to move forward with next steps. A VEX document is a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities. As a machine-readable mechanism, VEX allows both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact.
With a VDR, you document which vulnerabilities are in your product, and potential methods of mitigating them. It acts as a secondary step, using the information supplied by an SBOM to help to reduce security risks.
This is why companies that have software teams that all use disparate spreadsheets for their SBOMs often suffer when it comes to managing security. The so-called “Spreadsheet Curse” negates the ability of these teams to effectively manage their software, as each different sheet tells a slightly different story. It’s not cohesive.
As the software supply chain has continued to mature, better SBOM practices have emerged. Many companies now use automatic tools that generate comprehensive SBOMs. Even those that still haven’t committed to this technology are beginning to shift their perspectives due to how useful they can be for managing security tools.
Final Thoughts
Moving security to the left is the best approach when creating a secure software supply chain. But, there is no one singular act that will ensure your software is completely secure. It’s a process, a journey with a moving target.
With an SBOM, security analysts, the legal department, and development teams can search for known threats that might be present in their software. Cataloging the components across an organizations’ portfolio of applications allows impact assessment for newly reported security vulnerabilities to drive remediation work and releases of patches to customers. However, it’s important to analyze and use that data to influence policy and manage the software supply chain.
For more information, be sure to check out the most recent Revenera Open Source exchange, where experts discuss the evolution of SBOMs and their place in a comprehensive security response plan.
