Verifying OCI Sources' SBOM

[souleb]

With Flux HelmChart and OCIRepository CRD it is possible to define OCI artifacts as sources for the different Flux controllers. Recently we also added the possibility for users to verify the declared artifacts signatures at reconciliation time using cosign.

One next phase would be to be able to declare that a software bill of material exist for a given artifact, and expect Flux to find it and verify it.

In the following sections, we expose two possibilities to solve the use case. The intent here is not to provide a final solution, but to open the discussion and gather feedback.

1. Verify SBOM by using the referrer api

The oci-distribution-spec provides a new referrers api that we could use for that purpose. We could generate an sbom for an oci image named manifest:1.0.0 with syft like:

⋊> ~ syft manifest:1.0.0 -o json=sbom.syft.json -o spdx-json=sbom.spdx.json 

And then use oras to push the generated sbom as an OCI artifact and add a reference to the subject artifact.

oras attach manifest:1.0.0 --artifact-type application/vnd.example.sbom.v1 ./sbom.syft.json    

That would create an artifact with the following manifest:

{
  "mediaType": "application/vnd.oci.artifact.manifest.v1+json",
  "artifactType": "application/vnd.example.sbom.v1",
  "blobs": [
    {
      "mediaType": "application/json",
      "size": 1035,
      "digest": "sha256:87923725d74f4bfb94c9e86d64170f7521aad8221a5de834851470ca142da630"
    }
  ],
  "subject": {
    "mediaType": "application/vnd.oci.image.manifest.v1+json",
    "size": 10965,
    "digest": "sha256:3934df5db416893337fa3bed2efc427636bf1555fc8d538ec8c5b9180abb6e5c"
  },
  "annotations": {
    "org.opencontainers.image.created": "2022-08-08T12:30:59+03:00",
    "org.example.sbom.format": "json"
  }
}

Using the referrer api we could retrieve the sbom artifact with our source image digest like:

curl https://docker.io/v2/xxx/manifest/manifests/referrers/sha256:3934df5db416893337fa3bed2efc427636bf1555fc8d538ec8c5b9180abb6e5c?artifactType=application/vnd.example.sbom.v1 |jq
...
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "size": 1234,
      "digest": "sha256:a1a1a1...",
      "artifactType": "application/vnd.example.sbom.v1",
      "annotations": {
        "org.opencontainers.artifact.created": "2022-01-01T14:42:55Z",
        "org.example.sbom.format": "json"
      }
    }
  ],
  "annotations": {
    "org.opencontainers.referrers.filtersApplied": "artifactType"
  }
}

The result is an image index containing all the references(referenced with the subject field) to our source image manifest:1.0.0. What would be left to do for Flux is:

1. retrieve the sbom artifact.
2. verify the artifact signature if needed (this is an oci artifact and can be signed with cosign).
3. verify the sbom attestation.

Verifying the attestation means that Flux has to implement the logic or depend on another library for that.

Furthermore the referrer api is quite new and most registries do not support it yet. DockerHub is currently implementing it it seems and ACR and ECR seem also to be working on it.

Verify SBOM by using Cosign

Cosign provides capabilities to push, sign and verify sbom.

Using syft and cosign, it is possible to push and sbom in an OCI registry, colocated with the target artifact.

We generate a key pair with cosign and use --key with syft to sign the generated sbom.

⋊> ~ syft attest --key cosign.key manifest:1.0.0 -o spdx-json > manifest_1_0_0_sbom_attestation.json                                                                                       
 ✔ Parsed image
 ✔ Cataloged packages      [0 packages]

manifest_1_0_0_sbom_attestation.json attestation type is payloadType":"application/vnd.in-toto+json.Cosign can only verify attestation in the in-toto format at the moment.

We then push the signed sbom

⋊> ~ cosign attach attestation --attestation manifest_1_0_0_sbom_attestation.json .../manifest:1.0.0                                                                      
Using payload from: manifest_1_0_0_sbom_attestation.json

Cosign does this the same way it attaches a signature. It creates a manifest in the same repository which is tagged with <name>:<digest.att>, digest being our artifact's digest.

Verify the sbom as follow

⋊> ~ cosign verify-attestation --key cosign.pub --type spdxjson ...manifests:1.0.0 |jq '.payload | @base64d | fromjson | .predicate'                                      
Verification for ...manifest:1.0.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{
  "SPDXID": "SPDXRef-DOCUMENT",
  "creationInfo": {
    "created": "2022-11-16T11:26:49.499525Z",
    "creators": [
      "Organization: Anchore, Inc",
      "Tool: syft-0.60.3"
    ],
    "licenseListVersion": "3.18"
  },
  "dataLicense": "CC0-1.0",
  "documentNamespace": "https://anchore.com/syft/image/souleba/manifest-1.0.0-37bef7d3-5901-4798-a0fb-cd285e78be4e",
  "name": "...manifest-1.0.0",
  "packages": [],
  "spdxVersion": "SPDX-2.2"
}

Note cosign verify-attestation accepts a list of policies in rego or cue language that can run against the sbom for validation.

Flux integrates cosign for OCI artifact signature verification. It could extend that integration to sbom verification. That is quite appealing as that is a use case that cosign exist to address.

cc @fluxcd/core-maintainers

[souleb]

ACR supports the 1st workflow: https://learn.microsoft.com/en-gb/azure/container-registry/container-registry-oras-artifacts

[stefanprodan]

I think first we need to implement Cosign attestations so Flux users can set polices based on Issuer and Subject. Right now our keyless verification only checks for a valid log, but this doesn't protect against some bad actor signing artifacts via GH Actions.