“Oh, I didn’t realise we were exposed to <vulnerability> as I didn’t think that application was using <open-source-component>.”
I often heard such comments during the initial stages of our application security uplift. There was a lack of visibility on what open-source components applications relied on. Developers were often surprised, and sometimes in disbelief, as most of these vulnerable software components weren’t listed as application dependencies; they were transitive dependencies.
I’ve previously written about how modern applications mostly comprise of open-source components. 98% of it is open-source and you can read the article at https://edwinkwan.com/2024/07/02/youre-using-more-open-source-than-you-realise/. We need to maintain a dependencies list for all our applications. We need a Software Bill of Materials, also known as an SBOM. This is similar to the ingredient list labels on the back of food products.
Software Bill Of Material Benefits
Having an SBOM provides a way to keep track of what open-source components your applications are using. It also provides you with a way to quickly understand your organisation’s exposure to any discovered open-source vulnerabilities. It’s a great resource for your incident response team.
In addition, having an SBOM allows your organisation to standardise its open-source usage and limit the number of different types of components being used. Rather than using multiple components that provide similar functionality, decisions can be made to standardise and pick the best-quality component.
Managing our software supply chain is so important that it was explicitly called out in a White House executive order for improving cyber security.
Make Sure the SBOMs are Up to Date
It’s important to ensure that the SBOMs are up to date. Automating the generation of the SBOMs as part of the Software Development Life Cycle (SDLC) is the preferred option. However, the SBOM must be generated at the correct SDLC stage. SBOMs should contain information about your production applications, so you should do that as part of the release or deployment stages. I’ve seen some organisations do their SBOM generation in the code repository. This can lead to misleading information as the application that’s running in production might not always be the latest version.
Takeaways
- All applications should have a software bill of material (SBOM).
- SBOMs can assist with the standardisation of open-source components within an organisation.
- SBOMs provide a quick way to identify an organisation’s exposure to open-source vulnerabilities.
- Information in SBOMs must be for applications that are running in production.
