Attestation, Signing, and Verification for Images/Containers
## Executive Summary
This will enable a native experience for signing and verifying containers artifacts, container attestations (including build provenance and SBOM). This is the next iteration of the same work being completed for job artifacts.
#### Engineering Assessment
The implementation will leverage previous work to include cosign and attestation storage. Various cosign execution flows will be used to achieve this output. The output of attestation and artifact signing will be within OCI compliant Container registry, which could include GitLab Container registry or other customer provided.
Attestation and artifact signature data will be visible through the existing container image view in addition to attestation view under the build Nav once work is completed.
### Signing & Attestation
```mermaid
graph TB
%% Input sources
CI[Container Image] --> TCP[Trusted Control Plane <br/> *Rails backend*<br/>cosign execution flows]
SBOM[SBOM] --> TCP
%% Trusted Control Plane processing
TCP --> |generates| BP[Build Provenance<br/>Attestation]
TCP --> |generates| SA[SBOM<br/>Attestation]
TCP --> |generates| CS[Container<br/>Signature]
%% Output destinations
BP --> AS[Attestation Storage]
SA --> AS
CS --> AS
CS --> OCR[OCI Container Registry<br/>GitLab Container Registry<br/>or Customer Provided]
BP --> OCR
SA --> OCR
%% Styling
classDef input fill:#e1f5fe
classDef process fill:#f3e5f5
classDef output fill:#e8f5e8
classDef attestation fill:#fff3e0
class CI,SBOM input
class TCP process
class AS,OCR output
class BP,SA,CS attestation
```
####
### Verification
```mermaid
graph TB
%% OCI Registry with stored artifacts
OCR[OCI Container Registry<br/>GitLab Container Registry<br/>or Customer Provided]
%% Stored artifacts in registry
OCR --> |contains| CI[Container Image]
OCR --> |contains| CS[Container Signature]
OCR --> |contains| BP[Build Provenance<br/>Attestation]
OCR --> |contains| SA[SBOM Attestation]
%% Verification clients
GLAB[glab<br/>GitLab CLI] --> |queries| OCR
KAC[Kubernetes<br/>Admission Controller] --> |queries| OCR
%% Cosign library usage
GLAB --> |uses| CL1[cosign libraries<br/>signature validation<br/>attestation verification]
KAC --> |uses| CL2[cosign libraries<br/>signature validation<br/>attestation verification]
%% Verification processes
CL1 --> |validates| CS
CL1 --> |verifies| BP
CL1 --> |verifies| SA
CL2 --> |validates| CS
CL2 --> |verifies| BP
CL2 --> |verifies| SA
%% Verification outcomes
CL1 --> VR1[Verification Result<br/>CLI Output]
CL2 --> VR2[Admission Decision<br/>Allow/Deny Deployment]
%% Styling
classDef registry fill:#e3f2fd
classDef artifact fill:#fff3e0
classDef client fill:#e8f5e8
classDef library fill:#f3e5f5
classDef result fill:#fce4ec
class OCR registry
class CI,CS,BP,SA artifact
class GLAB,KAC client
class CL1,CL2 library
class VR1,VR2 result
```
#### Dependencies
- Team dependencies: ~"group::container registry" as FYI, for OCI based storage for attestations/signature.
- Epic/Issue dependencies - _Link to dependent epics/issues via the linked items widget below for ease of drill down_
- External dependencies: None identified
#### DRIs
- **PM**: `@jocelynjane`
- **EM**: `@ken.mcdonald`
- **UX/PDM**: `@jmandell`
- **Group(s)**: ~"group::pipeline security"
- **Engineering Owner**: `@mmishaev`
#### Initiative Driver - Product or Engineering?
- [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment
- These initiatives require a Product Priority label (P1/P2/P3)
- They may also receive GTM tier labels (T1/T2/T3) for external communication
- [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components
- These initiatives require an Engineering Priority label (E1/E2/E3)
- They have internal visibility only and are not externally communicated
- Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades
---
### Hygiene Guidelines
:bulb: \_See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/
##### :one: Pre-Interlock
- [x] Update epic description with all relevant information
- [ ] Ensure all dependencies are identified
- [x] Apply appropriate labels (see below)
- [ ] Apply target delivery Milestone
- [ ] Update interlock status as discussions progress (via label)
##### :two: Post-Interlock: once quarter begins
- Update health status weekly (via label)
- Document any newly identified risks or dependencies
- Link to implementation epics/issues as work begins
- Flag any scope or timeline changes immediately
<!--Apply appropriate labels:
- [x] Section (section::dev, section::ops, section::sec)
- [x] Stage (devops::plan, devops::create, devops::verify, etc.)
- [x] Group (group::product planning, group::project management, etc.)
- [x] Interlock Priority (Product labels = Interlock Priority::P1, Interlock Priority::P2, Interlock Priority::P3, Engineering labels = Interlock Priority::E1, Interlock Priority::E2, Interlock Priority::E3)
- [x] Investment theme (Investment theme::Core-Devops, Investment theme::Security-Compliance, Investment theme::AI across SDLC)
- [x] Platforms (platform: GitLab.com, platform: dedicated, platform: dedicated for gov, platform: self-managed)
- [x] Subscription tier (GitLab Ultimate, GitLab Premium, GitLab Free)
- [x] Quarter (FY27 Q1, FY27 Q2, FY27 Q3, FY27 Q4)
- [x] Pre-interlock status label (interlock status::New/Proposal in progress, interlock status::cancelled, etc)
- [ ] Post-interlock status label (R&D roadmap status::Executing, R&D roadmap status::Completed)
- [ ] Post-interlock, once quarter begins update health weekly (health::on track, health::needs attention, health::at risk)
*For guidance on labels, see the [labels guide here](https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/#labels-guide)-->
epic