Design: Attestation, signing, and verification
Problem and scope
Context
Part of the SLSA Compliance Epic to establish secure, verifiable software supply chain practices across the organization.
What is the problem to solve?
Organizations building and deploying containerized applications lack native capabilities to cryptographically prove that their container images are authentic, unmodified, and built from verified sources. Without signing and attestation for containers:
- Supply chain attacks can inject malicious code during the build or distribution process without detection
- Compliance requirements (SLSA Level 2-3) cannot be met for containerized workloads
- Trust boundaries between development, CI/CD, and production environments remain unverified
- Incident response lacks forensic trail to determine provenance of compromised containers
Currently, container artifact signing and verification requires external tooling, manual key management, and custom integration—creating friction, inconsistency, and security gaps across container workflows.Providing a native experience for signing and verifying container artifacts, container attestations (including build provenance and SBOM).
| Problem | Needs UI design? |
|---|---|
| Cosign execution flows - Cosign is a command line utility that allows signing, verifying, storing, and retrieving through interface with an OCI (Open Container Initiative) registry. Cosign can be used to sign attestations, or a verifiable assertion or statement about a software artifact. | No - CLI workflows |
| Making attestation and artifact signature data visible through the existing container image view in Build. | yes |
Who is the design solution for?
Primary Users:
- DevOps Engineers who build, deploy, and manage containerized applications
- Security Engineers responsible for supply chain security, compliance, and policy enforcement
- Platform Engineers managing Kubernetes clusters and container orchestration
Secondary Users:
- Compliance Teams auditing software supply chain practices
- Development Teams publishing container images to registries
What is the Job this user is trying to achieve?
User Job Statement:
"When I build and deploy container images, I need to cryptographically prove their authenticity and integrity, so that I can trust what runs in production and meet SLSA compliance requirements."
Specific Jobs-to-be-Done:
- Sign container images during CI/CD builds without managing cryptographic keys
- Generate build provenance attestations documenting how/when/where containers were built
- Attach SBOM attestations to containers for vulnerability management and compliance
- Verify container signatures before deployment to prevent tampered images from running
- Enforce attestation policies in Kubernetes admission control to block non-compliant deployments
- Audit container provenance to investigate security incidents or compliance questions
What outcomes is this design solution helping them achieve?
Security Outcomes:
- Prevent supply chain attacks by detecting tampered or unauthorized container images before deployment
- Achieve SLSA Level 2-3 compliance for containerized workloads through automated provenance and signing
- Establish zero-trust verification where every deployment validates cryptographic proof of authenticity
Operational Outcomes:
- Reduce friction in secure container workflows—signing/verification happens natively without external tools
- Centralize attestation management in existing GitLab Container Registry and UI
- Enable policy enforcement at deployment time through Kubernetes admission control
Business Outcomes:
- Meet compliance requirements (SLSA Build L2, supply chain security audits) for regulated industries
- Reduce security incident risk and associated costs from compromised containers
- Accelerate secure deployment velocity by automating trust verification
What are the requirements necessary to solve for this problem and Outcomes?
GUI Experience:
- Container attestation and signature data visible in:
- Existing container image view (Container Registry UI)
- Attestation view under Build navigation
- Signing process integrated into existing CI/CD pipeline workflows
- No manual key management required by users
Designs for discussion
| Requirement | Design concept |
|---|---|
| Container attestation and signature data visible in container registry UI |
|
| | Signing process integrated info existing CI/CD pipeline workflows (pipeline graph & job log details) | |
|
What supporting research or customer validation do we have?
Problem Validation: Understanding User Needs for SLSA
What is the timeline?
Relates to gitlab-org#19697
What are the technical constraints?
{ This is to understand initial constraints in which the design solution needs to work within, NOT whether the solution can be implemented in a given milestone.
Once the Product Designer has come up with a holistic Design Vision, or an ideal state for solving the problem, they should collaborate with their team members and engineers to continue the technical feasibility discussion during workflowplanning breakdown. }
{ e.g. All visualization must use [eCharts](https://echarts.apache.org/examples/en/index.html#chart-type-line) }{ e.g. Data prior to 2024-10-10 will not be available }{ e.g. Solution will only be visible to Maintainer roles }
In what parts of GitLab will this solution be available?
Plans:
- Free
- Premium
- Ultimate
Instances:
- Self-managed
- Dedicated
- GitLab.com
Levels:
- Instance
- Group
- Project
How will we know if the solution is successful?
User Experience Metrics:
- < 2 minutes added to build time for signing/attestation generation
- < 10 seconds for verification during deployment
- User satisfaction score of 4+/5 for signing/verification workflows
- Reduction in support tickets related to container security setup
Ready for design
See checklist
- The problem has been defined and is well understood
- Who the design solution is for has been defined
- User goals and outcomes have been defined
- Supporting research has been reviewed and linked
- The product requirements have been defined, and the scope has been agreed upon
- Success metrics have been defined and agreed upon
- I, as the Product Designer, believe I have all the information I need to begin creating a design solution
- Move this issue to ~"workflow::ready for design" or workflowdesign
🎉
(Optional) Help improve this issue template, view feedback issue
Proposal
See checklist reminder
- Follow the Product design process
- Start with a long-term vision
- Remember to link your video walkthrough, prototypes, Figma project
📺 Walkthrough🖼️ Design Solution Proposal- ❖ Figma project →
Design breakdown
Once the proposal is agreed upon, work with your team to break it down into buildable parts (MVC, Iteration 1, Iteration 2, etc... until fully built).
See checklist
- Design Vision broken down into MVC and follow-up iterations based on their ability to stand alone and provide value to the user
- Create MVC and other necessary Iteration 1, Iteration 2... issues and add them as Linked items to this issue
- Include all necessary requirements, and specs needed to create the designs for each broken down issue