9.2 Pipeline Control Plane: Short-Lived Identity, Policy as Code, and Runtime Feedback

The pipeline control plane acts as the gatekeeper to production, once a long-term key is compromised, it can bypass all prior approvals.

CI/CD pipelines can read source code, sign artifacts, and modify production environments. Storing long-term cloud keys in a secret vault merely relocates hardcoded credentials; a more secure approach is to have each job obtain short-lived, narrowly scoped credentials through a verified workload identity.

Federated Identity as a Replacement for Long-Term Cloud Keys

CI job identity token
  claims: issuer, repository, workflow, ref, environment
        ↓ cloud STS policy validation
short-lived credential scoped to one deployment action

The cloud must validate precisely the issuer, audience, repository or organization, workflow, and protected branch or environment. Validating only that the token originates from a CI platform would allow other repositories within that platform to obtain permissions.

PR jobs, build jobs, and production deployment jobs use distinct identities. Production roles should not permit arbitrary branch assumption; credentials must have a short lifespan tied to the job itself, and records must capture both the entity that acquired the credential and the events of its usage.

Secret Scanning: Covering History and Derivatives

Push protection can block known token formats before a commit, but secrets can still appear in Git history, build logs, test fixtures, caches, image layers, and artifacts. After a leak is discovered, you must first revoke or rotate the secret, then clean up its historical traces, removing only the current file does not invalidate copies of the secret that have already been propagated.

Logs default to masking registered secrets, but attackers can encode, fragment, or embed secrets into artifacts to bypass this masking. The fundamental control remains: never grant untrusted jobs access to secrets, and strictly limit job outbound traffic and artifact upload permissions.

Policy as Code Turn Decisions into Testable Inputs

Policies that can be enforced:

Production images must use digest;
Privileged containers and hostPath volumes are prohibited;
Publicly accessible services must have an owner, TLS, and rate limiting;
Artifacts must include trusted builder provenance;
Sensitive data storage must enable specified encryption and logging policies.

A policy repository requires CODEOWNERS, versioning, unit tests, and rollout controls. Begin by observing existing resources in audit mode, then block new violations, and finally remediate existing ones. A globally incorrect deny rule could prevent emergency recovery from working, therefore, design auditable break-glass mechanisms, not permanent bypasses of accounts.

Tool Execution Permissions Follow the Principle of Minimization

SAST typically requires only source code read access. SCA should not automatically execute dependency installation scripts. DAST needs restricted network access and dedicated test accounts for its test environments. IaC plans only require read access to current state and target APIs; actual apply operations require write permissions.

Third-party CI actions or plugins that execute code dependencies must be fixed to immutable revisions, subject to strict permission reviews, and sourced from verified, auditable origins. Scanners that process source code or artifacts under attacker control must themselves be regularly updated and run within isolated sandboxes.

Shift Right Incorporate Real Runtime Conditions

Runtime feedback helps identify: attack paths not covered by testing, configuration drift, actual dependency loading, abnormal permission usage, and newly emerging exploitation intelligence. It does not mean "release first, fix later" in production.

runtime event
→ artifact digest / source revision
→ owning team and threat
→ containment
→ regression test / policy / secure default

If events are only logged in SIEM and never fed back into code or platform controls, similar issues will recur. Conversely, don’t automatically treat every kernel syscall alert as a P0 development priority, each must be correlated with asset criticality, identity, network, and user impact.

Release Control Plane Validation

• Can external PRs access secrets, persistent runners, or release networks?
• Are each job’s token audience, subject, permissions, and expiration times minimized to the absolute minimum required?
• Are policy changes tested, reviewed, incrementally enabled, and safely reversible?
• Does the release system only accept verified digests, not mutable tags?
• Who is authorized to modify workflows, environment protection rules, and signing policies?
• Can runtime events trace back to the source revision, SBOM, owner, and deployment fix?

The next chapter dives into the evidence within artifacts themselves: what is contained in an SBOM, how provenance is constructed, and how signature and verification strategies determine whether a release is accepted.

References

• NIST, SP 800-218 SSDF 1.1
• OpenID Foundation, OpenID Connect Core
• OWASP, Secrets Management Cheat Sheet