If there was still any shortage of public awareness about software supply chain security after SolarWinds, Log4j made sure that every last chief information security officer (CISO) is now aware they have a problem.
For many CISOs, the most startling revelation of the Log4j vulnerability was how difficult it was to discover whether and where the popular library was running in their environments.
Today’s software systems — just like physical supply chains — are a web of complicated and brittle dependencies. Developers aren’t writing software from scratch today so much as they are wiring together third party software (typically from open source), and the end results are systems with hundreds, if not thousands, of unknown dependencies.
Below are some of the critical considerations emerging as the industry tries to unwind this software supply chain security problem and institute new security mechanisms and controls to make software artifacts secure by default.
1: Better metadata for software provenance
One of the clearest needs that CISOs recognize is better metadata on the third party software that’s being brought into their build systems. Open-source code is obviously hugely beneficial and paramount to developer productivity, but before they put their trust into a software package, can developers be confident that the library they introduced hasn't been tampered with? Do they know who wrote the code, the dependencies it is using or when it was last patched? This concept of “provenance,” understanding where exactly code in organizational software originates, is one of the most important building blocks of software supply chain security.
2: Rethinking security for registries and build systems
Attackers finding a popular open source library or dependency and hacking in that way is just one path of the modern software supply chain breach. Another is through the software registries and build systems themselves.
The good news is that in the wake of recent attacks like Log4j, there’s been a huge investment by the most popular language communities to lock down their registries. Many programming languages are now incorporating code-signing into their registries. Teams are also getting smarter about how build systems can get attacked and insert malicious code. Focusing on this stage of software security can help prevent cyberattacks down the software supply chain.
3: Taming the signal/noise ratio
One of the still unsolved major challenges with software supply chain security is how CISOs can manage threat detection signals and actually decipher the real threats from false alarms. There are many open source packages that have had vulnerabilities for years — so who decides what a “critical” vulnerability is?
There have already cases where open source maintainers are in disagreement about what constitutes “critical,” and it’s going to be difficult for security teams to understand what the real signal is, and what they should pay attention to, when there are thousands of open source components in the typical software supply chain and a lot of noise to sift through.
4: Making software secure by default without disrupting developer productivity
One of the biggest challenges in solving software supply chain security is really a cultural challenge. How can business and security leaders incentivize developers — who have historically been motivated to ship new features and functionality faster — to slow down to pay attention to the integrity of software packages, roots of trust and provenance? The answer is that security leadership can’t slow them down alone. The solution must involve the right amount of automation and best practices that occur by default, so it doesn’t slow down the natural build process.
