More and more companies acknowledge the importance of an up-to-date SBOM as part of every product and new release. The NSA even published a paper encouraging companies to adopt this tool to increase cyber awareness and better protect their software supply chains. Even if you concluded that generating an SBOM is the right thing to do you may be unsure how to go about it, what tools to use, or how to implement them. There are multiple SBOM generation tools on the market, some are proprietary, some free, and some are open-source tools. In this article, we’ll cover what key features your SBOM generation tool should have to make it the right one for your needs.
SBOM Formats
There are two major SBOM formats used in the market today: SPDX and CycloneDX.
Software package data exchange (SPDX) is an open-source, machine-readable SBOM project by the Linux foundation. The latest version of the SPDX was designed in line with the NTIA’s standard for ‘Minimum Elements For a Software Bill of Materials.’ It lists the components, copyrights, licenses, and security references of a piece of software.
CycloneDX (CDX) is also an open-source and machine-readable SBOM format developed by the Open Web Application Security Project (OWASP) community. As a BOM format, CycloneDX has other applications beyond the preparation of software bills of materials. It can also be used to compile components, vulnerabilities, and services of hardware and cloud systems.
Before you start checking out the various tools consider which format would best serve your needs. It’s best to not only consider the current time but also your future needs since once you commit to a certain format you will probably find it easier to stick with it. Consider the uses your SBOMs are going to see and the tools you’ll be using to analyze the data. If you’re uncertain which format to go for look for a tool that can generate both formats.
SBOM Tools Key Features
Here are some features you should look for in a good SBOM generation tool:
SBOM collection from both SCM and final Product – Getting full coverage of your product is key to a good SBOM. It’s well known that in the development stage, you don’t always pull in all the dependencies and integrate them into the project – that is something that is usually done only on the final compilation at the end of your CI/CD pipeline. Getting an SBOM from your SCM and your final product allows you to compare the two and also make sure that no unwanted changes were made to any files or folders in the stages between. Comparing files and folders between SBOMs can be done by comparing the hash values calculated for each. Having a tool that can do that automatically would save you a lot of time and worry.
SBOM Analysis – The SBOM is a file with lots of data. It is best to have software built to analyze it for the insights you wish to receive. Of course, building such software yourself is slow and time-consuming so it’s far better to get a tool that already includes the analyzing software so you can check the resulting reports rather than trying to make heads or tails of a multi-thousand line SBOM file. Some reports you might wish to consider are comprehensive vulnerability reports for all dependencies, a report on any out-of-date component used in your software, a report on all open-source licenses used, and a report of the relative health of open-source components used. That last one could utilize elements like the OpenSSF Scorecard to give an impartial score to each package used.
SBOM automation and secure storage – Part of the SLSA security framework principles is to make each security feature as automatic and as hard to manipulate as possible. The idea is that allowing people to manipulate security feature results would just leave an opening for that feature’s cancelation or manipulation as the need arises. As part of that concept, you can look for an SBOM tool that can be fully automated to run independently on each CI/CD pipeline or compilation run without the need for any human factor intervention. Additionally, look for an SBOM tool that stores the evidence in a secure location so that only properly validated personnel may access it. That would ensure that the SBOM evidence could not be manipulated or deleted no matter the circumstances.
Continuous SBOM analysis – Another potential advantage of having your SBOMs stored by a third party is allowing that third party to continually scan them for new vulnerabilities. New vulnerabilities are constantly discovered and reported and even a package that is known to be clean today may not remain that way tomorrow. Having an SBOM feature that continually scans all your SBOMs and looks for new vulnerabilities, notifying you of any finds, would ensure that even if you do not create a new SBOM every day, week, or month, you would still not be caught unaware by a new vulnerability in a previously clean package you have included in your product.
SBOM smart sharing – One major reason to have a good SBOM, other than having a source for checking on possible software supply chain issues, is to share it with others. You might wish to share the information with other internal teams, with clients, third-party contractors, or auditors. Of course, you can always just email an SBOM file to an interested party but considering frequent software updates and therefore frequent new SBOM this could get very tedious very quickly. It’s far better to have a tool that has a built-in sharing capability so you can define a list of subscribers and new SBOMs with or without their accompanying reports would be automatically shared based on the project, its subscribers, their level of interest, etc.
SBOM advisories – As we already mentioned an SBOM may include thousands of dependencies. Expecting a clean bill of health – zero vulnerabilities – is not realistic. You’ll always have vulnerabilities. The big question is are those vulnerabilities exploitable in your product’s exact configuration? Only the developers may answer that question but you should make sure your SBOM tool has a feature to enable you to share these findings. You do not want to have to answer the same vulnerability question 1000 times. Having the ability to add advisories to your SBOM noting the exact status of each vulnerability found would allow you to both show your clients and partners you’re on the ball and share the results once your developers have verified that a particular vulnerability is not exploitable in your product.
Where To Start With Your SBOM Generation Tool
There are many other features you may look for and find in an SBOM generation tool but I think our list of features makes it clear that a good SBOM tool is more than a solitary element. It’s best to find a full system incorporating the SBOM generation, analysis (both spot and continuous), reports, and sharing.
Considering the increasing attention from regulatory elements in the US it looks like it would not be long before an accompanying SBOM is a standard for each new software release. When that happens you want to already have the best tool selected and incorporated into your SDLC. I would also like to point out that an SBOM cannot infringe on your IP – it doesn’t ‘look’ at any code and only scans file names, versions, and the like. That means that sharing SBOMs or storing them in a secure location by a trusted third party is in no way endangering your security or IP.
Services like the Scribe Security platform can offer you all of the features covered in this article with more features added all the time. Feel free to check out our platform and see what other features our SBOM generation tool includes that could benefit you and your organization.