SigStore: Securing my software with a new standard

The secure dependencies dilemma

I had one situation where the customer asking how we can ensure that our 3rd party libraries or any external public dependencies are what they claims it to be. They are very skeptical and paranoid if any tampering happened and then the compromised code or binaries being used and imported into their software build.

Hence, without the proper and standard verification point, any tampering can introduce malware and other attack surface, that can cause millions or to billions of dollar losses depending on what kind of data is being exploit.

A new standard for signing, verifying and protecting software

The concern raised by the customer is legit and it is not impacting the customer alone, but rather the whole software industry. Supply chain attack getting more and more notorious and people start to feel uneasy about 3rd party dependencies imported as part of their software building block and yet there is not a single standard way of verification. We need a new way of signing, verifying the dependencies and subsequently protecting the software on both side, therefore in collaboration of Google, Linux Foundation, Red Hat and Purdue University, the sigstore project was born.

Install it!

I`m using Mac based system, i used brew to install cosign binary.

$ brew install sigstore/tap/cosign
<<TRUNCATED>>
==> Installing sigstore/tap/cosign
🍺  /usr/local/Cellar/cosign/1.3.1: 3 files, 82.5MB, built in 3 seconds

Run it for the first time!

 $ cosign version
GitVersion:    v1.3.1
GitCommit:     645ebf09fc555762a0494baa30edc08c38435368
GitTreeState:  clean
BuildDate:     '2021-11-11T19:36:12Z'
GoVersion:     go1.17.3
Compiler:      gc
Platform:      darwin/amd64

Sign it and verify it!

sigstore just release cosign 1.0 on July 28th. cosign brings container signing, verification and storage in OCI-compatible registry. cosign also capable of supporting compatible artefact such as arbitrary blobs and SBOMs.

In general, cosign works by comparing the signing key pair, similar to how RPM based system using GPG key pair.

$ cosign generate-key-pair
Enter password for private key:
Enter again:
Private key written to cosign.key
Public key written to cosign.pub

With this key we can start to sign the container image, I have my test image as docker.io/mzali/test:latest:

$ cosign sign --key cosign.key mzali/test
Enter password for private key:

Now let`s call the cosign image reference.

$ cosign triangulate mzali/test                                                                                                  
index.docker.io/mzali/test:sha256-22810633b8cbd87828449323ffaa2454faa79536b5afe294c1f58e0736e316bf.sig

Let`s verify it!

$ cosign verify --key cosign.pub mzali/test

Verification for index.docker.io/mzali/test:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

[{"critical":{"identity":{"docker-reference":"index.docker.io/mzali/test"},"image":{"docker-manifest-digest":"sha256:22810633b8cbd87828449323ffaa2454faa79536b5afe294c1f58e0736e316bf"},"type":"cosign container image signature"},"optional":null}]

Now let`s try with blobs and sign it:

$ echo "my test artefact" > artefact-blob
$ cosign upload blob -f artefact-blob mzali/artefact-blob
Uploading file from [artefact-blob] to [index.docker.io/mzali/artefact-blob:latest] with media type [text/plain]
File [artefact-blob] is available directly at [index.docker.io/v2/mzali/artefact-blob/blobs/sha256:fe86c72fcb5951a71af9d8033c30320c2509f9898b2bf3d45793e89696bb8d6b]
Uploaded image to:
index.docker.io/mzali/artefact-blob@sha256:25ca0d9c2f4e70ce3bfba7891065dfef09760d2cbace7a2d21fb13c56990213

$ cosign sign --key cosign.key mzali/artefact-blob
Enter password for private key: %   

Again, let`s verify the blob!

$ cosign verify --key cosign.pub mzali/artefact-blob 

Verification for index.docker.io/mzali/artefact-blob:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
  - Any certificates were verified against the Fulcio roots.

[{"critical":{"identity":{"docker-reference":"index.docker.io/mzali/artefact-blob"},"image":{"docker-manifest-digest":"sha256:25ca0d9c2f4e70ce3bfba7891065dfef09760d2cbace7a2d21fb13c569902133"},"type":"cosign container image signature"},"optional":null}]

What`s Next?

cosign is just a tip of iceberg from the sigstore project. There are other components that makes up the whole sigstore project that provides all features required to provide the service.

• Rekor (provide an immutable tamper resistant ledger of metadata) 
• Fulcio (Root-CA for code signing certs – issuing certificates based on an OIDC email address)
• CTL (Certificate Transparency Log)

Since now we going to have this new standard way of signing and verifying the software, we can integrate this with SDLC or Kubernetes platform as example.

Kubernetes cosigned admission controller make the integration easy with Kubernetes, when there are unsigned image deployment can be rejected during admission check:

$ kubectl apply -f unsigned-deployment.yaml
Error from server (BadRequest): error when creating "unsigned-deployment.yaml": admission webhook "cosigned.sigstore.dev" denied the request: validation failed: invalid image signature: spec.template.spec.containers[0].image

Tekton or other CI/CD tools can be used to push and subsequently signed the artefacts using cosign binaries during the pipeline.

Implementing signature and verification for any 3rd party source, dependencies or even our own build binaries will tremendously help in securing our software build that makes the software more trusted from tampering attempt.