Below you will find pages that utilize the taxonomy term “Secure Coding”
Signing and Verifying Code with Sigstore
Sigstore Basics
Let’s start with a really simple example of keyless signing using sigstore
:
First, install sigstore if you don’t already have it. E.g. with `brew:
brew install sigstore
Then, sign a file:
sigstore sign README.md
This should ask you to authenticate with an IdP to obtain an OIDC identity token. Behind the scenes, Sigstore creates a new local ephemeral keypair, then uses the OIDC identity token to create a Certificate Signing Request for the keypair which it sends to Fulcio. Sigstore receives the Signed Certificate Timestamp (SCT), Certificate and intermediate chain from Fulcio. Sigtore then signs the input using the ephemeral private key, publishes the signature, the inputs hash, and the signing certificate to the certificate transparency log - Rekor. Finally Sigstore saves the verifications materials locally, in a Sigstore bundle at README.md.sigstore.json.
Signing git commits with GPG
Signing commits with GPG is a useful technique for verifying the authenticity and integrity of code changes - here’s how you can set it up.
Creating keys
First you’ll need to create a key-pair to start signing commits. Run the following command and follow the prompts (if in doubt accept the default settings).
gpg --full-generate-key
This should give you a primary key for signing and for certifying other keys, and a subkey for encryption:
We Need to Talk About ReDoS

ReDoS - the security threat that no-one knows about. At least that how it seems, every time I talk to developers about ReDoS and get blank looks. Or when the results of a code audit highlight a bunch of evil regular expressions.
We need to talk about ReDoS. In this post, I’ll explain what ReDoS actually is, and what developers can do about it.
What Security Level Do I Need?
This system provides 128-bit security level.
Ever seen a statement like this, and wondered what it meant?
When we talk about security level, we’re basically talking about the number of steps an attacker would need in order to break a cryptographic system. So taking the above statement, that means that any attack on that system would require at least 2128 steps.
Let’s take an example. Imagine an encryption system that uses a 128-bit key. Let’s also assume that the only available attack on that system is through an exhaustive key search. That’s 2128 possible keys that the attacker would have to search through in order to find the right key. That’s 2128 steps, giving the system a 128-bit security level.