Fabien Joubert

CI/CD as a Control Plane in Regulated Environments

6 min read

This article draws from practical experience working in regulated and high-compliance environments.

Executive Summary

CI/CD is part of the system’s trust boundary.

In regulated environments, integrity must be engineered, not assumed.

This requires immutability, deterministic builds, verifiable provenance, strict identity controls, and explicit trust boundaries.

Introduction

Continuous Integration and Continuous Delivery (CI/CD) pipelines are commonly presented as mechanisms to accelerate software delivery. They automate builds, testing, and deployment workflows, and are often perceived as operational tooling external to the system itself.

In regulated and high-compliance environments, this perception is incomplete.

A CI/CD pipeline determines which source code is transformed into executable artifacts, how those artifacts are built, and under which conditions they are deployed. It interacts with source repositories, dependency ecosystems, artifact registries, identity systems, and production infrastructure. A compromise of the pipeline frequently implies compromise of the delivered system.

Recent supply chain incidents have demonstrated that build systems and dependency chains represent high-value attack surfaces.1 Integrity must therefore encompass the entire path from source commit to deployed binary, rather than being limited to application logic.

Regulated environments introduce formal constraints: artifacts must be traceable, builds reproducible, actions attributable, and evidence preserved. In such contexts, CI/CD must be engineered for defensibility as well as delivery.

CI/CD as a Supply Chain System

A modern pipeline operates as a distributed system embedded within a broader software supply chain. It coordinates:

  • source retrieval
  • dependency resolution
  • build execution
  • artifact storage
  • deployment automation

Each transition introduces a boundary across which trust must be evaluated.

Dependencies

Applications rely on external packages, container base images, build plugins, and transitive dependencies. If dependencies are dynamically resolved without strict version control, upstream compromise can silently alter downstream artifacts. Dependency poisoning and namespace confusion attacks illustrate this risk.

Build Infrastructure

Build runners and orchestration systems often execute with elevated privileges and access to sensitive credentials. Shared or insufficiently isolated runners increase the likelihood that compromise in one workload propagates to others.

Artifact Registries

Artifact registries distribute binaries across environments. If artifacts can be overwritten or modified without cryptographic verification, traceability and rollback guarantees collapse.

Deployment Automation

Deployment systems frequently hold privileged access to production clusters or infrastructure APIs. At this stage, the pipeline functions as part of the system’s control plane.

Collectively, these components form a chain of trust relationships rather than a simple automation script.

Threat Model Reconsidered

When CI/CD is viewed as a supply chain coordinator, the threat model expands beyond application vulnerabilities. Structural attack surfaces include:

  • unverified or floating dependencies
  • compromised build runners
  • mutable artifact references
  • overprivileged pipeline credentials

These attack surfaces are well documented in recent supply chain incidents. The relevant question shifts from “Can the application be exploited?” to “Can the artifact production path be subverted?”

Implicit assumptions (trusted runners, safe internal networks, immutable registries) must be replaced with explicit guarantees.

Regulatory and Compliance Constraints

Regulatory frameworks such as NIST SSDF (SP 800-218)2, NIST SP 800-533, and ISO/IEC 270014 impose structural requirements on software delivery systems. These standards do not mandate tools; they mandate properties.

Traceability

Every deployed artifact must be linked to:

  • a specific source commit
  • a defined set of dependencies
  • an identifiable build process

This establishes a verifiable chain of custody. Frameworks such as SLSA formalize provenance levels5, while SBOM specifications (SPDX6, CycloneDX7) describe dependency composition.

Reproducibility

Identical source and declared inputs must produce identical artifacts. This requires pinned dependencies, deterministic build processes, and controlled build environments.

Without reproducibility, integrity claims cannot be independently validated.

Accountability

Actions within the pipeline must be attributable. Strong identity management, auditable logs, and controlled approval workflows are structural requirements, not optional enhancements.

Separation of Duties

No single actor should control code creation, pipeline modification, and production deployment without oversight. Protected branches and mandatory reviews operationalize this constraint.

Evidence Preservation

Build logs, test reports, artifact digests, and approval records must be retained and protected against tampering. The objective is to enable retrospective verification of how a given artifact was built, validated, and deployed.

Ephemeral execution without durable logging undermines auditability and weakens traceability claims.

These requirements align with supply chain risk management guidance described in NIST SP 800-1618.

Engineering Principles Derived from Constraints

When translated into system design, regulatory constraints produce explicit engineering principles.

Immutability

Artifacts must be referenced by cryptographic digest rather than mutable tags. Overwriting artifacts invalidates traceability.

Determinism

Build inputs must be explicit and stable. Non-deterministic steps or floating dependencies undermine reproducibility.

Provenance

Artifacts should include verifiable metadata describing source, dependencies, and build identity. For example, SLSA Level 3 requires provenance generated by a trusted build platform, resistant to falsification.5

Least Privilege

Pipeline identities should use scoped, short-lived credentials (e.g., OIDC-based federation) rather than static secrets. Authority must be constrained to defined tasks.

Isolation

Build environments should be ephemeral and isolated from production networks, reducing blast radius and persistence risk.

Explicit Trust Boundaries

Transitions between source, build, registry, and deployment stages must enforce identity verification and artifact integrity checks.

Concrete Engineering Controls

Principles must be enforced through mechanisms.

  • Content-addressable storage and digest-based deployments (e.g., Kubernetes image references by SHA)
  • Artifact signing and verification at deployment time
  • Automated SBOM generation and provenance metadata
  • Scoped service accounts and federated identities
  • Enforced quality gates blocking progression on failure
  • Version-controlled and peer-reviewed Infrastructure as Code

These controls transform abstract guarantees into enforceable properties.

Testing as Risk Control

Testing contributes to structural risk reduction.

Unit tests validate local correctness but do not guarantee supply chain integrity. Integration and end-to-end tests validate artifact behavior under realistic conditions, reinforcing linkage between commit, build, and deployment.

Test results, logs, and coverage reports form part of the evidentiary chain demonstrating that defined validation procedures were executed.

Without reproducible builds, however, testing loses evidentiary strength.

Organizational Embedding

CI/CD systems are socio-technical constructs. Governance mechanisms must align with technical safeguards.

Documented standards, peer review, change management, and role delineation prevent concentration of authority and encode oversight into automation.

Automation does not eliminate governance; it formalizes it.

Common Anti-Patterns

Observed structural failures include:

  • automation without enforceable controls
  • mutable artifacts
  • shared credentials across environments
  • pipelines acting as privileged backdoors
  • compliance reduced to documentation without technical enforcement
  • implicit trust in internal networks

These patterns weaken guarantees while preserving the appearance of control.

Conclusion

In regulated environments, CI/CD is not peripheral automation. It is part of the system’s control plane.

A defensible pipeline enforces immutability, determinism, provenance, constrained privilege, and durable evidence. Trust does not arise from automation alone but from explicit constraints and verifiable integrity across the artifact lifecycle.

Footnotes

  1. ENISA, Threat Landscape for Supply Chain Attacks, https://www.enisa.europa.eu/sites/default/files/publications/ENISA%20Threat%20Landscape%20for%20Supply%20Chain%20Attacks.pdf ↩

  2. NIST SP 800-218, Secure Software Development Framework (SSDF), https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf ↩

  3. NIST SP 800-53 Rev.5, Security and Privacy Controls for Information Systems and Organizations, https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final ↩

  4. ISO/IEC 27001, Information Security Management Systems – Requirements, https://iso.org/standard/27001 ↩

  5. SLSA Specification v1.2, https://slsa.dev/spec/v1.2/ ↩ ↩2

  6. SPDX Specification v2.3, https://spdx.github.io/spdx-spec/v2.3/ ↩

  7. CycloneDX Specification Overview, https://cyclonedx.org/specification/overview/ ↩

  8. NIST SP 800-161r1, Cybersecurity Supply Chain Risk Management Practices, https://doi.org/10.6028/NIST.SP.800-161r1 ↩