A lot of words have been written in the past few years about the SBOM – Software Bill Of Materials. With all this exposure people feel they know what it is well enough to explain – it’s a list of software ingredients, it’s important for transparency and security, and it helps expose transient dependencies. All of this is true.
Still, the SBOM isn’t as clear-cut as it seems. For one thing, consider that to stay updated each new library version or patch requires a new SBOM to be released. Often, you only change or patch one or two libraries at a time so you can just break down their new ingredients, add that to the SBOM, and leave everything else the same, right?
And what about the concept of the ‘known-unknown’? If the developers know they’re missing something they can enter it as a ‘known-unknown’ and fill in the blanks later (or not at all).
There are also software artifacts that are very complex and include multiple interlocking elements, each a software artifact in its own right. Each element often has its own, separate, SBOM, and the whole build can have a greater, aggregated SBOM.
This all goes to show that instead of a clear-cut, simple SBOM file you could end up with a host of different, ever-changing elements that you must constantly keep as up-to-date as possible.
This is all well and good but what difference would it make to anyone if an SBOM or part of an SBOM isn’t as accurate or up-to-date as it could be? What could we do to maintain both the SBOM’s provenance and its accuracy?
In this article, we’ll examine the use of the SBOM in vulnerability scans and vulnerability disclosure. We’ll talk about cryptographic signing and see how signing an SBOM, or parts of it, makes it more useful as a security and transparency tool. We’ll also talk about metadata and why it’s so important in SBOM and other artifact production, especially when cryptographically signed into an attestation.
Start Here: What’s Cryptographic Signing Anyway?
Cryptographic signatures are used to verify the integrity and accuracy of digital files or folders. A signed file cannot be tampered with without making the signature invalid and so it would be immediately discovered once someone tries to verify the signed document.
That makes digital signatures a priceless tool in the arsenal of the software security industry and there are numerous uses already found for the simple concept of digital or cryptographic signing of digital assets.
How does it work? Digital signatures are based on asymmetric cryptography where an entity has two keys – a private key and a public key. The two keys are linked together in such a way that a document signed with one’s private key can be verified using one’s public one. A verification would mean both that the document wasn’t tampered with in any way (even the change of a single bit would make the signature unverifiable), and prove the identity of the signer, or at least the identity of the key used.
What Are You Doing With That SBOM?
SBOMs are not just long complicated files containing software component information. They are your gateway to knowing exactly what components are comprising your software artifact. You need to know the full component list since even though you may think you know exactly what you included, chances are that with every added library you shipped in numerous hidden and transient dependencies, each of which could be a carrier for a vulnerability or exploit that is now included in the software you’re shipping to your clients.
Once you have an SBOM, and that full list of ingredients, you can scan that list against known vulnerability databases and see what vulnerabilities are included in your software. But that is only the beginning. As anyone who ever run a vulnerability scan knows, the results of even a simple artifact scan can easily be in the hundreds (or more) of vulnerabilities.
That’s where the hard work starts, in mapping each vulnerability, seeing if it might be exploitable in your specific software composition, documenting that information, and dealing with the exploitable vulnerabilities by patching and remediating them, preferably in order of the danger they represent (live exploits in the wild are more dangerous than a theoretical exploit that has never happened yet).
All this work and vulnerability documentation and remediation is important for you as a software producer, but it’s also important to your clients, your partners, and potential auditors.
They want to know that you’re aware of potential vulnerabilities and that you’re on top of it, patching and correcting flaws, so that those do not impact THEM as your clients or partners.
Since the time you do a scan is important in this regard due to the fact that new vulnerabilities are constantly coming into the light, signing your SBOM along with the metadata of WHEN it was created is a great way to show you’re really on top of your vulnerability list.
In this way, you can prove that you knew about a vulnerability in advance and it’s not relevant (using a VEX advisory), that it’s not present in a certain version, or that it didn’t even exist at the time you released your last version.
Where Do I Sign?
Now let’s replace that simple ingredient list file with one of the more complex use cases described in the article’s beginning. Once you have multiple SBOMs combined to form a bigger, aggregated version to describe your full artifact, signing and verifying each individual part of that aggregated version becomes ever more important. Let’s say you are building a new version of a complex software artifact. In this new version, the only thing that changed is part 1 of a 3-part artifact. The other two parts are left exactly the same. Why should you waste time and resources on building the full 3-part SBOM, scanning all 3 for vulnerabilities and mapping all 3 for relevant exploits? The only changes were in part 1 so that is the only one you should put the work in. If you signed all 3 SBOMs and vulnerability scans the last time you created them, you can include the other two parts’ information knowing that it couldn’t have been modified. You can then prove at any time that the SBOMs for parts 2 and 3 are identical to the original versions. You can, of course, do the scans again if you’re worried about new vulnerabilities, but that is completely up to you and your software risk analysis.
Being able to prove to your clients, partners, and auditors when and how often you created SBOMs and scanned them for vulnerabilities is useful for numerous reasons. Not least of which is that it might be used in court to prove that you are not liable for the damage of an exploit since you did everything you should have to be protected, thereby gaining a safe harbor.
Where to Go From Here
As we stated earlier, one of the issues with digitally signing software artifacts or files is the hassle of dealing with key management systems. Once we remove that hassle by using something like Sigstore to bypass the use of a traditional PKI and make the signing and verification flow automatic, there is really little reason to not utilize this security tool. When you consider that the identity used to sign a file or artifact can also be used in a policy verifying the security of your CI/CD pipeline, you should be even more motivated to start signing almost everything in sight.
Signing files with their metadata can help you verify the time and location of their origin, as well as the persona and system where they were created, all relevant pieces of information when considered through the lenses of a security specialist. Being able to tell that the person, system, and time match the company and pipeline where the software was created is a good idea when a simple substitution can present a signed convincing counterfeit – until the singing persona is checked.
Considering that the tool I would suggest for signing and verifying evidence is free to use, you should really have no excuse. Check out our full article on Valint – our Validation Integrity tool to see what else you can do with it and start signing your SBOMs and other generated evidence today.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
