The rise of the SBOM (software bill of materials) is hitting software developers hard. While clients can now inspect the granular contents of the software releases they receive, workloads are mounting as software developers get to grips with new demands and disciplines while being forced to deal with heretofore-unseen levels of scrutiny. Unfortunately for them, the SBOM is a necessary development in an increasingly interlinked world.
Why we need SBOMs
The SBOM addresses a pressing problem in software: the supply chain. The modern world is characterised by deep digital connection interweaving throughout our daily lives, public bodies, and private businesses. One widely used application which is critical for database management might rely on another more fundamental piece of software and that piece of software might still be composed of code libraries and third party components produced by others. It’s this software supply chain that has allowed a huge digital transformation across the globe, and yet, because of its complexity, offers myriad opportunities for failures, malicious breaches, and all manner of other catastrophes.
In fact, the software supply chain is so long and complex that a small coding oversight or a poorly judged build decision can have wide reaching effects. These can come from accidental oversights or poorly built releases, but they can also come from malicious exploitation of those weak points. Indeed, threat actors commonly try to ‘poison the stream’ by injecting malicious code into otherwise trustworthy sources.
Open source can a double-edged swords
Software development – to its great credit – is a culture of sharing. Unfortunately, that trust is often exploited by threat actors, and supply chain risks are often pronounced within the open source community on which software developers rely to build. But even when these vulnerabilities in open source repositories aren’t malicious, they still pose a huge threat.
Log4Shell emerged from Log4J, a popular open source Java Logging framework, and when it was discovered at the end of 2021, Ars Technica called the zero day “arguably the most severe vulnerability ever.” Log4Shell effectively allowed unauthorised entities to execute malicious code with elevated privileges. At the time, Ernst and Young said that the vulnerability potentially affected over 90% of all Cloud environments.
Last year, an update to CrowdStrike’s popular Falcon software crashed millions of Windows computers, paralysing airlines, government departments, and other multinationals. In fact, it caused so much havoc that some commentators have even said that it could cost the global economy ‘tens of billions’ in insurance claims.
As you can see, the supply chain is a huge source of risk for companies, especially in a world that is so closely interwoven as our own. These are just some of the factors that have led to the need for SBOMs that can provide much needed transparency in a heretofore dangerously opaque and complex process.
Developers are now paying the SBOM bill
It’s a development we should welcome, but at the same time, it comes with significant costs. Those costs are now falling on software engineers who are now required to become experts in a completely separate discipline. Quite understandably, this is a cause of great stress and anxiety for many development teams.
Software engineers have always relied heavily on borrowed components from third parties and open sources. Indeed, this practice is a real foundation of modern development practices yet it has often been done without much consideration as to the security risks of those components. There were simply not the tools, systems of accountability, or consequences that could make that security a priority in the build process.
That, however, is changing and developers are being held to account with greater scrutiny than ever before. Regulations such as the EU’s Digital Operations Resilience Act, now require companies to issue SBOMs along with software and clients are increasingly demanding them. That means that clients can now closely scrutinise code releases and send them back if they see problems. This often piles on work and pressure to already stressed dev teams and adds the risk of financial penalties for compliance violations.
Software engineers need ways to integrate security insight into their development processes. They’ll need to know how, where, and when their build decisions become risky propositions. They’ll need to gain insight into the trustworthiness of the components they use and the sources they get them from – so they can understand when once-trustworthy components and repositories become insecure. Above all, that functionality needs to be built into the development pipeline in which all this software is made, so that SBOM creation can become a streamlined process. It will always be quicker and cheaper to fix software issues earlier than later and although SBOMs might seem cumbersome, they will act as a necessary corrective in the supply chain, allowing enterprises to save costs by making them fix issues earlier and saving them the expense of recalls.
Dave Roche, Director of Product – Software Trust, DigiCert
This article originally appeared in the July/August issue of Procurement Pro.