Attestations

[yizha1]

Is your feature request related to a problem?

Description

An attestation is a cryptographically signed collection of claims related to one or more software artifacts. According to SLSA, an attestation consists of authenticated statements about a software artifact or a collection of software artifacts. Examples include signed provenance files or signed SBOM files for container images. Attestations are crucial for ensuring the security and trustworthiness of the software supply chain.

Attestations are typically involved in the processes of creating attestations for software artifacts and verifying them before using the corresponding software artifacts. For instance, users generate SBOM attestations for container images in CI/CD pipelines and verify these attestations at admission control before deploying the container images on K8s clusters.

In-toto attestations are popular in the cloud-native ecosystem as part of the in-toto framework, which is designed to secure the integrity of software supply chains. You can find existing vetted predicates. Below are some examples of their adoption:

• GitHub artifact attestations
• SLSA attestations

To adopt in-toto attestations, the following open issues should be considered by the Notary Project community:

• Unsupported Envelope Type: In-toto attestations utilize the DSSE envelope and do not support the Notary Project signature envelopes such as JWS/COSE.
• Performance concern: Since the attestation includes the payload, large payload sizes (e.g., an SBOM for a Windows image, which could be hundreds of megabytes) can lead to performance issues during attestation download and verification.

Request

This issue requests the Notary Project to identify scenarios, create specifications, and provide reference implementations for attestations, including:

• Scenarios for using attestations throughout the cloud-native secure supply chain.
• Notary Project specification of the attestation format and storage in OCI-compliant registries.
• Notary Project specification of workflows for creating and verifying attestations.
• Reference implementation (Notation) of Notary Project attestation specifications including CLI specifications
• Integration of Notary Project attestation tooling into popular CI/CD pipelines.

Your comments are welcome.

[bureado]

Is the scenario for this that the trust policy can describe expectations from an attestation which then notation verify can pull and evaluate?

If so, I'm interested in whether the Notary Project sees this as in scope for tools like notation, or rather if it's more in scope for tools like ratify

[yizha1]

@bureado It is not only for verification scenarios. It is to define an e2e scenario including sign, store, publish and verify attestations. For example, which "attestation" format to be used, using detached signatures or following in-toto attestations; how to publish attestations throughout filesystem and OCI registries; how to verify attestations, and etc. I will create a proposal in near future.

For Ratify, it could mean more, for example, support validating in-toto attestations, Notary Project attestations (could be a variant of in-toto attestation as well)