Verify Kong Event Gateway image signatures and attestations

Use cosign tree to see every signature and attestation attached to an image:

cosign tree kong/kong-event-gateway:1.2.0

The output lists the supply chain artifacts (signatures and attestations) that are stored alongside the image in the registry.

1. Read the manifest digest for the image with regctl and store it in a variable:

    export IMAGE_DIGEST=$(regctl manifest digest kong/kong-event-gateway:1.2.0)
    echo $IMAGE_DIGEST

   Copied!

   This captures the image’s SHA-256 digest so you can reuse it in the commands below, and prints it:

    sha256:...

   Pinning to a digest guarantees you verify exactly the image you’re going to run, even if the tag is later moved to a different image.

2. Verify the signature with cosign verify:

    cosign verify \
      --new-bundle-format=true \
      -a repo="kong-gateway/event-gateway" \
      -a workflow="CI" \
      --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
      --certificate-identity="https://github.com/kong-gateway/event-gateway/.github/workflows/ci.yaml@refs/tags/v1.2.0" \
      kong/kong-event-gateway@${IMAGE_DIGEST}

   Copied!

   If verification succeeds, the response contains a summary of the checks that were performed:

    Verification for index.docker.io/kong/kong-event-gateway@sha256:... --
    The following checks were performed on each of these signatures:
      - The specified annotations were verified.
      - The cosign claims were validated
      - Existence of the claims in the transparency log was verified offline
      - The code-signing certificate was verified using trusted certificate authority certificates

Kong Event Gateway images carry several signed attestations. The most commonly used predicate types are:

The exact set of attestations can change between releases. Use cosign tree to see the authoritative list for the image you’re verifying.

To verify an attestation’s signature and print its contents, use cosign verify-attestation with the matching --type. For example, to verify the SPDX SBOM, run:

cosign verify-attestation \
  --type="spdxjson" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  --certificate-identity="https://github.com/kong-gateway/event-gateway/.github/workflows/ci.yaml@refs/tags/v1.2.0" \
  kong/kong-event-gateway@${IMAGE_DIGEST}

For predicate types that don’t have a built-in alias, pass the full predicate type URL to --type instead. For example: --type="https://cisecurity.org/docker/amd64".

To save the SPDX SBOM to a file, download the attestations and filter for the SBOM predicate type with jq:

cosign download attestation kong/kong-event-gateway@${IMAGE_DIGEST} \
  | jq -r 'select((.dsseEnvelope.payload // .payload | @base64d | fromjson | .predicateType) == "https://spdx.dev/Document") | (.dsseEnvelope.payload // .payload) | @base64d | fromjson | .predicate' \
  > sbom.spdx.json

This writes the SBOM document to sbom.spdx.json, which you can then feed into your SBOM tooling. To extract the CycloneDX SBOM instead, replace the predicate type with https://cyclonedx.org/bom.

Confirm that the extracted file is valid JSON and contains the expected SPDX fields:

jq -e '.spdxVersion and (.packages | length > 0)' sbom.spdx.json \
  && echo "Valid SPDX SBOM with $(jq '.packages | length' sbom.spdx.json) packages"

If the file is a well-formed SPDX SBOM, the command prints true followed by the package count. If jq reports a parse error or the expression evaluates to false, the download or filter step didn’t produce a valid document. Re-check the predicate type and confirm the previous commands completed successfully.