# Secure Build Factory / Artifact Signing / Deployment Approval Evidence Pack

> **Intro:** The goal of a secure build factory is not only “the build passed”. The goal is to produce software artifacts in a way that can later be defended: **who built it, from what source, under which controls, with which approvals, and why the deployment was allowed**.
>
> **What this page includes**
>
> * a practical build-factory model
> * artifact signing and attestation patterns
> * deployment approval and evidence templates
> * operational checklists for teams that need auditable release controls

## The operating model

```mermaid
flowchart LR
    A[Protected Source Repo] --> B[Trusted Build Runner / Build Factory]
    B --> C[Artifact + SBOM]
    B --> D[Provenance / Attestations]
    C --> E[Registry / Artifact Store]
    D --> E
    E --> F[Policy Check / Approval Gate]
    F --> G[Deployment System]
    G --> H[Runtime Evidence / Release Record]
```

## What a secure build factory should guarantee

### Source integrity

* protected branches and review controls;
* controlled workflow changes;
* reproducible or at least well-described build path;
* builder identity separated from developer identity.

### Build integrity

* trusted runner or isolated builder;
* minimal secrets in build context;
* tamper-evident logs;
* artifact digests fixed before approval.

### Deployment integrity

* approvals tied to digest, not just tag;
* policy check against provenance, vulnerability status, and environment rules;
* release record retained as evidence.

## Evidence classes

| Evidence type                   | What it proves                                   |
| ------------------------------- | ------------------------------------------------ |
| **Commit and review record**    | source change lineage and human oversight        |
| **Build log / runner metadata** | where and how the artifact was built             |
| **Artifact digest**             | immutable content identity                       |
| **SBOM**                        | dependency inventory                             |
| **Provenance / attestation**    | builder, source, inputs, parameters              |
| **Approval record**             | who allowed promotion and under which conditions |
| **Deployment record**           | what digest actually reached which environment   |

## Artifact signing patterns

### Sign the digest, not the mutable tag

Tags move. Digests do not. Approval and policy decisions should bind to the digest or an attested subject, not just `:latest` or `:prod` tags.

### Separate signing from building when possible

A strong pattern is:

* builder produces digest + provenance;
* signing authority signs only after policy checks or under KMS/HSM-backed controls;
* deployment system verifies before promotion.

### Keep keys out of general CI where possible

Prefer:

* KMS/HSM-backed signing;
* keyless signing where supported;
* narrowly scoped signing identities.

## Practical evidence pack structure

```
release-evidence/
  01-source/
    pull-request-summary.md
    commit-range.txt
  02-build/
    build-log.txt
    runner-metadata.json
  03-artifacts/
    image-digests.txt
    sbom.spdx.json
  04-attestations/
    provenance.jsonl
    vuln-scan-attestation.jsonl
    test-attestation.jsonl
  05-approvals/
    environment-approval.md
    security-signoff.md
  06-deployment/
    deploy-record.json
    rollback-plan.md
```

## What should be enforced before production deployment

| Control             | Minimum                     | Better                                     | Strong                                                  |
| ------------------- | --------------------------- | ------------------------------------------ | ------------------------------------------------------- |
| Source protection   | branch protection           | CODEOWNERS + protected workflow files      | source + workflow provenance and admin review           |
| Build isolation     | shared runner with controls | dedicated runner group / ephemeral runners | hardened build factory with narrow network and identity |
| Artifact identity   | digest retained             | digest + SBOM                              | digest + SBOM + provenance + signature                  |
| Deployment approval | human environment approval  | approval tied to evidence checklist        | policy + evidence + break-glass logging                 |

## Operational template — approval questions

Before a production promotion, ask:

1. Which digest is being approved?
2. Was it built from a reviewed and protected source change?
3. Do provenance and builder metadata match the expected pipeline?
4. Did required tests and scans run on the same subject digest?
5. Are there unresolved blocking findings or exceptions?
6. Is rollback defined for the exact digest being promoted?

## Example finding patterns

### Finding 1 — deployment approved by tag only

> The organization used manual deployment approvals, but the approval was recorded against a mutable image tag rather than a fixed image digest. As a result, the evidence trail could not prove which exact artifact was approved and deployed.

### Finding 2 — build provenance existed but was not checked at deployment

> Provenance was generated by the build platform, but the deployment system did not verify it before promotion. This reduced provenance to passive documentation rather than an active release control.

## Anti-patterns to avoid

1. shared CI runners with broad environment access;
2. signing keys stored as generic CI variables;
3. promotion by tag only;
4. scan results detached from the final digest;
5. approval records in chat only, with no retained release artifact;
6. emergency deploys bypassing evidence capture entirely.

## Read next

* [🧩 Commit to Deployment Security — Repository, Pipeline, Runners, Secrets, Approvals, Provenance, and Release Controls](/devsecops-cicd-and-supply-chain/index-1/commit-to-deploy-security-repository-pipeline-runners-secrets-approvals-provenance-and-release-contr.md)
* [🛑 Release Governance — Security Sign-off, Quality Gates, Acceptance Criteria, and Escalation](/devsecops-cicd-and-supply-chain/index-1/release-governance-security-signoff-quality-gates-acceptance-criteria-and-escalation.md)
* [🔗 Chainloop and Supply Chain Evidence](/devsecops-cicd-and-supply-chain/index-1/chainloop-and-supply-chain-evidence.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/secure-build-factory-artifact-signing-and-deployment-approval-evidence-pack.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.