Building Secure CI/CD Pipelines for DoD Applications

The Department of War has embraced DevSecOps as the standard approach for developing and delivering software to warfighters. However, a DoD pipeline must satisfy both engineering best practices and rigorous security requirements. That makes it a fundamentally different challenge than standing up a pipeline for a commercial SaaS application. This article walks through the essential components of a secure CI/CD pipeline for DoD applications and the security tooling to integrate at each stage. It also covers the Authority to Operate (ATO) considerations that shape pipeline architecture.

The DevSecOps Imperative in Defense

Traditional software delivery in defense environments followed a waterfall model: long development cycles, monolithic releases, and security assessments conducted at the end of the process. This approach produced software that was often outdated by the time it reached operations. Moreover, security vulnerabilities discovered late in the cycle caused costly rework and schedule delays.

The DoD Enterprise DevSecOps Reference Design, published by the Department of War’s Chief Information Officer, established a new paradigm. DevSecOps integrates security into every phase of the software delivery lifecycle — from code commit through production deployment. The goal is continuous delivery of secure, mission-capable software at the speed of relevance.

Pipeline Architecture: Core Components

A DoD-compliant CI/CD pipeline typically includes these core components, each serving a specific function in the secure delivery chain.

Source Code Management (Git): All code, infrastructure definitions, and configuration must reside in a version-controlled repository. GitLab is the most widely adopted SCM platform in DoD DevSecOps environments, though GitHub Enterprise and Bitbucket are also used. Teams must control repository access through role-based permissions and sign all commits to ensure code provenance. Branch protection rules enforce code review requirements before merges to protected branches.

Build Automation (Jenkins/GitLab CI): Automated build systems compile source code, execute unit tests, and produce deployable artifacts. Jenkins remains a workhorse in many DoD environments due to its extensive plugin ecosystem and flexibility. GitLab CI/CD offers a more integrated experience for teams already using GitLab for source control. Build agents must run on hardened infrastructure and produce reproducible builds to support audit requirements.

Static Application Security Testing (SAST): Tools like SonarQube and Fortify analyze source code for security vulnerabilities, code quality issues, and compliance violations before the code is compiled. SAST scans should execute automatically on every commit or merge request. In addition, findings above defined severity thresholds should block the pipeline. SonarQube’s quality gates provide a configurable mechanism for enforcing code quality standards.

Dynamic Application Security Testing (DAST): OWASP ZAP, Burp Suite, and similar tools test running applications for vulnerabilities that SAST cannot detect. Examples include injection flaws, authentication weaknesses, and session management issues. DAST scans should run against deployed instances in staging environments before promotion to production.

Container Security in the Pipeline

Containerized deployments are the norm in modern DoD applications, and container security must be baked into the pipeline at multiple points.

Base Image Management: The DoD maintains hardened container base images through Iron Bank, a repository of DoD-approved container images that have undergone rigorous security scanning and hardening. Pipelines should pull base images exclusively from Iron Bank or equivalent approved registries. Using unapproved base images introduces unvetted code into the software supply chain.

Container Scanning: Tools such as Twistlock (now Prisma Cloud), Anchore, and Trivy scan container images for known vulnerabilities in operating system packages and application dependencies. Container scans should execute after image build and before the team pushes the image to the production registry. Furthermore, teams must remediate images with critical or high-severity vulnerabilities before deployment.

Runtime Security: Container runtime security tools monitor deployed containers for anomalous behavior — unexpected network connections, privilege escalation attempts, or file system modifications. For this purpose, DoD Kubernetes environments commonly deploy Falco and Sysdig.

Infrastructure as Code and Configuration Management

Teams must treat infrastructure definitions (Terraform, CloudFormation) and configuration management (Ansible, Puppet) as code — version controlled, peer reviewed, and tested. Security scanning tools such as Checkov and tfsec analyze infrastructure-as-code templates for misconfigurations. Examples include overly permissive security groups, unencrypted storage volumes, and missing logging configurations. Therefore, integrate these scans into the same pipeline that processes application code.

ATO Considerations for CI/CD

The pipeline itself is a system that requires authorization. Under the Risk Management Framework (RMF), the system’s security boundary must include the CI/CD pipeline and its components — Jenkins, GitLab, SonarQube, container registries, and artifact repositories. Assessors then evaluate them against applicable NIST SP 800-53 controls.

The DoD’s Continuous Authority to Operate (cATO) model aligns naturally with DevSecOps pipelines. Rather than a point-in-time assessment, cATO relies on continuous monitoring, automated security testing, and real-time visibility into the security posture of deployed applications. A well-instrumented CI/CD pipeline provides much of the evidence needed to support a cATO. It demonstrates that automated testing continuously enforces security controls.

The pipeline should automatically generate key ATO artifacts. These include the Software Bill of Materials (SBOM), vulnerability scan results with remediation status, code quality and security scan reports, deployment audit logs, and configuration compliance assessments. As a result, automating the generation of these artifacts reduces the administrative burden on development teams and accelerates the authorization process.

Zapata Technology’s DevSecOps Approach

Zapata Technology has designed and implemented secure CI/CD pipelines for multiple Department of War programs. We integrate security tooling at every stage while maintaining the development velocity that mission owners demand. Our software engineering services include pipeline architecture, security toolchain integration, cATO support, and ongoing pipeline operations. We work within customer-accredited environments and tailor pipeline configurations to meet the specific security requirements of each program.

Conclusion

Building a secure CI/CD pipeline for DoD applications requires more than plugging security tools into a standard pipeline template. Instead, it demands a deliberate architecture that integrates security at every stage. That architecture must also generate the artifacts needed for authorization and support the continuous monitoring that modern ATO models require. Organizations that invest in building these capabilities early will deliver more secure software faster — and spend less time and money navigating the authorization process.