Software supply chain security risks can be mitigated by traditional security practices under the umbrella of DevSecOps, such as scalable security with low friction through collaboration and automation.

DevSecOps is often discussed under the buzzword “shifting left” which has spawned several innovations in different areas. These include automated testing, reporting and workflow integration in software development tools and technologies. Although these are certainly important prerequisites for supply chain security, it is misleading to assume that DevSecOps by its current definition provides the solution to supply chain security challenges. And alarmingly, it tends to lead to insufficient control of potentially serious risks. VIPRE’s Chief Product Officer, Usman Choudhary explores this further..

Reviewing the framework 

Consider the Supply Chain Levels for Software Artefacts (SLSA) framework , which serves as a maturity model for supply chain security for example. Security issues in the supply chain are defined by SLSA as risks resulting from not being able to ensure software artefact integrity and that the “source code you rely on is the code you actually use“. But, different requirements are defined for each level. The SLSA maturity model focuses on verifiable software provenance and open source tools are suggested for this purpose. It is imperative that businesses spend time familiarising themselves with the various SLSA levels and activities associated with them at the current time when it comes to DevSecOps: One thing they will find is that it is extremely difficult to associate it with the practices which have been marketed as DevSecOps for the last decade.

Of course, those behind the SLSA requirements are not the only ones to provide strategies for dealing with supply chain risks. In response to the US President’s Executive Order 14028, the National Institute for Standards and Technology (NIST) wrote its own “Software Supply Chain Security Guidance“. This document lists several security controls that should be adopted by software vendors and users, including the Secure Software Development Framework (SSDF).

The SSDF comprises a set of recommended practices and the aim is to provide companies with a framework to better meet and implement the US government’s requirements for supply chain security. In particular, this involves Executive Order 14028 and Memorandum M-22-18 and the resulting verification requirements. In addition, the SSDF will support the assessment, design and implementation of software development programmes. This is done in such a way that security considerations and controls are integrated in all processes, procedures, tools and with regard to suppliers involved in software development.

Implementation of the SBOM

However, NIST’s “Software Supply Chain Security Guidance” offers even more. It describes additional practices that should be applied around the topic of attestation, including a Software Bill of Materials (SBOM).

A software bill of materials is an important component of risk management within the software supply chain (SSCRM) and is now mandatory for many industries. However, creating a comprehensive, accurate SBOM that meets standard specifications and integrating it into overall risk management processes is anything but trivial. Firstly, the business should take an inventory of all the software a company uses including everything the software contains that could become a potential risk. The software manufacturers are now required to provide companies with a bill of materials that lists all the components of a software application, along with licensing and copyright information, as well as any known security issues associated with each component. Furthermore, the NIST Guidance identifies advanced vendor risk assessments, further highlighting that the more traditional and industry-accepted DevSecOps practices are far from sufficient for supply chain security.

Addressing potential risks

It is therefore advisable to expand the previous definition and prevailing understanding of DevSecOps to include such practices that are closely related to the security of the software supply chain. The understanding of DevSecOps includes security practices that address not only the risks within the software created, but also the way the software was created in the first place. Many companies are planning to establish this formalised practice or are already doing so but given the growing complexity and the comparatively immature nature of the field, many companies do not know where best to start..

Industry-supported security strategies include:

1. Authenticity and integrity of developers
2. Authentication and access control of code management systems
3. A hardened build infrastructure in conjunction with a Software Bill of Materials (SBOM)
4. Safety verification/tests by means of Software Composition Analysis (SCA)
5. Attestation verification in a hardened deployment infrastructure
6. Integrity check before using the software

At the end of the supply chain, you need processes to protect the maintenance phase within the software lifecycle. In the infamous SolarWinds supply chain attack, attackers gained access to sensitive information at thousands of companies and several US government agencies. The result of an attack that managed to inject malicious code into the software patching process at the end of the software lifecycle.

Conclusion

So, as far as the security of the software supply chain is concerned, what matters most is the authenticity and integrity of people, processes and technologies within the application infrastructure. The topic is sufficiently complex. However, it can be made easier by looking at it in the context of the software development lifecycle. There are three main phases of software development: writing the software, building it, and deploying it. For each phase of the SDLC, there are appropriate testing methods to ensure the integrity of a software and the data but tools alone, however, are not enough. It is vital to create a developer-friendly security framework, not least through appropriate training methods that raise discussions, summarise important findings and, ideally, have checklists ready for basic security controls.

Security professionals and developers alike are struggling with the complexity of the issue and the potentially far-reaching impact on all areas of the software supply chain. In light of this, development teams should be better equipped than they have been in the past to take appropriate measures to manage the risks at any point in the SDLC. As a result of all the strategies listed above, moving forward, the supply chain should be able to verify the authenticity and integrity of everything and everyone involved in the creation, development, deployment, and use of software.