PS Product SecurityKnowledge Base

🧱 Secure Build Factory, Artifact Signing, and 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

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.