A Software Bill of Material (SBOM) lists the software components that are used in a piece of software. It typically also provides an overview of known vulnerabilities (N-day vulnerabilities) as well as the software licenses that cover the components used.
All in all, this is often a significant amount of information to process, especially if this is the first time that you are seeing an SBOM for your software development project, which is the case for a lot of teams that rely on software as a significant component in the products that they build.
Why Are We Doing This?!?
Cyber security regulations are tightening for many industries and regulators are taking notice. This holds for, for example, the automotive industry, the US Federal Government through Executive Order 14028, the FDA as well as the European Consumer market through the Cyber Resiliency Act.
At a high level these standards direct software providers to be aware of the open-source components that they use in their project, to understand the outstanding risk due to known vulnerabilities, and to be ready to issue software updates when new vulnerabilities are discovered and published in the future.
At the same time, license compliance remains of legal importance. In other words, projects need to make sure to not include a viral open-source license that requires publishing of competitive intellectual property.
So now, in today’s charged regulated climate, the need to understand software composition is present and urgent.
How Are We Doing This?!?
Manual methods of tracking software composition in a spreadsheet as developers add new components, is onerous on developers, not to mention the product managers asking for this information. Further, manually looking up the vulnerabilities related to these components in the National Vulnerability Database (NVD), slows production.
A bit more sophisticated project might track through Dependency Track. But the process still relies on manual tracking, which is nearly as prone to errors as using spreadsheets, and the data needed to make a valid decision on whether or not to use a component is nearly as incomplete.
Software composition analysis during development and at release offers the easiest and most available way to automating this tracking. Conducting this analysis during development provides early information on whether or not they even want to use a components; while conducting such analysis again at release time allows the team to do complete analysis of the ‘golden bits’, the bits that make up the final product.
Most software development projects include third party and open-source libraries that are often provided as binaries. Sometimes these have a list of libraries provided, but based on our empirical evidence, data about the code included in third-party libraries is usually incomplete and often missing components.
CodeSecure provides CodeSentry, an easy-to-use solution that scans these golden bits and provide an accurate Software-Bill-of-Materials quickly, usually in minutes. Development teams may use this manually, or integrate it as part of your release process in GitLab for example through a CI Component. CodeSentry automatically detects components used in these third-party libraries and brings them to the surface.
What To Do With The Info ?!?
First, realize that having data is great! You are in a lucky position. Now, the earlier you receive the information in the Software Development Lifecycle, the better it is. But still, even if you receive this information a couple of weeks (or days) before your release date, realize that having this information _before_ you ship the final bits out of the door is better than shipping product with blinders on.
I talk with a lot of customers in this position and we go through a simple process:
- Assess the component list
- Asses the vulnerability list
- Assess the license list
- Iterate
Let’s walk through these four stages in a bit more detail.
1. Assess the component list
Review the list of the components provided in the SBOM and review for accuracy. Follow with editing (if required) and a quick review with your engineering team as the first step of the SBOM provisioning process.
2. Assess the Vulnerability List
Realize that the vulnerability list lists all the known vulnerabilities for the found components, an overwhelming notion for most development teams when you consider how many third-party components reside in code. CodeSentry provides some strong filtering assistance here. For example, if it knows that a vulnerability is related to a specific sub-part of a component and that sub-part is not detected, then it will filter out that component. CodeSentry further reduces developer toil, by assessing vulnerabilities with knowledge of the attack surface and level of probability for an external actor to trigger the vulnerability.
BCA-Enabled Filtering Example
For example, one of our customers ended up including an older version of ffmpeg. As a media-encoding/decoding solution, ffmpeg is prone to a lot of buffer overruns associated with remote-code-execution (RCE) vulnerabilities that have a CVSS (Common Vulnerability Scoring System) score of 10. (The CVSS score indicates the criticality a vulnerability, with a score of 10 being the highest criticality.) For this customer though, ffmpeg was used to display videos as part of their documentation, so there was no way for third parties to inject videos into the system to trigger any of the vulnerabilities. With the help of CodeSentry, it only took them 15 mins to come to this conclusion and they marked all these vulnerabilities as ‘Not affected’, removing them from the outstanding risk list.
Reviewing the list of vulnerabilities with this attack-surface heuristic in mind will quickly reduce outstanding risk.
And if the heuristic does not apply and an external actor can reach the code that contains the vulnerability, then this thought process often helps the team understand how to put mitigating factors in place. For example, if libjpeg in use has a buffer overrun that can be triggered when PPM files are uploaded (CVE-2021-46822), then developers need to modify the product to not allow PPM files.
3. Assess the license list
Software licensing is a topic that warrants a discussion with your legal or licensing department, and product companies vary on how they treat licensing issues.
Some companies completely prohibit GPL based licensing, so if a GPL (GNU General Public License) license shows up in your golden bits, you must take action to remove it. And while this can be frustrating, especially if discovered late in the release process, imagine the impact of releasing _with_ that unlicensed component.
Other companies allow GPL based licenses, but only if not directly connected to their own Intellectual Property (IP). In cases like these, you need to review all the GPL license instances and explain to the legal, or licensing team how it does, or does not impact your product.
4. Iterate
Step number 4 is iterate. If you find some violations, either in vulnerabilities, or in licenses, then make changes to the product and conduct another scan.
Findings may call for changes to the product, such as switching to a newer version of the component in question in order to remove a critical vulnerability or license violation. This incurs additional testing cost, of course, to make sure the change in component version doesn’t impact the behavior of your product. But preventing violations and exploitable vulnerabilities before the product ships is worth it.
In some cases, when alternatives are unavailable, removing a functionality that depends on a component is the only option. We see both approaches in our customer base.
It is always good to remain up to date on the latest open source-components, along with their associated vulnerabilities and licensing, which SBOMs are primarily suited for. Knowing this at the beginning of the development cycle, is also a better way to go than the tail end of a release cycle with your hair on fire.
And sometimes, yes, if a problem develops late in the cycle, it may be necessary to disable a piece of functionality, even if just temporarily, while you resolve the violation.
Conclusion
It is good to have information. Better to be aware of a specific risk, or violation ahead of time, such that you can inform the appropriate teams in your own corporation, or possibly customers. Releasing software products with dangerous vulnerabilities, or crippling licensing violations has shortened promising careers across all levels of the organisation, from engineering to the C-suite. And, with regulators bearing down on software products, especially for critical embedded systems, product companies need to automate awareness into these risks at the earliest possible stages in the development lifecycle.
