Software bills of materials (SBOMs) have sparked a real culture shock in software development. Enterprises and regulators are now increasingly demanding these bills of goods from the providers of their software. In turn, developer teams are being made to account for – and be scrutinized over – the minute decisions they make in the development of software. This simply is something they have never done before.
Software Developers are not Security Specialists
Several important factors regarding software development need to be considered. Software developers are talented and creative people, but they are not security specialists and aren’t expected to be, for most of the discipline’s existence.
Considerations like security were left to code reviews and assessments later in the development process. Software developers are not security experts and for most of their short history have not been expected to consider the security of their builds. In recent years, demand for new software has boomed and devs are being asked to write and release more, faster. Pressure on them to be productive is rising, and they need help and guidance to adapt to this new reality, as opposed to merely being expected to quickly adopt a new field of expertise.
Software Developers are Borrowers
Furthermore, software development has a culture of sharing. It is a baseline expectation for a development team to use all manners of third-party libraries, open-source components and shared resources to construct a given piece of software.
The Linux Foundation, along with the Laboratory for Innovation Science at Harvard (LISH) in their ongoing study — Census II of Free and OpenSource Software (FOSS) – Application Libraries — found that anywhere between 70% to 90% of all software is constituted of that. The report states that it is ‘an increasingly vital resource in all industries, public and private sectors, among tech and non-tech companies alike’. In addition, LLMs like ChatGPT have become an enormously popular tool in software development, yet present huge unknowns and have the potential to introduce risks into the process. These practices are increasingly a huge vector for attack, a focus point for attackers who try to exploit software supply chains and an increasing concern for customers and governments alike.
SBOMs Bring Pressure on Software Development
The SBOM did not come out of nowhere. Vulnerabilities commonly emanate from the software development process and the dev teams who are not thinking about the security of their code or the engineering decisions they make. That is not their job and not necessarily their fault, but something has to give.
Software security is becoming a mounting concern all over the world. Given the fundamentally linked nature of software supply chains and global businesses, a fault, failure or security issue in one place can have massive consequences in other parts of the globe. We only need to look at the SolarWinds attack a few years ago, in which hackers inserted malicious code into popular software; or this year’s CrowdStrike event, in which an update led to massive technology failure across the globe. SBOMs have arisen as a way to provide accountability and transparency to this highly complex discipline and its supply chain.
Moreover, regulators are increasingly demanding this kind of transparency from their respective compliant bodies and third parties. The U.S. Food and Drug Administration (FDA) now demands that manufacturers provide SBOMs to them for any new medical device they produce. This is also the case in the private sector where standards like PCI DSS have introduced SBOM requirements in its fourth version and compliant bodies will be expected to start providing them by March.
In 2023, the EU introduced the Cyber Resilience Act. Under its auspices, any product with a digital element must come with an SBOM. The act’s text clearly states that it is not just about stopping cyber risks in the supply chain but also helping people identify where those risks emanate from. Preamble 77 of the text of the acts states, ‘an SBOM can provide those who manufacture, purchase and operate software with information that enhances their understanding of the supply chain, which has multiple benefits. It particularly helps manufacturers and users to track known newly emerged vulnerabilities and cybersecurity risks.
Why SBOMs Worry Developers
SBOMS shine a light on software development practices, which on the one hand, are an important development in a load-bearing and risk-ridden environment. On the other hand, they are also exposing dev teams to a level of scrutiny and criticism, which has never been expected of them before.
As SBOMs have become a normal part of software development, many developers find themselves worrying about decisions they will have made or not made in a release, which software libraries they have chosen or which tools they have used to build. All those decisions can now be scrutinized, criticized and rejected by customers and partners. It is crucial to note here that things change constantly: Long-reliable software libraries become outdated, protocols get deprecated and new vulnerabilities are unearthed all the time.
A release may be launched with secure and safe components — all registered within an SBOM — and yet in a few days something may become insecure and unsafe. The resulting fixes or reevaluations can add work, pressure and time to projects that are already time-starved. This only adds to the pressures that dev teams are now feeling, introducing yet more problems.
Staying on Top of Developer’s Decisions
So how software developer teams can deal with this anxiety-ridden development? One way is to give them a clearer idea of the ever-changing risk profiles of the components they use.
Dev teams need a better idea of how the decisions they make become risky. That will start with integrating better oversight of various build decisions into the development pipeline. They need ways to change and track their dependencies, to see immediately if one decision or another creates failures or vulnerabilities and to understand if the components they are using are still secure, updated and safe to use. Threat detection scans can assess a given release at the source-code level using binary analysis to assess the risk profile of both its actual behavior and its third-party or open-source dependencies. This will allow them to build and draw up those necessary SBOMs with confidence and provide proof points to querulous partners who want to dispute one build decision or another. Crucially, however, that ability needs to extend past the development stage too. Changes to the risk profile of those dependencies and third-party components need to be tracked beyond release so that they can stay on top of mounting risks within their software.
SBOMs are not going anywhere and that basic fact signifies a real change in the way software developers work. Still, we can relieve much of the anxiety around SBOMs by giving developers and engineers the necessary insight into their build decisions and dependencies along with the post-release changes they are subject to.
