Securing Your Company’s Digital Supply Chain

By Guest Blogger, Chris Bonatti, Cybersecurity Consultant with IECA of Casper, Wyoming

Forward by CyberWyoming: To learn about topics like this, join Wyoming’s Cybersecurity Competition for Small Businesses! It’s one-on-one, on-the-job, human focused risk management training program.

Unless you’ve been asleep under a rock for the past few years, you are likely aware that threat groups are targeting supply chains as a means of bypassing more traditional security countermeasures. We’ve witnessed compromise of computer and network hardware, compromise of source code by targeted penetration, and deliberate sabotage of source code by its authors. The White House has issued its directives, in the form of Executive Orders 13873 and 14017, but they are big on demands and short on solutions. The government has convened task forces and working groups. The National Institute of Standards and Technology (NIST) has released some frameworks. Namely, the Cyber Supply Chain Risk Management (C-SCRM) framework [SP 800-218] and the Secure Software Development Framework (SSDF) [SP 800-161r1] to identify, assess, and mitigate risks. However, like a lot of NIST’s products, they are long, confusing, and stop short of actually telling you how to address this threat. As usual, we have some thoughts that might help.

Fortunately, there have also been some more concrete positive developments. Google introduced something called Supply chain Levels for Software Artifacts (SLSA), or “Salsa”, with the goals of improving code integrity, particularly open source code, and making it more resilient to supply chain attacks. The SLSA framework is an Open Source Software Foundation (OpenSSF) standard that safeguards source integrity and build integrity. It allows users at all levels of the supply chain to check the provenance of any code they’re installing, determining both the reputation of the source and whether any of the code has been tampered with. SLSA also defines four levels of maturity, with 4 being the strongest. SLSA 1 only requires an automated build process that generates provenance metadata, which is data about the software’s origins, dependencies, and build process. SLSA 2 adds
version control and authenticated provenance, which prevents tampering to the extent that the build process is trusted. SLSA 3 further requires that the source and build platforms meet specific standards to guarantee auditability. SLSA 4 adds a requirement for two-person review of all changes and a hermetic, reproducible build process. This is intended to catch mistakes, and deter bad behavior by insiders. Hermetic builds guarantee that the provenance’s list of dependencies is complete.

The best news is that (since it’s Google, and not the US government) SLSA represents Internet norms… meaning that their announcement brought with it running code. In fact, the popular open source management platform GitHub has adopted SLSA, and aims for all projects to achieve SLSA 3. The Linux Foundation’s sigstore project is also using SLSA to improve software supply chain integrity and verification. OpenSSF describes sigstore as “Let’s Encrypt for Code Signing”.

Of course, solutions like SLSA do not solve the entire supply chain security problem. In particular, SLSA does nothing to help you address the risk of potentially compromised hardware. Hardware compromises might be an unadvertised network interface, hidden integrated circuit features, or memory that is especially vulnerable to rowadjacent bit errors. It’s also still early days for SLSA. Industry support for SLSA is still quite sparse, and the software market is quite fragmented. A lot of software relies on automated pre-SLSA installation or update mechanisms, many of which are proprietary. Some software will eventually benefit from the sigstore project, but have not yet incorporated its protections. It also remains to be seen how the assurance measures stipulated by the SLSA levels 3 and 4 will stand up against threat actors in the real world.

In the absence of a more comprehensive solution, IECA offers some down-to-earth suggestions for securing your organization’s supply chain. The prescription varies somewhat depending on whether we’re talking about hardware or software, and whether your organization is a producer or consumer. Depending on your circumstances more than one of the following may apply.


Register to Receive the Tech Joke of the Week!

This Week's Joke:

How many programmers does it take to change a light bulb?

None, it is a hardware problem!

More Posts: