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

The pipeline control plane can modify production. If a long-term key is compromised, an attacker may bypass every earlier approval.

CI/CD pipelines can read source code, sign artifacts, and modify production environments. A dedicated secret vault adds access control, auditing, and rotation compared with hardcoding, but leaked long-term cloud keys can still be reused. Where federation is supported, let 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 verify signature, validity, exact issuer and audience, then constrain repository/organization, trusted workflow, and protected branch or environment using claims its CI and cloud provider actually support. Decoding a JWT is insufficient, and subject formats can vary across platforms or repositories. 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; choose the shortest supported lifetime that meets the operation's needs and log issuance and use. The CI identity token and exchanged STS credential have separate lifetimes. Ending the job does not necessarily invalidate a copied cloud credential immediately; its permissions and remaining validity still matter.

Secret Scanning: Covering History and Derivatives

Server-side push protection checks supported token formats before a push enters the repository; local pre-commit checks are a separate mechanism. Coverage depends on token type, configuration, and bypass authority. 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 historical and derived copies as appropriate. Removing only the current file does not invalidate copies of the secret that have already been propagated.

Some CI systems mask registered secrets, but that behavior must be verified. 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 Makes Decisions Testable

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 needs versioning, tests, review, and rollout controls. CODEOWNERS requires corresponding branch protection or rules to enforce approval; the file alone is insufficient. Test allow, deny, missing fields, wrong types, and unavailable validators. Skipping policy execution must not mean allow. 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. Design auditable break-glass mechanisms, not permanent bypass 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 plan generation should use read-only cloud privileges where possible, but may execute providers, external data sources, or other programs and may require backend state-lock permissions. It is not a side-effect-free sandbox for untrusted IaC. Acquire write privileges separately for apply, and protect state and plan files as sensitive data.

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.

Runtime Feedback Adds Deployed 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 examines what an SBOM lists, how provenance records a build, and how signatures and verification policy determine acceptance.

References

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