The timing of CISA’s SBOM-a-rama today and tomorrow coincides with the fallout from the “vulnerability of the decade” gifting the industry with yet another example of why scaling and operationalizing the widespread use of SBOMs is so vital. Log4Shell is a 10/10 vulnerability in a hugely popular Java logging library – Log4j – used in virtually every online service. For two decades it was considered harmless, that is until last week when somebody found it wasn’t. So, who did what when? Wikipedia reports the vulnerability was privately disclosed to Apache by Alibaba’s Cloud Security Team on 24 November 2021, Cloudflare reported evidence of use in the wild on 1 December, fixes were released by Apache on 6 December, and it was publicly disclosed on 9 December 2021.
Today, knowing precisely which version of the code you run in your environment is the essential first step in quickly patching or otherwise mitigating the risk of exploitation. But quickly identifying which vendors packaged Log4j in the software and services you bought is a harder problem since most commercial software includes unlisted open-source ingredients. If there were Software Bills of Materials, they would identify them.
That means SBOMs are the long-term answer, right?! Yes, but SBOMs alone won’t help unless delivered to the right people who can act on the correct information in a timely manner. Deluging busy people and teams with unnecessary information at times of crisis can be as damaging as failing to communicate the relevant facts. Automated, permissioned distribution of SBOMs is essential to their effectiveness.
How could SBOMs help?
The ‘ingredient-list’ aspect of an SBOM is clearly critical in these situations. Combined with automated vulnerability alerts they can save time by identifying if and where compromised code exists in the software packaged by third parties and used by an organisation. This can speed decision-making on when and how to mitigate the threats. As the ongoing Log4j issue shows, the devil is in the detail. Not all versions of the code share the vulnerability, but, as the UK’s NCSC notes in its advisory, many systems have Log4j as a dependency. Tracing exactly where this code is used is the first challenge and SBOMs will definitely help.
But only if they are shared effectively
SBOMs are, however, of no value if they sit on a vendor’s shelf unshared, or if organisations must search frantically to find the right ones in a time of crisis. The widespread nature of the current vulnerability, its ease of exploitation and evidence of in-the-wild attacks, forced the decision to broadcast an alert. But this is not always the best solution, nor does it provide guarantees that the right people hear about the issue at the right time. There is always a fine line and a delicate balance to be struck between open communication and responsible disclosure.
Some software vendors have chosen to email their entire contact databases to disclose Log4j dependencies. But this approach can cause panic and creates work for already busy teams as they check for that providers’ code in their software stack – unsure as to where, or even if, it is used. Other vendors may choose to wait or to communicate via their websites, or strictly by the terms of their contracts and risk customers not acting until it is too late.
What these approaches have in common is a lack of certainty in the message getting through to those that need it in a timely fashion. What if the names on the database are no longer in the same role or even the same organisation? Whose responsibility is it to check? Does this vulnerability really affect me, and how critical is it to my operations? To be effective SBOMs must be backed with a distribution strategy that defines a process that guarantees that the right information gets to the right people at the right time. Things are complex and nuanced, read this article by Medcrypt to see why.
Immutable chain of evidence
In a crisis, all parties need robust and reliable processes. RKVST provides the foundation for automating agreed processes between all cyber supply chain participants. It ensures that critical information has provenance to be trusted. Permissioned distribution that follows data governance policies ensures SBOMs are shared to exactly the right people and places. An immutable record of every event is created so that all parties can prove what critical steps were taken. Simple low-code integration with existing systems means that much of the work identifying exactly what is at risk can be automated.
For open-source software that is freely available and widely used, the RKVST SBOM Hub provides a repository for publicly available SBOMs. Publishers have a single place to store and share SBOMs and organisations can quickly find the most up-to-date SBOM and a complete archived record of the open-source code they use. For proprietary code, software publishers can use the RKVST platform to enable governance rules so that commercial software SBOMs can be fetched by authorized parties. RKVST SBOM Hub is the first place to find and fetch any public or private SBOM.
If SBOMs are the season’s gifts that keep on giving, then using a precision distribution infrastructure would be a new year resolution worth making too. Is there a better plan to avert the next crisis?
Our Gift to You – Click Here to Use the RKVST SBOM Hub for Free!
