Software & Security: How to Move Supply Chain Security Up the Agenda

COMMENTARY

After Log4j, software supply chains are under more scrutiny for security issues. The US government mandated software bills of materials (SBOMs) for federal software projects so that security teams can understand any potential risks from software components. The Cybersecurity and Infrastructure Security Agency (CISA), the European Union Commission, the UK's National Cyber Security Centre, and Japan are collaborating on how to make SBOMs more useful and more valuable.

However, there are problems to overcome. Actually implementing SBOMs is still down the list of priorities for many chief information security officers (CISOs). When I asked CISOs in the UK why, it came down to prioritization. When you have so many issues to deal with, how much value does an SBOM provide today?

Alongside this, you have the issue of who is responsible for maintaining the software involved. Is this a first-party application that your internal team has put together, or a third-party application that you have bought from a supplier? What about outsourced software developed for your organization by a third-party developer? Who should bear the responsibility for managing the SBOM as well as the code?

Software Supply Chain Security and Assigning Responsibility

In the world of software, it is challenging to track what is being used, as workloads can be created and stopped from minute to minute based on demand. Yet having accurate lists of what is installed, what is running, and what might be vulnerable will be essential when it comes to managing risk.

All of this makes sense in theory. So why does it fall down the priority list for CISOs, security teams, and developers alike? The challenge is how these programs get rolled out in practice. With so much IT to look after, so many changes taking place, and so much software to track, the data can overwhelm teams.

Establishing responsibility for application security and management has to focus on practical responsibilities. For example, software is often built by outsourced providers. These contracts should include SBOM delivery as part of the remit for development, as well as who will be responsible for maintaining that documentation over time. The most important element is that someone is held accountable and the rest of the organization knows their responsibilities as well.

Helping Teams to Collaborate Effectively

SBOMs are rapidly maturing, but they still have a way to go before they are standardized. Too often, security issues become the proverbial hot potato, passed on as quickly as possible to the next person. Assigning developers hundreds or thousands of software issues to fix does not magically make those fixes happen; in fact, it can lead to more problems as teams don't know what to concentrate on.

To solve this, we need to implement better practices around software supply chain security, starting with SBOMs and asset management and followed with proper prioritization discussions between security and developer teams. Both teams have to automate more of the process around fixing issues or deploying updates.

On the security side, this will involve automated patching for low-risk issues. For developers, it will mean implementing security by design practices. IT security can provide tools that integrate into developers' workflows early, so that problems can be fixed sooner. Security can also help by flagging other ways to remove problems.

For example, one CISO I worked with had demoralized teams in both security and software development. More than a million software issues and security vulnerabilities existed across endpoints, applications, and infrastructure. To get the root cause of this problem, we looked at where the issues existed. What quickly became apparent was that there was no one directly responsible for updates in software image libraries. Both sides were working hard to deal with issues, but each time a new image was created from that library, the "old" issues would come back again. Those images also contained multiple versions of Java, making them responsible for hundreds of vulnerability detections per image.

Getting everyone around a table and fixing those images cut the number of vulnerabilities and alerts dramatically. The team saw its outstanding vulnerability count drop by half, freeing up time and making both sides appreciate the other more.

This kind of discussion is not possible without data. Getting more insight helps you to prioritize across all your systems, including first-party software, so you can drive more collaboration, real change, and real success for your teams.