The DoD DevSecOps Reference Design describes the vision for continuous delivery of secure software to defense missions — but the reference design is a document, not working code. Software Factory pipelines are the operational implementation of that vision. This article examines what a production DoD-capable DevSecOps pipeline actually contains, what each stage enforces, and how to build one that meets DoD standards.
What Makes a Pipeline "DoD-Grade"
A CI/CD pipeline for typical commercial software focuses on build, test, and deploy. A DoD Software Factory pipeline adds security control enforcement as automated gates — non-passing security scans block promotion to the next stage, just like a failing unit test blocks merge.
The core distinction: security is a deployment gate, not a post-deployment activity.
The DoD DevSecOps Reference Design identifies these mandatory security activities in the pipeline: - Static Application Security Testing (SAST) - Dynamic Application Security Testing (DAST) - Software Composition Analysis (SCA) / dependency scanning - Container image scanning - Configuration validation / STIG compliance checking - Artifact signing and provenance
Pipeline Stages in a DoD Software Factory
Stage 1: Pre-Commit / IDE Hooks
Security starts before code reaches the pipeline. Pre-commit hooks run on developer workstations:
- Secret detection: git-secrets, TruffleHog, or Gitleaks detect accidentally committed credentials, API keys, or certificates before they enter the repository
- Linting and formatting: Syntax errors and formatting violations caught immediately
- License checking: Open-source license compliance check flags restrictive licenses at introduction point
Pre-commit security doesn't replace pipeline scanning — it provides a fast-feedback loop that reduces the cost of finding issues.
Stage 2: Build and Unit Test
Standard CI activities: - Dependency resolution and compilation (Gradle, Maven, pip, npm, cargo — language-dependent) - Unit test execution with coverage reporting - SAST scan (Fortify, Checkmarx, SonarQube, or Semgrep) — scanning source code for security vulnerabilities before compilation or during build artifact analysis - Software Composition Analysis (SCA) — scanning dependencies against NVD, OSV, and other vulnerability databases; generating SBOM
SBOM generation is increasingly mandatory for DoD programs. The Enduring Security Framework guidance, OMB M-22-18, and executive orders on software supply chain security have driven SBOM requirements into DoD contract language. SBOM generation (CycloneDX or SPDX format) should be automated in the build stage for every artifact.
Gates: Unit tests must pass, SAST critical/high findings must be zero (or have documented risk acceptances), and SCA must confirm no exploitable CVE-critical findings in dependencies.
Stage 3: Container Build and Image Scanning
For containerized deployments (the DoD Software Factory standard):
- Build container image from Dockerfile
- Container image scanning (Trivy, Grype, Prisma Cloud, or Aqua) — scan the container image layer-by-layer for OS and application vulnerabilities
- CIS benchmark / STIG hardening validation — OpenSCAP or InSpec profiles validate that the container image meets the applicable STIG (RHEL-based container image STIGs, Kubernetes node STIG, etc.)
- Artifact signing — Sign the container image with a cryptographic signature (Cosign/Sigstore, Notary v2) that can be verified at deployment time
Image signing enables policy enforcement at the Kubernetes admission controller — a Kubernetes validating webhook (OPA/Gatekeeper, Kyverno) can reject any container that doesn't carry a valid signature from the approved CI system.
Gates: No exploitable critical CVEs in the container image, STIG findings at or below the acceptable residual risk level, image is signed.
Stage 4: Integration and DAST Testing
Deploy the application to a test environment and run:
- Integration tests — Service-to-service integration validation, API contract tests
- DAST scanning (OWASP ZAP, Burp Suite Enterprise) — active scanning of the running application for exploitable vulnerabilities: injection attacks, authentication weaknesses, CORS misconfigurations, exposed sensitive data
- Performance baseline testing — Synthetic load tests to detect performance regressions before they reach staging
Infrastructure-as-code scanning also happens here: Terraform/CloudFormation configurations are scanned with Checkov, tfsec, or Terraform Sentinel for security policy violations (public S3 buckets, unencrypted storage, overpermissive security groups).
Stage 5: Staging Deployment and Acceptance
- Deploy to a staging environment that mirrors production configuration
- Smoke tests to verify deployment health
- Automated acceptance tests for critical user workflows
- Human approval gate (optional, for production promotion) — security engineer or ISSO reviews automated scan results before production deployment
Stage 6: Production Deployment
- Progressive deployment (canary, blue/green, feature flags) rather than big-bang deploys reduces blast radius of defects reaching production
- Runtime security monitoring active immediately upon deployment (Falco, Sysdig, Prisma Cloud Defender) — behavioral anomaly detection for post-deployment exploitation attempts
- Image signature verification enforced at Kubernetes admission control — no unsigned or differently-signed images allowed
SBOM Integration in the Pipeline
The SBOM pipeline integration connects to the SBOM management workflow:
- SBOM generated at build time (CycloneDX JSON format preferred for machine processing)
- SBOM stored in artifact registry alongside the container image (OCI-spec SBOM attachment)
- SBOM submitted to DoD VEX (Vulnerability Exploitability eXchange) infrastructure when required by contract
- SCA findings reference SBOM components — traceable from vulnerability → package → container image → deployment
Deploying Pipeline Templates Across Multiple Programs
Software Factories that serve multiple programs (like Platform One) use pipeline templates — standardized pipeline configurations that programs extend with their own customizations rather than building from scratch.
GitLab CI template example structure:
include:
- project: 'software-factory/pipeline-library'
file: '/templates/sast.yml'
- project: 'software-factory/pipeline-library'
file: '/templates/container-scan.yml'
- project: 'software-factory/pipeline-library'
file: '/templates/sbom-generate.yml'
# Program-specific stages extend the shared templates
stages:
- build
- test
- sast
- container-build
- container-scan
- dast
- deploy-staging
- production-approval
- deploy-production
This approach ensures every program inherits the factory's security gates while allowing program-specific customization of build, test, and deploy stages.
Rutagon designs and implements Software Factory pipeline architectures for DoD programs. Contact us to discuss DevSecOps infrastructure for your program.
Frequently Asked Questions
What is the difference between Platform One and a program-specific Software Factory?
Platform One is a shared DoD Software Factory operated by the Air Force that provides pipeline infrastructure, tools, and environments as a service to DoD programs. It supports multiple programs on shared infrastructure with IL2, IL4, and IL5 environments. A program-specific Software Factory is built and operated for a single program or contract. Platform One is appropriate for programs that want to focus on application delivery without operating infrastructure. Program-specific factories provide more customization but require more operational overhead.
What SAST tools are approved for use in DoD Software Factories?
Fortify (Micro Focus) and Checkmarx are the most widely approved SAST tools in DoD environments. SonarQube and Semgrep are used in some DoD Software Factories. The specific approved tools depend on the Software Factory's authorization and the applicable STIGs. Verify with your software factory operator or ISSO which SAST tools are on the approved tools list for your specific program environment.
Is it possible to meet DoD DevSecOps requirements with open-source tools only?
Yes, primarily. DoD Software Factories have been built with entirely open-source tooling: Trivy (container scanning), Gitleaks (secret detection), OpenSCAP (STIG compliance), OWASP ZAP (DAST), Cosign/Sigstore (artifact signing), and OPA/Gatekeeper (admission control). The DoD's own Platform One uses GitLab (with open-source edition capabilities) as its primary CI/CD platform. Commercial licenses may be required for Fortify/Checkmarx SAST if those tools are specified by the program's STIG requirements.
What is SBOM and why is it required for DoD programs?
SBOM (Software Bill of Materials) is a machine-readable inventory of every software component in an application — including third-party libraries, open-source packages, and their transitive dependencies — with version information and known vulnerabilities. DoD requires SBOMs under Executive Order 14028 (Improving the Nation's Cybersecurity) and subsequent OMB/CISA guidance. SBOMs enable supply chain risk assessment, vulnerability management, and license compliance tracking. They must be generated at build time and provided to program customers in standard formats (CycloneDX or SPDX).