Cosign supports container signing, verification and storage in an OCI registry.
In the examples below we will use the following identifiers:
|Your Cloudsmith account name or organization name (namespace)
|Your Cloudsmith Repository name (also called "slug")
|The name of your Docker image
|A tag for your Docker image
|An SBOM in a standard format supported by cosign, SPDX, SWID, Cyclone DX
|cosign private key, cosign.key
|cosign public key, cosign.pub
Follow the instructions here to push an image to Cloudsmith.
Cosign signs OCI artifacts and pushes the generated signature into Cloudsmith. Cloudsmith hosts this signature as an artifact alongside the signed artifact.
First, follow cosign's instructions here to install cosign and generate a keypair.
cosign sign --key cosign.key docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG
To verify the image, you need the public key (which can be generated from the private key).
cosign verify --key cosign.pub docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG | jq .
The image signature created using cosign can be viewed on Cloudsmith by selecting the docker image and going to the Info tab. The signature will be listed as SIG under cosign manifests.
Cosign also has built-in support for in-toto attestations.
An in-toto attestation is authenticated metadata about one or more software artifacts, as per the SLSA Attestation Model. The in-toto spec is described here.
You can create and sign an in-toto attestation from a local predicate file using the following command:
cosign attest --predicate <file> --key cosign.key <image>
cosign verify-attestation --key cosign.pub <image>
Attributions attached to an image using cosign can be viewed on Cloudsmith by selecting the docker image and going to the Info tab. The signature will be listed as ATT under cosign manifests
The SBOM lists all components, including licenses and dependencies contained in a software product and other data, including checksums. SBOMs can be used to identify all your software components and improve supply chain security.
An SBOM in a known format like SPDX or CycloneDX can help drive automation and trigger security alerts. The end-user of software can use the SBOM to perform vulnerability and license analysis of their software packages which can help to evaluate risk in a software product.
You can host your SBOM alongside your image in Cloudsmith using sigstore/cosign tooling.
You can generate an SBOM using tooling like syft, or [trivy's SBOM generator] (https://aquasecurity.github.io/trivy/v0.27.1/docs/references/cli/sbom/).
syft docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG -o json > ./sbom.json
trivy sbom --output sbom.json --format cyclonedx docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG
To host an SBOM alongside your image, you can attach an attribution with the SBOM as the predicate.
cosign attest -predicate ./sbom.json -key ./cosign.key cosign.key docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG
cosign verify-attestation cosign.key docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG --key ./cosign.pub > ./attestation_output
And to extract the SBOM from an attestation:
The SBOM extraction specifically works for a SBOM generated using the syft command above.
cat ./attestation_output | jq --slurp --compact-output 'map(.payload | @base64d | fromjson | .predicate.Data | fromjson | select(.descriptor.name == "syft")) | first' > ./sbom.syft.json
You can also attach an unsigned SBOM:
cosign attach sbom docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG
cosign download sbom --output-file sbom.json docker.cloudsmith.io/OWNER/REGISTRY/IMAGE_NAME:TAG
Attaching SBOMs using 'cosign attach sbom' does not sign them and you will get warnings 'Downloading SBOMs this way does not ensure its authenticity'. If you want to sign the SBOM, you can use the commands above to add the SBOM as an in-toto attestation.
SBOMs attached to an image using cosign can be viewed on Cloudsmith by selecting the docker image and going to the Info tab. The signature will be listed as SBOM under cosign manifests.
Updated 5 months ago