Executive Summary
Software delivery pipelines are the most consequential yet consistently under-secured component of modern federal IT infrastructure. The CI/CD pipeline is where source code becomes deployed capability — the crucible through which all software passes before it reaches operational systems. It is also, for exactly that reason, the highest-value target in the software supply chain. A compromised pipeline does not merely expose one system; it compromises every system that pipeline touches, with a trust-propagation radius that can span an entire enterprise.
Executive Order 14028 on Improving the Nation's Cybersecurity made this explicit: federal agencies must adopt Zero Trust Architecture and secure their software supply chains. CISA's Zero Trust Maturity Model and NIST SP 800-207 provide the frameworks. The National Security Memorandum on Improving Cybersecurity for Critical Infrastructure extends these requirements into the defense industrial base. For federal contractors and agencies operating CI/CD pipelines in support of government programs, Zero Trust is no longer an architectural aspiration — it is a compliance mandate with a deadline.
Most federal CI/CD pipelines are built on an implicit trust model — tokens and credentials that grant broad access, service accounts with standing permissions, build environments that run arbitrary code with elevated privileges, and artifact stores with no integrity verification. Applying Zero Trust to CI/CD requires rebuilding the pipeline's trust architecture from first principles: every identity verified, every action authorized, every artifact attested, and every secret dynamically provisioned.
Why CI/CD Pipelines Are High-Value Targets
The SolarWinds attack of 2020 was a watershed moment for software supply chain security. The attackers did not breach SolarWinds' customers directly — they compromised the build pipeline and inserted malicious code into a software update that customers then downloaded and trusted. Roughly 18,000 organizations installed the backdoored update. The attack demonstrated, at devastating scale, that a compromised pipeline is worth more to an adversary than a compromised endpoint — because it delivers persistence into every downstream system simultaneously.
CI/CD pipelines in federal environments are particularly high-value targets because they serve as the delivery mechanism for software that runs on systems ranging from unclassified administrative infrastructure to mission-critical operational platforms. A pipeline that deploys code to a Space Force ground system, an Army logistics application, or a financial regulatory reporting platform carries an operational consequence profile that dwarfs any single endpoint it touches.
The Trust Problem in CI/CD
Traditional CI/CD security relies on perimeter trust: if you are inside the network and have credentials, you are trusted. This model fails catastrophically when a single token, service account, or build worker is compromised — because the blast radius of that compromise is every system those credentials can reach. Zero Trust replaces perimeter trust with continuous verification: no identity is inherently trusted, every access decision is evaluated in context, and the principle of least privilege is enforced at every step.
Applied to CI/CD, Zero Trust means: every pipeline stage must prove its identity and be authorized for each action; every artifact must be cryptographically attested and verified before deployment; every secret must be dynamically issued with minimum scope and automatically rotated; every build environment must be ephemeral and isolated; and every action must be logged to an immutable audit trail.
Federal Program Context
Continuum Resources operates CI/CD pipelines in active DoD programs — including the first Space Force Operational Acceptance under the Software Acquisition Pathway (DoD 5000.87). The practices in this paper are drawn from that operational experience, combined with our DevSecOps expertise and the published standards that now govern federal software delivery. This is not theoretical guidance — it is what Zero Trust CI/CD looks like in practice for federal programs.
Zero Trust Principles Applied to CI/CD
NIST SP 800-207 defines seven tenets of Zero Trust Architecture. Each tenet has direct, specific implications for CI/CD pipeline design. The following maps each tenet to its pipeline-specific implementation requirement — the translation from principle to practice that is the purpose of this paper.
Federal Policy Landscape
The Zero Trust mandate for federal CI/CD pipelines derives from an interlocking set of executive orders, agency guidance documents, and emerging contract requirements. Understanding the specific obligations each creates is essential for compliance planning.
| Policy | Issuer | Key CI/CD Requirement | Applicability |
|---|---|---|---|
| EO 14028 | White House | Zero Trust adoption, software supply chain security, SBOM, pipeline security for federal software | All federal agencies + contractors delivering software |
| OMB M-22-09 | OMB | Federal ZTA strategy — specific milestones for identity, devices, networks, applications, data; agencies must achieve defined maturity levels | Federal agencies; propagates to system contractors |
| NIST SP 800-207 | NIST | Seven ZTA tenets, architecture models (agent-based, enclave, DAAS), implementation guidance | Reference standard for all federal ZT implementations |
| CISA ZT Maturity Model | CISA | Five pillars (Identity, Devices, Networks, Applications, Data) with Traditional → Optimal maturity progression; specific CI/CD controls at each level | Framework for measuring progress; referenced in agency plans |
| NIST SP 800-218 (SSDF) | NIST | Secure Software Development Framework — practices for secure pipeline design, build environment integrity, and supply chain risk management | Federal software developers and contractors |
| SLSA Framework | Google / OpenSSF | Supply-chain Levels for Software Artifacts — 4-level provenance attestation framework now referenced in CISA and DoD guidance | Emerging DoD requirement for mission-critical software |
| CMMC 2.0 | DoD | Level 2: 110 practices aligned to NIST SP 800-171 including access control, audit, configuration management; Level 3 adds NIST SP 800-172 practices | Defense contractors handling CUI |
| NSM-8 | White House | National Security Systems — ZTA requirements for systems processing classified information; most stringent controls | NSS operators; highest-classification DoD systems |
OMB M-22-09 established fiscal year milestones for Zero Trust adoption. Agencies were required to have specific ZTA capabilities in place by end of FY2024, with full maturity targets in FY2026. Defense contractors whose pipelines deliver software to federal systems are increasingly finding ZTA requirements appearing in solicitations, task orders, and PWS language. Programs that have not begun ZTA implementation for their CI/CD pipelines are already behind the compliance curve.
CI/CD Pipeline Threat Model
Securing a CI/CD pipeline requires understanding what attackers are actually trying to accomplish and through which specific attack paths. The following threat model is structured around the pipeline's stages — each stage has a distinct attack surface and corresponding threat actors.
Top Pipeline Attack Vectors
| Attack Vector | Description | Example | Severity |
|---|---|---|---|
| Dependency Confusion | Attacker publishes malicious package to public registry with same name as private internal package; build system resolves public over private | SolarWinds, PyPI typosquatting attacks | Critical |
| Build Script Injection | Malicious code in Makefile, Dockerfile, CI YAML, or dependency install scripts executes arbitrary commands during build with pipeline credentials | XZ Utils backdoor (2024) | Critical |
| Secret Exfiltration | Build script or compromised dependency reads environment variables or mounted secrets and exfiltrates them to attacker-controlled endpoint | Travis CI token exposure incidents | Critical |
| Artifact Tampering | Attacker with registry write access modifies a signed artifact after signing validation but before deployment verification | Codecov bash uploader compromise | Critical |
| Privileged Token Theft | Long-lived deployment tokens or service account credentials stolen from configuration files, environment variables, or CI runner cache | GitHub Actions token leakage via logs | High |
| Pipeline Poisoning (PPE) | Attacker with pull request access modifies CI workflow files to execute arbitrary code in the pipeline's privileged context | GitHub Actions PR workflow attacks | High |
| Runner Compromise | Persistent build runner (non-ephemeral) is compromised via a prior build job and used to poison subsequent builds or exfiltrate secrets | Persistent runner credential caching | High |
| SCM Account Takeover | Developer credential compromise via phishing, password reuse, or MFA bypass gives attacker code commit capability with signing trust | Linus Torvalds key infrastructure attacks | High |
Identity & Access Management for Pipelines
Identity is the foundation of Zero Trust — CISA's ZT Maturity Model places Identity as the first pillar, and for CI/CD pipelines it is the most critical. Pipeline security fails when any of three identity categories are inadequately managed: human identities (developers, operators), machine identities (service accounts, runners), and workload identities (individual pipeline jobs, agents, containers). All three must be managed with the same rigor.
Human Identity Controls
- Phishing-resistant MFA mandatory: FIDO2/WebAuthn hardware keys or platform authenticators for all accounts with SCM access. TOTP-based MFA is insufficient for federal programs; OMB M-22-09 requires phishing-resistant MFA for all privileged access by FY2024.
- Role-based branch protection: Every SCM repository enforces branch protection requiring minimum two-person review, signed commits, and status check passage before merge to protected branches. No developer has direct push to main or release branches.
- Commit signing enforced: All commits to protected repositories must be signed with developer GPG keys or SSH signing keys registered in the organization's key management system. Unsigned commits are rejected at the SCM layer.
- Privileged access workstations: Developers with access to production pipeline configuration use designated hardened workstations with endpoint detection, full-disk encryption, and no local admin privileges — consistent with CISA ZT Devices pillar requirements.
- Just-in-time elevation: Access to pipeline administration, secret management interfaces, and deployment authorization requires just-in-time elevation through a PAM system — no standing privileged access for human identities.
Machine Identity: Replacing Long-Lived Tokens with OIDC
The single highest-impact change a federal CI/CD program can make is replacing long-lived service account tokens with OIDC-based workload identity. This eliminates the class of attack where a static token — once stolen — grants persistent access indefinitely. Modern CI/CD platforms (GitHub Actions, GitLab CI, Tekton) support OIDC token exchange natively: the pipeline job authenticates to the identity provider, receives a short-lived token scoped to the specific job's permissions, and exchanges it for cloud provider or vault credentials that expire at job completion.
- No stored secrets: The pipeline never stores cloud credentials or vault tokens in environment variables, files, or the CI system's secret store. Credentials are dynamically issued at runtime and expire at job completion.
- Job-scoped permissions: Each pipeline job receives only the permissions required for that specific job — a build job can pull from a private registry but cannot push to production; a deploy job can push to a staging environment but not production without a separate authorization step.
- Auditability: Every credential issuance is logged by the identity provider with full job context — which repository, which branch, which workflow, which commit triggered the token issuance.
- Automatic rotation: Because tokens are issued fresh per job, there is no rotation requirement — tokens are self-expiring by design.
Least-Privilege Service Account Architecture
| Pipeline Stage | Required Permissions | Prohibited Permissions | Token Lifetime |
|---|---|---|---|
| Source Checkout | Read repository (specific SHA/branch) | Write, admin, other repositories | Job duration only |
| Dependency Pull | Read internal registry (approved packages only) | Write to registry, access to prod registries | Job duration only |
| Build & Test | Read source, write build cache, read test fixtures | Network egress to internet, write to registry | Job duration only |
| Artifact Push | Write to designated staging registry path | Write to prod registry, delete operations | Job duration only |
| Deploy to Staging | Deploy to staging namespace/cluster | Access prod environment, modify cluster config | 15 minutes max |
| Deploy to Production | Deploy to prod (post approval gate) | Modify infrastructure, access secrets store directly | 10 minutes max |
Artifact Integrity & Supply Chain Security
Artifact integrity is the guarantee that the software deployed to a production system is exactly the software produced by the authorized build process — unmodified, from a known-good source, built by an authenticated identity, and verified at every stage from build to deployment. In a Zero Trust pipeline, artifact integrity is enforced cryptographically, not procedurally.
The SLSA Framework
Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") provides a graduated framework for supply chain integrity that is increasingly referenced in federal guidance. SLSA defines four levels of provenance and build integrity:
| SLSA Level | Build Requirements | Provenance Requirements | Federal Context |
|---|---|---|---|
| SLSA 1 | Build process documented | Provenance available (unsigned) | Minimum baseline — any program |
| SLSA 2 | Hosted build service; version controlled | Signed provenance from build service | EO 14028 SBOM baseline equivalent |
| SLSA 3 | Hardened build service; auditable build | Non-forgeable provenance; isolated build | CMMC L2 / IL4 programs |
| SLSA 4 | Hermetic build; two-person review required | Reproducible builds; comprehensive provenance | Mission-critical DoD / NSS programs |
Sigstore and Cosign for Federal Pipelines
Sigstore is the emerging open standard for artifact signing in cloud-native environments, now used by the Linux Foundation, Python, npm, and numerous federal-adjacent projects. Its Cosign tool enables keyless signing of container images using OIDC identity, with signatures stored in a public transparency log (Rekor) that provides non-repudiation without requiring key management infrastructure.
For federal programs requiring air-gapped or classified environments, Sigstore can be deployed as an internal instance — the same cryptographic guarantees, none of the external dependencies. Continuum has implemented internal Sigstore deployments for DoD programs where external transparency logs are not acceptable.
Software Bill of Materials (SBOM)
EO 14028 mandates SBOM generation for software sold to the federal government. An SBOM is a complete, machine-readable inventory of all components in a software artifact — direct dependencies, transitive dependencies, and their versions. For Zero Trust CI/CD, SBOM is a security control, not just a compliance deliverable:
- Automated vulnerability correlation: SBOMs are continuously scanned against NVD, OSV, and CISA KEV feeds. When a new vulnerability is published, automated tooling immediately identifies every deployed artifact containing the vulnerable component.
- Policy gate enforcement: SBOMs are evaluated against a policy engine (e.g., OPA) before deployment. Artifacts containing components with CVSS scores above a threshold, components on CISA KEV, or unlicensed components are blocked from deployment without exception approval.
- Dependency provenance: SBOMs include download source and integrity hash for every component — enabling detection of dependency confusion attacks where a component was sourced from an unexpected registry.
Secret Management in Zero Trust Pipelines
Secrets — API keys, database credentials, TLS certificates, signing keys, deployment tokens — are the most targeted data class in CI/CD pipelines. The 2022 Codecov breach, the 2023 CircleCI incident, and numerous GitHub Actions token exposure events all share a common root cause: static secrets stored in ways that were accessible to attackers. Zero Trust secret management eliminates static secrets from the pipeline entirely where possible, and strictly controls the few that remain necessary.
Vault Architecture for Federal Pipelines
A secrets management platform (HashiCorp Vault, AWS Secrets Manager, or equivalent FedRAMP-authorized service) provides dynamic secret generation, short-lived credential issuance, automatic rotation, and comprehensive access auditing. The architecture for federal CI/CD should implement three vault tiers:
Secret Scanning and Leak Prevention
Despite best practices, secrets occasionally appear in code. Pre-commit hooks using tools like Gitleaks or detect-secrets scan every commit for patterns matching known secret formats before they reach the remote repository. At the CI level, a mandatory secret scanning stage runs against every build. For federal programs, any detected secret triggers an automatic incident response workflow — the secret is immediately revoked, not merely removed from the repository.
Network Segmentation & Micro-Perimeters
Zero Trust does not eliminate network security — it redefines its role. Rather than a perimeter that separates "inside" from "outside," the network in a ZT architecture enforces micro-perimeters around each pipeline component, ensuring that a compromise of one component cannot be laterally exploited to reach others. CISA's ZT Maturity Model identifies the Network pillar as requiring isolation of pipeline workloads, encrypted intra-pipeline communication, and network-level policy enforcement aligned to workload identity.
Pipeline Network Architecture
- Isolated build namespaces: Each CI job executes in an isolated Kubernetes namespace (or equivalent) with its own network policy. A build job for Repository A cannot communicate with the network resources of a build job for Repository B — lateral movement between concurrent builds is blocked at the network layer.
- Egress allowlisting: Build environments have no default internet egress. All external access — to package registries, artifact stores, external APIs — is allowlisted by destination and protocol. Unexpected egress (a build job attempting to contact an external IP not on the allowlist) triggers immediate alert and job termination.
- Service mesh with mTLS: Internal pipeline service-to-service communication (runner to Vault, deployer to registry, agent to SIEM) uses a service mesh (Istio, Linkerd) with mutual TLS. No plaintext service communication. Certificate rotation is automated; expired certificates fail closed rather than open.
- Air-gap capability for classified builds: Pipelines processing classified or sensitive workloads are physically segmented from pipelines handling unclassified work. No shared infrastructure, no shared credentials, no shared registries between classification levels. This is a physical requirement, not a logical one.
Software-Defined Perimeter for Remote Developers
Federal program developers accessing CI/CD systems remotely must do so through a Software-Defined Perimeter (SDP) or Zero Trust Network Access (ZTNA) solution — not through traditional VPN. ZTNA verifies device health, identity, and behavioral context before granting per-application access, and continuously re-evaluates the access decision throughout the session. This eliminates the "VPN as trusted network" assumption that has been exploited in numerous federal breaches.
Traditional VPN grants broad network access to an authenticated user — effectively extending the "trusted inside" perimeter to remote locations. ZTNA grants access only to specific applications, evaluated per-session against device health, identity context, and behavioral baseline. For federal CI/CD, ZTNA means a developer can access the SCM and artifact registry they need without being granted network-level access to production systems, secret stores, or other developers' project namespaces.
Runtime & Container Security
Zero Trust does not end at deployment — it extends into the runtime environment where deployed artifacts execute. Container security, Kubernetes admission control, and runtime behavioral monitoring are the runtime expression of Zero Trust principles: verify the workload's identity and integrity at execution time, enforce minimum privilege for running containers, and detect behavioral anomalies that indicate compromise or misuse.
Admission Control and Policy Gates
Kubernetes admission controllers (OPA/Gatekeeper, Kyverno) enforce policy at deployment time — the last line of defense before an artifact enters the runtime environment. Federal CI/CD programs should implement admission policies that enforce:
- Images must come from approved internal registries only — no direct pulls from public Docker Hub or untrusted sources
- Images must have a valid Cosign/Sigstore signature from the CI pipeline's signing key
- Images must not run as root; non-root user and non-privileged security context required
- Images must have a current SBOM with no CVSS 9.0+ vulnerabilities or CISA KEV components
- Pod specifications must define resource limits — no unbounded CPU or memory access
- Read-only root filesystems required for all production workloads
- Network policies must be present — pods without explicit network policy are denied egress
Runtime Behavioral Monitoring
Even a perfectly signed, policy-compliant container can behave maliciously at runtime — through a zero-day vulnerability, a logic bomb, or an adversarial input that triggers unexpected execution paths. Runtime security tools (Falco, Sysdig, Aqua) monitor container system calls against a behavioral baseline, alerting on anomalies such as unexpected network connections, file system writes to read-only paths, new process spawning, or privilege escalation attempts. For federal programs, runtime alerts feed directly to the SIEM for correlation with pipeline-level telemetry.
Ephemeral Build Environments
Every CI build job must run in an ephemeral, clean environment that is created at job start and destroyed at job completion. Persistent build runners — runners that persist between jobs — are a Zero Trust violation: they accumulate state, cached credentials, and artifacts from previous builds that can be accessed by subsequent builds. Ephemeral runners eliminate this attack surface by design. Cloud-native CI platforms and Kubernetes-based runner controllers (GitHub Actions Runner Controller, GitLab's operator) provide ephemeral runner support natively.
Observability, Audit & SIEM Integration
Zero Trust without observability is not Zero Trust — it is Zero Trust theater. The policy enforcement decisions, identity verifications, access grants, artifact operations, and runtime behaviors of a ZT pipeline must be continuously collected, correlated, and analyzed. The NIST SP 800-207 Tenet 7 requirement — "Collect as much information as possible about the current state of enterprise assets, network infrastructure, and communications" — mandates comprehensive observability as a ZT requirement, not an operational luxury.
Pipeline Telemetry Architecture
| Telemetry Source | Events Captured | Retention | SIEM Use Case |
|---|---|---|---|
| SCM (Git/GitHub/GitLab) | Commit events, PR actions, branch operations, access grants, failed authentication | 1 year minimum | Insider threat detection, unauthorized code changes, access pattern anomalies |
| CI Orchestrator | Job start/completion, runner assignment, artifact pulls/pushes, secret accesses, environment variable access | 1 year minimum | Build anomaly detection, secret access anomalies, runner behavior baselines |
| Vault / Secrets Manager | Every secret access — who, what secret path, from which workload, timestamp, credential issued TTL | 3 years (federal) | Credential abuse detection, unauthorized secret access, lateral movement indicators |
| Artifact Registry | Image push/pull/delete, tag mutations, signature verifications, scan results | 3 years minimum | Artifact tampering detection, unauthorized registry access, image provenance audit |
| Kubernetes API Server | All API calls — deployments, config changes, RBAC changes, pod exec, admission decisions | 1 year minimum | Privilege escalation detection, unauthorized workload changes, admission policy violations |
| Runtime (Falco) | Container system calls — file opens, network connections, process spawns, privilege operations | 90 days hot, 1 year cold | Behavioral anomaly detection, malware detection, data exfiltration attempts |
| Identity Provider (IdP) | Authentication events, MFA use, token issuance, failed auth, suspicious login patterns | 3 years (federal) | Account compromise detection, credential stuffing, impossible travel alerts |
Federal SIEM Requirements
Federal programs are subject to CISA's Continuous Diagnostics and Mitigation (CDM) program, which requires agencies and their contractors to feed security telemetry to CDM dashboards. For CI/CD pipelines, this means pipeline telemetry must be formatted and routed to meet CDM data requirements — not just stored locally. Additionally, CMMC Level 2 requires a SIEM capable of correlating events across the pipeline, generating alerts for defined suspicious patterns, and supporting incident response investigation.
Interactive Compliance Mapper
The following compliance mapper lets you track implementation status of Zero Trust CI/CD controls against the major federal standards. Select your applicable frameworks using the tabs, then mark each control as Implemented, Partial, N/A, or leave it as a gap. The progress bar reflects your overall compliance posture across all marked items.
Zero Trust CI/CD Maturity Assessment
The CISA Zero Trust Maturity Model defines a progression from Traditional (implicit trust) through Advanced to Optimal (full ZT enforcement). The following assessment maps that progression to the five CI/CD-specific capability domains, allowing organizations to self-assess their current maturity, identify gaps, and prioritize investments. Rate each capability from 1 (Traditional) to 4 (Optimal) by clicking the dots.
Implementation Roadmap
Zero Trust CI/CD implementation is a phased journey, not a rip-and-replace event. The following 18-month roadmap reflects Continuum's delivery methodology, sequenced to maximize security improvement per implementation effort while maintaining pipeline availability and minimizing disruption to ongoing program delivery.
Enumerate all pipelines, service accounts, stored secrets, and tokens. Conduct threat model assessment. Identify all static long-lived credentials. Enable MFA for all SCM accounts. Implement commit signing. Deploy secret scanning pre-commit hooks. These actions eliminate the most exploited vulnerabilities with minimal pipeline disruption.
Deploy the secrets management platform. Migrate pipeline stages from static credentials to OIDC-based dynamic credential issuance. Implement per-stage least-privilege service accounts. Replace long-lived tokens with short-lived, automatically expiring OIDC tokens. This phase eliminates the credential theft attack class.
Implement artifact signing (Cosign/Sigstore or equivalent). Deploy SBOM generation and automated vulnerability scanning. Implement OPA admission control for artifact verification at deploy time. Migrate build environments to ephemeral runners. Implement network micro-segmentation and egress allowlisting. Achieve SLSA 3 for all priority pipelines.
Integrate all pipeline telemetry into SIEM. Deploy runtime behavioral monitoring (Falco or equivalent). Implement anomaly detection for pipeline behavior baselines. Connect to CDM feeds for federal programs. Deploy runtime admission policies (read-only root FS, non-root containers). Achieve CMMC Level 2 audit trail requirements.
Pursue SLSA 4 for mission-critical pipelines. Implement reproducible builds. Deploy continuous pipeline security testing (automated red-team exercises against the pipeline itself). Establish governance structure for ZT pipeline policy — quarterly review, annual red-team, documented exception process. Prepare ATO documentation package for the pipeline's security posture.
The Continuum Approach
Continuum Resources has operated CI/CD pipelines in active DoD programs for over eight years — including the first Space Force Operational Acceptance under the Software Acquisition Pathway. Our DevSecOps practice is not a service offering built around a vendor tool stack — it is a delivery methodology refined through real program experience, documented in the process of earning some of the most rigorous software delivery validations in the federal government.
Zero Trust for CI/CD is not a product Continuum sells. It is an architecture Continuum has built, operated, defended, and continuously improved in environments where the security requirements are defined by DoD directives, DISA STIGs, and program-specific ATOs. When we implement OIDC workload identity, ephemeral runners, Cosign artifact signing, or SIEM integration for a client program, we are applying patterns we have already proven operational.
- ZT Pipeline Assessment: Gap assessment of current CI/CD pipelines against the ZT controls in this paper, mapped to EO 14028, NIST SP 800-207, CISA ZTM, and CMMC requirements. Deliverable: prioritized remediation roadmap with effort estimates and risk ratings.
- Pipeline Design & Implementation: End-to-end design and delivery of ZT-native CI/CD pipelines — OIDC identity, Vault secret management, artifact signing, SBOM generation, admission control, ephemeral runners, and SIEM integration. Built to the program's specific classification level and compliance requirements.
- ATO Documentation Support: Development of the pipeline security documentation package required for Authority to Operate — system security plan sections, control implementation statements, configuration baselines, and continuous monitoring procedures.
- DevSecOps Maturity Assessment: Independent assessment of a program's DevSecOps maturity against CISA ZTM, DISA DevSecOps Fundamentals Guide, and DoD Software Acquisition Pathway requirements. Supports program management reporting and audit readiness.
- Automated Testing Integration: Continuum's Automated Testing capability (see companion white papers) integrates directly with ZT CI/CD pipelines — security testing, functional testing, and compliance testing as native pipeline stages with policy-gated deployment decisions.
- Continuous Security Program: Ongoing pipeline security management including quarterly configuration reviews, pipeline red-team exercises, vulnerability remediation SLA management, and ZT policy governance support.
Engagement Models
| Engagement | Scope | Duration | Outcome |
|---|---|---|---|
| ZT Pipeline Assessment | Current state gap analysis against ZT controls; threat model; risk-prioritized remediation roadmap | 3–4 weeks | Documented gaps, risk ratings, implementation roadmap, ATO gap analysis |
| Pipeline Hardening Sprint | Implementation of Phase 1–2 controls (identity, secrets, branch protection) on existing pipelines | 6–8 weeks | OIDC workload identity, Vault deployment, MFA enforcement, secret scanning active |
| Full ZT Pipeline Build | End-to-end ZT-native pipeline delivery for a program — all five phases of the roadmap | 12–18 months | Fully compliant ZT pipeline with ATO documentation, SIEM integration, and governance |
| DevSecOps Continuous Support | Ongoing pipeline security management, quarterly reviews, pipeline red-team exercises | Ongoing | Sustained ZT posture with documented security history for ATO maintenance |
Conclusion
The CI/CD pipeline is the single point through which all software passes on its way to operational systems. A Zero Trust architecture for that pipeline — verified identities at every stage, cryptographically attested artifacts, dynamically issued secrets, isolated build environments, and comprehensive observability — is not a security enhancement. It is the minimum viable security posture for any federal program whose pipeline produces software that operates in a threat environment.
The regulatory mandate is clear: EO 14028, OMB M-22-09, and the CISA Zero Trust Maturity Model have established the requirement. The technical path is available: OIDC workload identity, Vault-based dynamic secrets, Sigstore artifact signing, and Kubernetes-native admission control are mature, well-documented, and deployable today. The SLSA framework provides a measurable progression from current-state to full supply chain integrity attestation. What remains is the organizational will to prioritize pipeline security with the same rigor applied to endpoint and network security — and to begin before the compliance deadline, not after it.
Ready to Build a Zero Trust Pipeline?
Contact Continuum Resources for a complimentary ZT Pipeline Assessment tailored to your program's classification level, compliance requirements, and current DevSecOps maturity.
Get in Touch →References
- [EO-14028] Executive Order 14028 — "Improving the Nation's Cybersecurity" — White House, May 12, 2021. The foundational mandate for Zero Trust adoption and software supply chain security in federal programs.
- [OMB-M-22-09] OMB Memorandum M-22-09 — "Moving the U.S. Government Toward Zero Trust Cybersecurity Principles" — January 2022. Federal ZTA strategy with FY-specific milestones.
- [NIST-800-207] National Institute of Standards and Technology — "Zero Trust Architecture" — SP 800-207, August 2020. The definitive technical reference for Zero Trust architecture implementation.
- [CISA-ZTM] CISA — "Zero Trust Maturity Model v2.0" — April 2023. Five-pillar maturity progression framework for federal ZTA implementation.
- [NIST-800-218] National Institute of Standards and Technology — "Secure Software Development Framework (SSDF) v1.1" — SP 800-218, February 2022. Practices for secure pipeline design referenced in EO 14028 implementation guidance.
- [SLSA] OpenSSF / Google — "Supply-chain Levels for Software Artifacts (SLSA)" — slsa.dev, 2023. Four-level artifact provenance framework referenced in federal supply chain guidance.
- [SIGSTORE] Sigstore Project — "Sigstore: A Non-Profit, Public Good Artifact Signing and Transparency Service" — sigstore.dev, 2023. The keyless signing standard for container artifacts.
- [CMMC-2] Department of Defense — "Cybersecurity Maturity Model Certification (CMMC) 2.0" — 32 CFR Part 170, October 2024. Three-level certification framework for defense contractors handling CUI.
- [DISA-DEVSECOPS] DISA — "DevSecOps Fundamentals Guide" — October 2021. DoD guidance for secure software delivery pipeline implementation.
- [NIST-SSCS] National Institute of Standards and Technology — "Cybersecurity Supply Chain Risk Management Practices" — SP 800-161r1, May 2022.
- [CR-01] Richardson, K.A. — "WP-CR-2025-01: Agentic AI in Mission-Critical Environments" — Continuum Resources, 2025. Agentic AI security architecture that relies on ZT CI/CD for pipeline delivery.
- [CR-04] Richardson, K.A. — "WP-CR-2025-04: Prompt Injection & Adversarial Attacks on LLM Systems" — Continuum Resources, 2025. Adversarial threat model for AI systems delivered via ZT pipelines.