PS Product SecurityKnowledge Base

Security of the Path from Commit to Deployment

Why this page exists: the delivery path is a security boundary, not only an automation convenience. If an attacker can change source, pipeline logic, runner behavior, secrets, artifact integrity, or deployment approvals, they can often bypass large parts of the normal AppSec program.

The control-plane view

Commit to deployment security control plane

The secure-delivery path is easier to reason about if you split it into six control domains:

  1. repository — source of truth, branch protection, review, and workflow definitions;
  2. pipeline control plane — the CI system that decides what runs and under which identities;
  3. runners / execution — the actual build or test hosts where attacker-controlled code can execute;
  4. secrets and workload identity — how the pipeline gets credentials, cloud access, and signing authority;
  5. artifact integrity and provenance — how you prove what was built and whether it was modified; and
  6. release / deployment controls — who is allowed to promote, approve, override, or emergency-release to production.

What each stage is supposed to defend

Stage Main question Typical controls Common failure mode
Repository can unsafe or unreviewed change land in the source of truth? protected branches, required review, CODEOWNERS, status checks, workflow review direct push, weak review, unsafe workflow change
Pipeline control plane can someone change what the CI system executes or what it is allowed to touch? PBAC/RBAC, reusable templates, policy checks, audit logs workflow injection, over-privileged automation
Runners can hostile build code reach sensitive networks, caches, or credentials? isolation, ephemeral runners, least privilege, egress control, pinned images poisoned pipeline execution, lateral movement
Secrets / identity are credentials short-lived and tightly scoped? OIDC federation, vault-issued secrets, masked variables, environment scoping long-lived tokens, shared secrets, secret exfiltration
Artifact / provenance can we prove where the artifact came from? immutable artifact store, signatures, attestations, SBOM, digest pinning tampered artifact, untrusted rebuild, opaque release source
Release / deployment can the wrong person or process push to production? protected environments, separate approvers, change freezes, emergency path governance self-approval, bypassed gate, unlogged override

Practical baseline by control domain

1) Repository security

The repository is not just code storage; it also stores workflow definitions, IaC, deployment descriptors, and the policy hints that determine what the rest of the chain will do.

Minimum baseline:

  • protect the default branch;
  • require pull requests and independent review for protected branches;
  • require review for security-sensitive files such as workflow definitions, IaC, deployment config, and policy-as-code;
  • make the repository the single approved source of truth for releasable code.

2) Pipeline security

The pipeline control plane should decide who can trigger what, which identities the workflow receives, and which templates or components are trusted.

Minimum baseline:

  • separate the ability to edit pipeline definitions from the ability to approve production deployment;
  • centralize reusable pipeline logic where possible;
  • log privileged pipeline changes and sensitive manual triggers;
  • treat third-party pipeline integrations as part of the attack surface, not as harmless convenience plugins.

3) Runner security

Runners are where attacker-controlled code often executes. This is why runners need a stronger boundary than the CI dashboard alone suggests.

Minimum baseline:

  • prefer ephemeral runners for untrusted or mixed-trust workloads;
  • restrict network reachability from runners to only what the job truly needs;
  • avoid sharing caches, workspaces, or long-lived host credentials across trust zones;
  • pin base images and maintain a runner hardening baseline.

4) Secrets and workload identity

Long-lived pipeline secrets are one of the fastest ways to turn a build compromise into cloud, registry, or deployment compromise.

Minimum baseline:

  • prefer short-lived, federated identities over static cloud keys;
  • scope secrets to environments and jobs rather than to whole projects or organizations;
  • never let pull-request code or fork-originated code touch high-trust secrets without an explicit policy decision;
  • separate build identity, signing identity, and deployment identity where practical.

5) Provenance and artifact integrity

A releasable artifact should not only exist; it should be provable. Security teams need to know what source, workflow, and builder produced it.

Minimum baseline:

  • store release artifacts in an immutable or tightly controlled registry/repository;
  • generate and retain provenance / attestation for the build;
  • keep SBOM and verification material attached to the release record;
  • require deploy-time verification of the intended artifact digest or signature where supported.

6) Release controls and approvals

The final gate is where speed pressure often defeats security. Good release control is not only about more approvals; it is about separation of duties and auditable exceptions.

Minimum baseline:

  • protect production environments separately from normal merge rights;
  • require a release approver who is not the sole code author for the change set in the defined risk classes;
  • keep an emergency release path, but make it explicit, logged, and reviewable afterward;
  • tie approvals to evidence: tests, security checks, exceptions, and artifact identity.

Control summary mapped to widely used references

Control area Example controls Main risk reduced Useful references
Repository governance protected branches, required review, CODEOWNERS, workflow-file review insufficient flow control, unauthorized source changes NIST SSDF, OpenSSF branch-protection best practices, OWASP CI/CD Top 10
Pipeline identity and authorization RBAC/PBAC, controlled manual triggers, audited template changes misuse of CI control plane, insider and token abuse NIST SSDF, OWASP CI/CD Top 10
Runner isolation ephemeral runners, trust-zoned pools, limited egress, pinned images poisoned pipeline execution and lateral movement OWASP CI/CD Top 10
Secret handling OIDC federation, vault-issued secrets, short-lived tokens, env scoping credential hygiene failures NIST SSDF, OWASP CI/CD Top 10
Provenance and integrity signatures, attestations, SBOM, digest verification artifact tampering and unclear build origin SLSA, in-toto, NIST SSDF
Release control protected environments, approval separation, evidence-based promotion, logged override path unauthorized or unsafe production promotion NIST SSDF, secure-by-design delivery guidance

Anti-patterns worth calling out explicitly

  • letting any maintainer merge workflow changes and deploy to production with the same permission set;
  • using long-lived cloud keys in CI variables when federated identity is available;
  • treating shared self-hosted runners as a neutral platform even when hostile code executes there;
  • releasing artifacts without a durable record of source revision, builder identity, and attestation;
  • relying on “someone looked at the dashboard” instead of explicit release evidence and exception records.

Minimal review checklist

  • Is the default branch protected and subject to independent review?
  • Are workflow-definition changes controlled at least as tightly as application code?
  • Are untrusted jobs prevented from reaching privileged runners or secrets?
  • Can the organization prove what source and build produced the release artifact?
  • Are production approvals separated from ordinary code authoring and merge rights?
  • Is there a documented emergency path with retrospective review rather than a silent bypass?

Best-practice references

Keep the KB concise and link outward for deeper standards detail: