### Context There is an ongoing effort to rollout the new container registry in support of online garbage collection (see gitlab-org&5523). This is great for container images, but is not a holistic solution to managing the garbage collection of artifacts. In addition to garbage collection, we need to be looking forward to the evolving standards around Software Supply Chain Security (SSCS). See [`sigstore`](https://docs.sigstore.dev/) as the best example of this currently along with related tooling like [`cosign`](https://github.com/sigstore/cosign). It is important to store artifacts and provenance data in one place because provenance needs to be immutable and authoritative. If provenance data is stored in a separate system (like is currently the case with our Vulnerability Reports API) then your deployment policy engine must integrate and establish trust with multiple systems with differing APIs. In general, I think the way we are attempting to enforce security through MR review does not align with the complexity of Software Supply Chains and vulnerability detection. The policy enforcement point for admitting software into an environment belongs in the deployment environment itself. You might have different policies for admitting artifacts to review/staging vs production. Further, a container image that was once admitted/trusted may now contain known vulnerabilities. Organizations might want to include a TTL on their attestations to enforce continuous scanning. ### Proposal I propose that we move to storing all artifacts in the registry following the [OCI Artifacts](https://github.com/opencontainers/artifacts) specification. Such a registry would allow us to store not only container images and packages and their metadata, but also scan results, attestations, and their signatures. In other words, the full provenance for a given piece of software. ### Benefits This consolidation of artifact storage mechanisms will not only ensure that all artifact types benefit from enhancements to our registry (like intelligent expiration, hot/cold/frozen storage classes, etc). It will also vastly simplify the implementation of policy enforcement points in deployment environments (namely, Kubernetes admission controllers) because the deployment environment only needs access to one system: the registry. It would provide a general purpose artifact store where we could offload all sorts of blob storage (ex. CI metadata as noted in https://gitlab.com/gitlab-org/gitlab/-/issues/328603#note_714737903). We would even have the ability to define [fully custom `mediaType`](https://github.com/opencontainers/artifacts/blob/main/artifact-authors.md#defining-a-unique-artifact-type)(s) if so desired. Finally, n the context of proposals related to Pods, Horse, and tenancy in general (&6950), this unified architecture applied to all artifact types would make it easier for us to migrate and replicate tenant data between instances, Pods, and/or regions. On a related note, if we are able to capture all artifact metadata in the OCI image format, we wouldn't have to provide as strong of [resiliency guaruntess for the database](https://docs.gitlab.com/ee/architecture/blueprints/container_registry_metadata_database/#database) used as the metadata store. It could be thought of as a simple cache of what is in object storage and rebuilt from scratch if necessary. ### Ecosystem/Adoption The CNCF has already begun adopting these semantics in projects like Tekton (see [Tekton Bundle Contract](https://tekton.dev/docs/pipelines/tekton-bundle-contracts/)), Helm (see [HIP-0006: OCI Support](https://github.com/helm/community/blob/main/hips/hip-0006.md)), [Open Policy Agent Bundles](https://github.com/open-policy-agent/opa/issues/1464), and more. Tekton is a notable example of a CI system that was built with SSCS in mind from day one. [Tekton Chains](https://github.com/tektoncd/chains) observes all `TaskRun` executions (i.e. CI jobs) and automatically signs their results including storing/signing [the `TaskRun` definition itself as part of the attestation](https://github.com/tektoncd/chains/blob/main/docs/intoto.md). Various vendors already have [some level of support](https://github.com/opencontainers/artifacts/blob/main/implementors.md) for storing OCI Artifacts in their registries: - [Amazon ECR](https://aws.amazon.com/blogs/containers/oci-artifact-support-in-amazon-ecr/) - [Azure Container Registry](https://aka.ms/acr/artifacts) - [CNCF Distribution](https://github.com/distribution/distribution/) - [Project Harbor](https://goharbor.io/blog/harbor-2.0/) - [Quay.io](https://www.openshift.com/blog/quay-oci-artifact-support-for-helm-charts) As noted previously, [`sigstore`](https://docs.sigstore.dev/) and the related tooling they maintain appears to be on track to becoming the standard for generating/signing attestations. ### Additional References - [Supply-chain Levels for Software Artifacts (SLSA)](https://slsa.dev/), see [levels 1-4](https://slsa.dev/levels) and their respective [requirements](https://slsa.dev/requirements) - [CNCF Software Supply Chain Best Practices](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/sscsp.md) (GitHub) (or [PDF](https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf)) - Dan Lorenc (Founder & CEO, [Chainguard](https://chainguard.dev/), formerly Google) provides great context in blog posts: - [A Safer curl | bash? Why OCI?](https://blog.sigstore.dev/a-safer-curl-bash-7698c8125063#76d1) - [OCI Artifacts Explained](https://dlorenc.medium.com/oci-artifacts-explained-8f4a77945c13) - [What’s Up With OCI References?](https://dlorenc.medium.com/whats-up-with-oci-references-9d841843c3de) (Medium) - [Policy and Attestations: Best Practices for Supply Chain Security](https://dlorenc.medium.com/policy-and-attestations-89650fd6f4fa) (Medium) - [Zero Trust Supply Chain Security](https://dlorenc.medium.com/zero-trust-supply-chain-security-e3fb8b6973b8) (Medium), [slides](https://docs.google.com/presentation/d/13wiv0xXXMEmoUX0H8XgIUSH2gsLnvUTxA8_PaYPJxFw/edit#slide=id.gf2e08ce6a9_0_132) (Google Slides), [recording](https://www.youtube.com/watch?v=-VdL9d9LHIo) (YouTube) - [Software Supply Chain Security with Dan Lorenc](https://www.youtube.com/watch?v=t__f4jXEdvc) (GitLab Unfiltered - YouTube) /cc @trizzi @grzesiek