Alpaquita Linux: Verifying signed container images and SBOMs

1. Overview

Container images play a crucial role in containerized application development. They enable applications to be packaged and deployed consistently across multiple environments, eliminating concerns about dependencies or configuration differences.

SBOM (Software Bill of Materials) is a formal, structured list detailing all components, libraries, modules, and dependencies used to build a software application.

When a SBOM or image is shared, it is essentially anonymous, therefore it is difficult to verify the content inside or its source without cryptographic signatures.

By signing container images and attaching signed SBOMs BellSoft adds a digital “fingerprint” to its artifacts. This helps users verify the origin of images and SBOMs and ensure that they come from a trusted source.

This document explains how to verify digital signatures of BellSoft hardened container images and also how to retrieve and verify SBOMs.

Signing utility and keys

There are various methods for signing container images, such as using private/public key pairs or trusted third-party certificate authorities. BellSoft signs hardened container images, such as hardened-base, hardened-liberica-runtime-container, hardened-liberica-native-image-kit-container, and others with the BellSoft private key. Users can then verify the signature using the public key located at https://download.bell-sw.com/pki/cosign-bellsoft.pub. The signature is verified with the cosign utility. Cosign is an open-source tool developed by Sigstore that provides an easy and secure way to sign, verify, and store container images and other artifacts.

How we attach SBOMs to the images

This is similar to how we attach container images. We use cosign attest to attach an attestation to a container image, and we sign it using a private key.

For more information, refer to the cosign official documentation.

2. Verifying BellSoft container images

This part of the document provides commands and examples to help you verify the signature of the BellSoft hardened container images.

Before you can verify images, install the cosign utility on your system. For the installation instructions, refer to the Sigstore documentation.

Verification commands

You can verify a BellSoft container image against a public key with the cosign verify command. This command will return 0 if at least one Cosign formatted signature for the given artifact is found that matches the public key. Any valid formats are printed to standard output in a JSON format.

The general verification format of the cosign verify command is as follows.

cosign verify [--key <key path>|<key url>|<kms uri>] <image uri>

For example, to verify the signature of the hardened-gcc:14.2-glibc image, download and save the BellSoft public key and use the following command:

cosign verify --key ~/keys/cosign-bellsoft.pub bellsoft.azurecr.io/hardened-gcc:14.2-glibc

Output:

Verification for bellsoft.azurecr.io/hardened-gcc:14.2-glibc --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"bellsoft.azurecr.io/hardened-gcc:14.2-glibc"},"image":{"docker-manifest-digest":"sha256:bd1778b0eec2076adbd42303316e6f6838e7d619f1763a43a44f28c4de99a0f2"},"type":"https://sigstore.dev/cosign/sign/v1"},"optional":null}]

Basic cosign commands for local verifications

The following commands help you verify the signature against the supplied public key.

Note:

You can pass more than one image to cosign verify.

Verifying with an on-disk public key provided by the signer or other organization.
```
cosign verify --key cosign.pub user/demo
```

Verifying with an on-disk signed image from cosign save.

cosign verify --key cosign.pub --local-image PATH/to/user/demo

3. Retrieving and verifying SBOMs

It is possible to retrieve and verify a SBOM for an image at the same time with the cosign verify-attestation command.

To do that we first get the payload, which is Base64 encoded in-toto attestation. In the in-toto attestation the predicate field contains the actual SBOM content in JSON format.

For example, for verifying and getting the CycloneDX SBOM for the docker.io/bellsoft/hardened-base:glibc image, use the following command:

$ IMG='docker.io/bellsoft/hardened-base:glibc'
cosign verify-attestation \
    --key ~/keys/cosign-bellsoft.pub \
    --type cyclonedx \
    $IMG | jq -r '.payload' | base64 -d | jq '.predicate'

Where ~/keys/cosign-bellsoft.pub is the path to the public key provided by BellSoft and --type is the type of SBOM (both spdxjson and cyclonedx are supported for our images). This command should print out the SBOM content to the standard output.

Sample output:

Verification for docker.io/bellsoft/hardened-base:glibc --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key
{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "components": [
    {
      "bom-ref": "pkg:apk/bellsoft-hardened-containers/[email protected]?arch=x86_64&distro=bellsoft-hardened-containers-stream&package-id=f80c834c0dc9f13b",
...