If you’re new to the Sigstore project, we officially launched on March 9th 2021 with a mission of improving the open source supply chain by making it easy to sign and verify code. We’re planning to provide free tools, APIs, and services as a public-benefit/non-profit. This post is to give a quick recap of where we are today, where we’re headed and what we’re focusing on next. I’ll also outline some areas we need help, and how to get involved!
Why does it need to be so TUF?
If you’re anything like me and spend time reading blog posts and GitHub discussions around how to securely package and release software, you’ve probably heard of The Update Framework. Unfortunately, if you’re actually anything like me it probably seemed overwhelming and confusing at first. This blog post explains the mental model I’ve built up for TUF, and some of the concepts that finally made it understandable and digest-able for me.
Naming is hard, but TUF really isn’t a framework in the traditional sense. In my head, a framework is something like a…
I’ve heard a TON of questions about how to sign an open source software release lately. Once you get past the impossible tooling/crypto questions, you quickly realize you’ve barely scratched the surface in complexity. These problems aren’t all specific to OSS, but community-driven projects do face some unique challenges that stretch beyond technical and into the philosophical realm.
What does it mean to sign a release? Who should do it? Where should the keys live? How do users verify it? Why are we even doing this again? If you (understandably assumed) that this was a solved problem, you’re in good…
The protocol and format explained!
In my last post, I showed how
cosign can be used to sign and verify container images today. In this post, I’ll explain how it works at each step of the way.
We’ll start with
cosign generate-key-pair .
This command creates an ECDSA-P256 key pair (a private and a public key). The public key bytes are encoded in a PKIX formatted file. The public key looks like this:
— — -BEGIN PUBLIC KEY — — -
— — -END PUBLIC KEY — — -
The private key is marshaled into PKCS8 formatted bytes…
I’ve seen a lot of questions about signing container images in the last few months, and unfortunately there aren’t many great options or answers today. So I decided to write a simple tool called
cosign. It can sign container images! Here’s what it looks like to use:
You can get it installed and start signing containers in minutes. There are almost no configuration options, by design. There is only one supported signature algorithm (ECDSA-P256) and one payload format (Red Hat Simple Signing).
Public keys are stored in plain old PKIX files. They look like:
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEroVS8KdYXp5SSI5YDwwQymSByQAM 7MDgk9po3wpp/hHZAzCLsu+j3axrJJ5nMet9tqX1eH8yk21G626Z8lrkQA== -----END…
This took me awhile to figure out, so I thought I would write it down in the hopes it saves someone else time later.
I have a Golang app that runs on Kubernetes (in my case GKE) that I want to add some basic monitoring to. I was hoping for a solution that roughly meets these requirements:
Searching and reading examples led me down a two routes: OpenTelemetry/OpenCensus and…
Making “many eyes” a reality with automation
Many advocates of open source software claim it is easier to make secure because it has “many eyes” looking at it. It is probably true that in the limit enough eyes can catch all bugs, but there’s no evidence we’ll ever hit that limit. Thankfully, we can help add more eyes to OSS with automation. This post explains how I built a platform to hunt for malicious behavior hiding in plain sight.
The specific type of malware I’m looking in this post embeds itself in open source packages, and exploits the fact that…
Not really. But Kind of?
Did you know that you probably already have a working PKI system for signing artifacts on your laptop today, with no keyservers, web-of-trust, or configuration? You can use it to sign files, and to find the public keys for other people and use them to verify files they signed.
So why aren’t more people using this? I think it’s just gone overlooked because it’s a relatively new feature in apretty old piece of software. I’ve only been able to find one other blog post explaining how it works (outside of the man pages).
More haunted dependencies in the jungle
This is Part Two of my Dependency Jungle series. (Part 1 here). I’m trying to better understand how large networks of projects manage dependencies, vulnerabilities and upgrades, so I decided to spend some time doing it myself. By documenting and sharing this experience, I’m hoping we can come up with ideas to systematically improve this process, making it faster and easier for real-world projects to stay up to date and secure.
From time-to-time I live-tweet these adventures, so consider following me on Twitter for some bite-sized versions of archaeology like this.
In the last…
Or, how to deploy 25+ CVEs to prod in one command!
WARNING: This is very long. I tried to trim it down, but decided against splitting it. Showing all steps required and how long this took was the point of the exercise. I expect most people not to finish reading this, and that’s OK — I didn’t even finish analyzing everything. At least scroll to the bottom so you can see how much there is, and consider following me on Twitter for some bite-sized versions of archaeology like this.
When the first railroad train was built over Niagara Falls, engineers…
Software Engineer at Google