I read a couple of advisories by Caleb Queern of KPMG entitled, What Are SBOMs?, and, Which Teams In My Organization Can Help Reduce Risk Using SBOM's? These articles bring a smile to my face and give me hope that the practice of creating and using SBOMs has finally gone mainstream.
I've spent most of the last year reaching out to application security (AppSec) professionals imploring them to consider why the OWASP A9 is about to turn seven years old and yet so few teams have effective controls in place. Our own DevSecOps Community Survey tells me that less than half of the respondents indicated that their organization can produce a software bill of materials, which just seems crazy to me. I thought that surely, by now, everyone would have meaningful controls in place for this one basic ability. To compound that, a recent Gartner Report on AppSec tools had this little gem in it (emphasis added):
By 2024, the provision of a detailed, regularly updated software bill of materials (SBOM) by software vendors will be a non-negotiable requirement for at least half of enterprise software buyers, up from less than 5% in 2019.
This means that while we've had seven years to address this so far, for those that haven't, they have only four years left. But this is also where my years of frustration are turning into a smile now that this conversation has gone mainstream.
So, if your company is amongst the majority that still isn't doing software composition analysis (SCA) that can both produce a SBOM and provide visibility on the use of known vulnerable components, the good news is that Sonatype has a mature, enterprise ready solution available. Seeing a global system integrator like KPMG share their views on the importance of addressing this issue, as well as exactly how it impacts a variety of stakeholders, is exciting.
KPMG is demonstrating a deep awareness of this problem domain in the second article which covers how a SBOM affects different personas, beyond just security, within a typical organization. The concept of "Supplier Security" and "Internal Audit" illustrates the deeper Governance, Risk, Audit, and Compliance (GRAC) issues associated with any vendor relationship extended to open source software. The goal is to be able to make informed decisions around products licensing and other forms of risk. An example of this might be to look closely at the vendor's mean-time-to-detect (MTTD) and mean-time-to-repair (MTTR) record. Is the vendor actively finding and fixing their own issues or do they tend to linger?
All of this comes at a time when we are seeing sophisticated new attack vectors in the open source software world. A couple a years we saw new poison-the-well type attacks where adversaries were stealing developer credentials to publish malicious packages. Sometimes these would be the official package. Sometimes it would be named slightly differently, also known as typo-squatting.
Just last week we learned about a whole new approach that attacks development infrastructure. In this case, the integrated development environments (IDEs) are attacked, and the IDE's build process embeds a malicious payload into both the project files and the JAR files being built. This is much more virus-like in nature than anything we've seen before. This is why it is more important than ever to review security programs and ensure you have identified all of the current risks. Do you have effective controls in place for them? KPMG is showing leadership in this space and should be on your shortlist of whom you'd consider to come in and help with those controls.
