Skip to content

SigStore: Securing my software with a new standard

Avatar photo

https://www.linkedin.com/in/muhammad-aizuddin-zali-4807b552/

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.

Linux Foundation Sigstore Aims to Be the Let's Encrypt of Code Signing
The SigStore Project Logo

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.

Disclaimer:

The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.

Tags:

Avatar photo


https://www.linkedin.com/in/muhammad-aizuddin-zali-4807b552/
Red Hat ASEAN Senior Platform Consultant. Kubernetes, OpenShift and DevSecOps evangelist.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.