What can you do with an SBOM today?

We can all agree that computer software is a complicated construct composed of numerous diverse components. Open-source software is becoming ever more common as a building block in software. This phenomenon is accompanied by an increase in exploitable vulnerabilities so it is little wonder that being able to tell quickly what your software (or that of your suppliers and vendors) is composed of is becoming increasingly important.

Even though you may think the SBOM is a new idea people always needed to know what were the components in their software. Initially, the process was done on excel sheets but as software became more and more complicated and interconnected a more automated format was required.

The first SBOM format, SPDX, was created in 2010 by the Linux Foundation as a common data exchange format so information about software packages and related content (like licensing) could be collected and shared. These days the most common SBOM format is OWASP’s CyclondeDX.

Put simply, an SBOM is a document that provides a complete inventory of all the components used in a piece of software and the connections between them. It includes information such as the name, version number, and origin of each component, as well as any dependencies or libraries required for the software to function properly. The purpose of the SBOM is to provide transparency and visibility into the software supply chain, allowing organizations to better manage their software assets, identify potential security vulnerabilities or licensing issues, and facilitate effective software patching and updates.

Let’s say you have already started using either an open-source tool or have bought a tool that creates SBOMs of your software. You’re diligently collecting these files and you produce them for each new version and patch you release. But what can you actually use these files for other than collecting them ‘just in case’?

So what are SBOMs good for

There are quite a few uses you can put your SBOM files to today.

Vulnerability scanning

as mentioned above the increase in exploitable vulnerabilities, particularly in open-source components, is one of the reasons for the increase in demand for SBOMs. There are multiple tools you can use to scan an SBOM to see all the recognized vulnerabilities hidden in your open-source components. Open-source scanners such as Grype and Dependency-Track can help you see what vulnerabilities are hidden not only in the dependencies you’re aware of but also in the transient dependencies — the dependencies of your dependencies. The CVE list you’ll get this way isn’t perfect but it’s better than nothing.

Prevent license poisoning

There are almost as many open-source licenses as there are different packages. The GNU General Public License v2.0 or later and the GNU Lesser General Public License v3.0 for example are two of the most popular open-source licenses, but they are both quite restrictive. In a worst-case scenario, you might be forced to distribute your proprietary software under the same license — royalty-free. To avoid losing a valuable IP it’s advisable to make sure none of your transient dependencies are trying to ‘poison’ your licensing.

Track old/unpatched/unmaintained versions

One of the risks you run into when using open-source is that the project maintainers would lose interest or time and the project would fall by the wayside and would no longer offer security patches or updates. Node offers the ‘npm audit’ tool to check if any of your dependencies have newer versions but that is not always enough. You can go to open-source project pages to check how often they are maintained and by how many people. Doing such a check periodically is highly recommended since not all open-source projects would bother putting out an EOL or EOS message.

Easily look up vulnerable libraries

Every now and again a new pervasive exploitable package comes to light. We can look at the now infamous Log4J as an example. More than a year after the exploit first became public knowledge some companies are still struggling to determine if they have the vulnerable package version and where. The fact is that when dealing with legacy systems and code, where the people who wrote it left or are not available it can be a real pain to figure out these things. Having an SBOM that would allow you to run a search to see if you have the problematic package and version would make patching or remediation much much easier.

Going Forward

The use cases I have offered in this article are only some of the more obvious security use cases for an SBOM of your software. Considering that having all your software itemized in this fashion can offer a lot more, both now and in the future. You could check your remediation stats over time, see how long it takes you to address bugs and vulnerabilities, see how often you add major features or publish security patches. And all that is before we consider the benefits of examining SBOMs of your vendors or third party tools in a similar way.

SBOMs still have a long way to go and many more capabilities are heading our way in the future — from being able to see AI’s training data sets to the ability to examine data’s encryption strength — but none of it would matter unless more people started producing and sharing SBOMs. Even if you only plan on using these informative files for your own use there should be nothing stopping you from trying SBOMs out.

By Barak Brudo, Developer Advocate at Scribe Security

Originally published at https://grcviewpoint.com on March 31, 2023.

*** This is a Security Bloggers Network syndicated blog from Stories by Barak Brudo on Medium authored by Barak Brudo. Read the original post at: https://medium.com/@mr.lightning_54863/what-can-you-do-with-an-sbom-today-bd68e371101a?source=rss-48bdf18a8d23------2