Are SBOMs the answer to the next critical vulnerability?

When the Log4Shell zero-day vulnerability was published in 2021, it sent shockwaves around the world. With a CVSS severity rating of 10 and being related to a piece of software that was used in 93% of enterprise cloud environments, the race was on to identify, and patch affected instances as soon as possible.

A fundamental good practice of development is – “don’t reinvent the wheel”. If someone has created some code which fulfils a function you need, you take that code and embed it into yours. Using open-source and third-party code as building blocks and integrating them in a new way, allows for rapid development.

The problem arises when one of those building blocks has a fundamental security flaw.

Assessing the situation

Organisations typically have two types of application code to manage. Firstly, the commercial off-the-shelf software that they purchase – for example oracle database software, or a software library where they don’t have rights to access the code. Secondly, the code they write themselves to meet their own unique needs. Both types need to be assessed to see if they contain a ticking time bomb.

For internally written code, one benefit is that you have access to the source code. You can re-task your development team to trawling through the code to check for affected libraries and apply the patch. It is prone to human error; things can be missed – but at the cost of your quarterly development schedule it can be done.

The major problem comes with software you have purchased from a third party. Most likely you will not have the source code to check manually, so you will be waiting for someone to create a tool to scan for the vulnerability. You might have to assume that the tool is safe and not a ‘trojan-horse’ containing malware itself. While you wait for a scanner to become available, you could try contacting the vendor, and waiting for your support ticket (alongside everyone else’s) to get answered. Best case scenario? The vendor posts a message on their website to tell you if they are impacted or not. Worst case scenario? The vendor is no longer in business.

Either way, its going to be a long week – a typical enterprise has over 400 applications.

Enter the SBOM

The “Software Bill of Materials (SBOM)” has been around for a while, with the original use case being to help ensure open-source licencing compliance. The SBOM was a way of breaking an application down into its ingredients – the component libraries it was built from, the version numbers and the licence restrictions associated with each. The SBOM can be as simple as a human readable text file, but more usefully – a standard format machine readable file. The SPDX format released in 2010, and the CycloneDX format created in 2017 by OWASP are the two most successful. SPDX become an ISO standard as of 2021. CycloneDX seeks to add more use cases beyond open-source compliance to include outdated component analysis and vulnerability identification. Probably the biggest event suggesting that SBOMs are to hit the mainstream was the US executive order mandating them for sales into the federal government.

Job done then?

Unfortunately, not quite. SBOMs are not ubiquitous nor is the process of collecting them, maintaining them or querying them completely mature.

For your own code, look at using Software Composition Analysis (SCA) tools which should be integrated into your development pipeline. This will ensure you always have an up-to-date SBOM for the code you have in production. For third party products, you will need the vendor to create an SBOM and some way to ingest it.

Code is very rarely static, it is updated to add new functionality, squash bugs and patch vulnerabilities. This means that SBOMs need to be updated in parallel to in order to make sure they still represent the current makeup of the software. Where software is held in an Open Container Initiative registry, these are beginning to gain support for also hosting the SBOMs there too, but for other distribution methods, where to store and how to exchange SBOMs is still a developing area.

Assuming you manage to get current versions of SBOMs for your software estate, you need a way of mining them for actionable data. Dependency-Track by OWASP is the most mature offering today, providing a great central engine for querying and searching the data across all your SBOMs. It has a GUI frontend but requires integration via API to reach its full potential. ?Internal integration with your CI/CD pipeline is a no brainer, but don’t forget you will need to integrate with vulnerability data sources to have something to validate your SBOMs against.

Conclusions

SBOMs will solve a real-world problem, but adoption will remain slow until some fundamental challenges have been solved. For SBOMs to live up their full potential, there are three key elements which need to be defined.

1.??????The ability to easily create SBOMs for your own code. We have this today with SCA, and features like standardised formats and the inclusion of an experimental SBOM creation feature in docker compose are moving SBOM creation towards mainstream.

2.??????The ability to derive value from SBOMs using automated tools is still immature, but tools like dependency-track are already valuable when combined with a vulnerability database.

With just these two elements, SBOMs can provide value to your organisation today - if you are creating and developing code internally, or for external consumption. There is a low barrier to entry, and you can use them to detect and patch vulnerabilities in your code. Shifting left vulnerability detection saves your organisation time and money and will result in a better user experience for your end customers. Making your SBOMs available to your customers, while only mandatory for US federal clients today shows transparency and will be respected by customers who are looking to automate their supply chain security.

For SBOMs to go mainstream in organisations who are mainly consumers not developers of software, the third element needs more development.

3.??????Automated exchange and ingestion of third party SBOMs. In the same way that package managers have become ubiquitous for finding and installing software in Linux, we need a similar distribution mechanism for SBOMs. Until this is available, the process of maintaining an up-to-date SBOM library will remain a barrier to value for software consumers.

As a consumer of software, you can start asking your vendors about their plans to adopt SBOMs and distribute them to their clients. Putting pressure on vendors to become more transparent via the procurement process would seem a sensible next step to grow adoption. Software consumers are entitled to ask their vendors if they use SBOMs internally, as this is indicative of good development maturity, and from there it is a small step to request the SBOMs to be shared.

Of course, knowing about a vulnerability in third party code is one thing, the ability to patch it is another. You will still be reliant on the vendor to design and distribute a patch – but a good vulnerability management process using SBOMs allows you to have a continuous reading of your security risk, and gives you the option to put in place additional security controls it mitigate those risks while you wait for a patch. SBOMs are not perfect today, but should be considered as a useful tool in your appsec armoury, and taking some tentative steps today could bring huge benefits as the ecosystem matures.