Signing is Just the Start

In a recent blog post, we discussed npm's new code signing feature for provenance data. While code signing is a valuable security measure, it is important to recognize its limitations. In this post, we'll examine the infamous SolarWinds Orion hack and discuss why code signing alone is insufficient for ensuring security.

The SolarWinds Hack: A Cautionary Tale

The SolarWinds Orion hack is considered one of the most devastating supply chain attacks ever executed on the United States. Major players like the Department of Justice, security professionals like Mandiant, and important companies and infrastructure were all affected.

What made this attack particularly challenging to detect was that it was embedded in a code-signed update to a component of SolarWinds Orion's product. This leads us to question the efficacy of code signing in ensuring security. While the signing does allow identifying the provenance of the malicious code being introduced it did not identify anything about the code malicious or not.

From the SolarWinds incident, we can conclude that code signing did not provide sufficient security. While this doesn't mean that code signing is inherently bad, it does highlight its limitations in providing security guarantees.

At Socket Security, our mission from day one has been to help users understand their software dependencies. We support code signing objectives because they can make understanding dependencies easier. For example, unsigned updates to fsevents recently caused issues on npm by changing the source of provenance. A signature on the downloaded files would have been enough to prevent damage caused by a domain hijacking later on.

However, it's crucial to note that simply rubber-stamping code with a signature before distributing it is not enough. Security professionals need to scrutinize the data and the software's dependencies to ensure the highest level of security.

Think of software bill of materials (SBOM) as a receipt of the actual software bundled together. Signing a SBOM ensures it is the real receipt instead of a fake receipt forged by another party. To put it in a more common real world scenario, lets make an example of going to the grocery store. You get a receipt and you know it is the real one. However, knowing the items bought at the store doesn't tell you if these items are good. For example if we are buying ingredients for a sandwich the receipt might look like:

Receipt
* Bacon
* Lettuce
* Tomato

This doesn't tell us much except what items were bought. Particularly:

• It doesn't say where the lettuce came from if it is recalled.
• It doesn't say the expiration date for the bacon.
• It doesn't say if the tomato was bad when it was bought.

In the case of the SolarWinds attack. It most like the tomato example above. A bad dependency was included and knowing what was included didn't help because it didn't analyze in depth.

Conclusion

The SolarWinds hack serves as a stark reminder that relying solely on code signing for security is insufficient. While it can be a helpful tool in the security toolbox, it should not be the only measure taken to protect software and systems. Instead, a comprehensive approach to understanding and managing software dependencies should be implemented to truly safeguard your digital assets.