### Problem to solve refer epic for more details https://gitlab.com/groups/gitlab-org/-/epics/15857 The software supply chain is highly vulnerable to attacks, especially during the build process where malicious actors can tamper with the code or build environment to introduce backdoors, malware, or other forms of compromise. To ensure integrity and authenticity, it's crucial to generate attestation (provenance) for each build in a way that prevents forgery or tampering. This is a core requirement of SLSA (Supply-chain Levels for Software Artifacts) Level 3 compliance. However, without proper in-pipeline attestation generation, developers lack visibility into the build process and cannot easily verify that an artifact has been built securely. This undermines trust in the artifacts produced and weakens the overall security posture. ### Proposal This proposes a multi-stage approach to SLSA L3 compliance that minimizes the time to MVP and which should work independently of the GitLab deployment mechanism. This ultimately advocates long-term for a hybrid approach: a pure Runner-initiated approach cannot collect as granular of data without some form of build instrumentation like what the OpenSSF team has performed. However, further hardening of the GitLab pipeline platform (such as via Runner Identity or supporting organization-owned long term attestation keys) still can be performed. This epic is limited to [job artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/). It doesn't cover SLSA provenance attestation for images and packages built by CI/CD jobs. https://gitlab.com/groups/gitlab-org/-/epics/15858#note_2514305304