Linux Foundation's answer to supply chain attacks is to offer a free code signing service for open source developers, called Sigstore. While on the right track it does not  mitigate all supply chain hazards.The truth is that it's not possible to completely do so.

To build useful software we don't reinvent the wheel but we base on work already done coming bundled in the form of libraries.
The problem is that even a mediocre open source project can have loads of such dependencies which themselves depend on others, forming a length chain.Not a problem per se unless you aim implanting malicious code anywhere in this chain. After all it takes just one command:

npm install <module>

to get infected.

How easy that is, is marvelously described in I’m harvesting credit card numbers and passwords from your site. Here’s how.

The author of that piece describes the process:

Lucky for me, we live in an age where people install npm packages like they’re popping pain killers.

So, npm was to be my distribution method. I would need to come up with some borderline-useful package that people would install without thinking — my Trojan horse.

People love pretty colours — it’s what separates us from dogs — so I wrote a package that lets you log to the console in any colour.

I was excited at this point — I had a compelling package — but I didn’t want to wait around while people slowly discovered it and spread the word. So I set about making PRs to existing packages that added my colorful package to their dependencies.

I’ve now made several hundred PRs (various user accounts, no, none of them as “David Gilbertson”) to various frontend packages and their dependencies. “Hey, I’ve fixed issue x and also added some logging"

To cut the story short, the end result is that statistically a few maintainers would take the bait and incorporate the malicious code into their dependency.Then it's a matter of time for the code to start capturing credit card accounts and sending them to a remote server.

How could this be mitigated? With signing every component down the chain which would prove its authenticity.That's what sigstore aims to do, to empower software developers to securely sign software artifacts such as release files, container images and binaries, which signatures would then be stored in a tamper-proof public log - for free.

This would alleviate the issue of a github account being highjacked (see the Gentoo account highjack case
 or HomeBrew's ) or a release being falsified because of it lacking a signature or it being signed with an incorrect one.But what happens then under the npm scenario I've already described? Not much;the only difference that it would make is that the malicious author would have had to register in order to get a key and by doing that he would presumably leave traces behind.

What Sigstore's covers is the former case:

Understanding and confirming the origin and authenticity of software relies on an often disparate set of approaches and data formats. The solutions that do exist, often rely on digests that are stored on insecure systems that are susceptible to tampering and can lead to various attacks such as swapping out of digests or users falling prey to targeted attacks.

In detail,

Users generate ephemeral short-lived cryptography keys with the sigstore client tooling and use the keys to sign software.

A sigstore PKI service will provide an X.509 signing certificate generated upon a successful OpenID connect grant. All certificates are then recorded into a certificate transparency log and software signing materials are sent to a signature transparency log.

So you don't have to manage the keys yourself, which would also deal with the issue of those keys many times ending up being written inside the source of the repo itself, in effect canceling out the signing process.

In essence tagging,tracking history and preventing tampering is a spot on case for utilizing the blockchain.But this idea was rejected on the basis of that: 

• Public blockchains with all the best of intentions, often end up using a centralized entry point for canonicalization, auth etc
• Consensus algorithms can be susceptible to majority attacks
• Transparency logs are more mature in this space at present and they are capable of providing exactly what we need. 

The project's state as it stands is that the transparency log is in place but the client signing tooling is under prototype development and is not available for general use.

So Sigstore is a decent attempt to secure the supply chain, mitigating most of the dangers, but not all. The later npm case still relies on the maintainer manually and meticulously scanning the code of the PR, a process that could very well fail to identify its malicious intent.

More Information

Sigstore

Related Articles

Track Open Source Vulnerabilities With Google's OSV

The State Of Secure Software Development - Three OpenSSF Courses

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info