Question: Software is only secure until it isn’t, then what happens?
Last year the Log4J vulnerability perfectly illustrated how properly shared SBOMs would have helped users find and mitigate the “vulnerability of the decade”. And over the last few days we’ve been worried that we’re in the same place with OpenSSL 3.x. Why will this keep on happening?
A lot has happened since The White House issued Executive Order 14028. SBOMs have been thrust into the spotlight as a panacea to software supply chain security, delivering integrity transparency and trust. Sunlight is the best disinfectant and SBOMs bring the transparency to let the light in.
But not everyone is happy to reveal all the gory details of their software to their end users. 15 months after the Executive Order, a new entrant came to upstage the SBOM, the Letter of Attestation.
A Letter of Attestation basically says, “I do solemnly declare that I produce good software, so help me God”. Or perhaps it’s more a Jedi mind-trick to say, “These aren’t the SBOMs you’re looking for”. The Letter of Attestation is a requirement and the SBOM now a “nice-to-have”.
The issue some may have with SBOMs is perhaps that certain know-how (a form of intellectual property) is tied up in keeping the ingredients of software secret. Or perhaps software vendors knowingly ship software with vulnerabilities and want to keep that secret. Not all vulnerabilities are exposed or exploitable, but human frailty or the spectre of legal issues mean that people don’t want to admit to potential weakness. Or worst of all, and hopefully unlikely, it is actual negligence.
So, let’s run a thought experiment by winding the clock back one year.
Imagine a year ago, all software vendors had produced Letters of Attestation. The procurement teams buying software had gathered them all, read them, filed them and much like Chamberlain in 1938, declared, “we have peace for our time”.
One month later, the Log 4J critical vulnerability was discovered.
- Do you remember the scramble to find out whether your software was affected?
- How much time did you spend identifying all software known to contain Log4J?
- How much time did you spend in support calls to suppliers and customers?
- How much time did you spend in figuring out if the vulnerability was exposed?
- How much time did you spend putting mitigations in place?
- How much time did it take from you enjoying the holiday season?
- What use were those Letters of Attestation the procurement teams waved in their hands?
Now back to today and the latest “critical” vulnerability with Open SSL only turned out to be “high severity”.
But did you hear anyone in the last week say, “if only we had Letters of Attestation, we wouldn’t have had to worry”?
Human readable documents such as Letters of Attestation are not the answer.
Letters of Attestation are useless to machines and won’t help you find vulnerable OpenSSL.
So most folks can stand down from hunting the latest “vulnerability of the decade”, which wasn’t supposed to come around for another ten years.
But at this rate we really should expect the next one won’t take so long. Consider it a warning shot.
Just because you run the latest software doesn’t mean all is ok, in fact with this vulnerability you’d have been better off not upgrading to version 3.x! But do you know which versions you’re running?
What’s the answer?
The whole point of SBOMs and machine-readable artefact transparency is to help automate the discovery of vulnerable software WHEN it becomes known to be vulnerable. Tools that can then automate remediation would help Security Operations Centres perform triage and mitigate exposure. But note that SBOMs are not fit for human consumption – they contain vast amounts of data, will change too often, and require machines to read them and analyse against known vulnerabilities.
There are requirements for governing privacy in distributing SBOMs – transparency does not mean opening everything to public scrutiny. It does mean allowing the right data to get to the right places at the right time.
There are requirements for verifying artefacts and their provenance – if your machines are going to make decisions based upon them, they had better be trustworthy and attested. Look to the Internet Engineering Task Force (IETF) Supply Chain Integrity Transparency and Trust (SCITT) working group which will be firmly on the agenda at IETF 115 in London next week.
Tools are emerging and a few days ago the open source project Graph for Understanding Artifact Composition (GUAC) was revealed by Google to help track dependencies in software.
GUAC sits at the green layer – aggregation and synthesis. But look at the red layer at the foundation. Google calls for a trust fabric. RKVST is a zero trust fabric, a zero trust evidence platform. We have that answer!
But RKVST alone does not solve all problems. We’re part of a growing ecosystem of tool vendors that create and consume software attestation and get them to the right places with RKVST. Each software producer and consumer is free to choose whichever tools they prefer.
SBOMs are the gift that keep on giving. Through APIs, SBOMs can provide a reliable, automated process, where provenance and integrity of information can be trusted and shared to exactly the right people and places so that organizations can accurately assess and address risks in a timely manner. And RKVST has the APIs for distributing evidence of software lifecycle artefacts and more, automating the work of identifying exactly what is at risk.
If you’re a software consumer, ask your SOC tool vendors to integrate with RKVST so they can get the evidence you’re looking for directly in the tools you use today.
If you’re a software developer, ask your DevOps tool vendors to integrate RKVST APIs to make it easy to distribute SBOMs to your customers.
If you’re a tool vendor, join our technology partner ecosystem here.
Or you could do all of this yourself with APIs if you want, this guide shows how.
