|Does Sigstore Really Secure The Supply Chain?|
|Written by Nikos Vaggalis|
|Wednesday, 24 March 2021|
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.
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
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.
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:
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.
or email your comment to: email@example.com
|Last Updated ( Wednesday, 24 March 2021 )|