DevSecOps for Defense: Integrating Security into Every Sprint

DevSecOps — the integration of security practices into the software development and operations lifecycle — is not a new concept in commercial software development. In defense software programs, however, it remains an area where the gap between aspiration and practice is wide. Many defense programs still deliver security as a gate at the end of the development cycle: a penetration test, a security review, an accreditation process, all occurring after the code is functionally complete. This model is expensive, slow, and produces software with security deficiencies that are costly to remediate after delivery.

A DevSecOps approach shifts security left — integrating it into every sprint rather than treating it as a release gate. This article explains why end-of-sprint security fails in defense, how to integrate SAST, DAST, and SCA into an automated pipeline, how to handle secrets and secret management, and how to maintain STIG compliance as a continuous pipeline output rather than a point-in-time audit.

Why End-of-Sprint Security Review Fails in Defense

The traditional defense software security model creates a structural mismatch: developers spend months building functionality, then a security team spends weeks finding vulnerabilities in the completed code. The remediation cost is high because fixing a security vulnerability in deployed or nearly-deployed code requires regression testing, re-review, and potentially rework of multiple dependent components. NIST research (referenced in their SP 800-64) estimated that the cost to fix a security vulnerability found in design is 1x; the same vulnerability found in testing is 15x; and found in deployment is 30x or more.

In defense programs, the accreditation timeline amplifies this problem. An Authority to Operate (ATO) process — required before a DoD system can process operational data — typically takes 6–18 months for a new system. If security findings emerge late in development, they extend the already-long accreditation timeline. A single high-severity finding found during the final security assessment can delay a program by months while the vulnerability is remediated and the assessment is repeated.

The DevSecOps alternative: security tools run on every code commit and every pull request. Developers receive security feedback within minutes, in the same development workflow they already use. Security debt is eliminated sprint-by-sprint rather than accumulated and paid in a single painful block at the end of the program.

SAST, DAST, and SCA in the Automated Pipeline

Static Application Security Testing (SAST) analyzes source code without executing it, looking for patterns associated with security vulnerabilities: SQL injection, command injection, buffer overflow, hardcoded credentials, insecure cryptographic function calls, and hundreds of other weakness patterns. SAST runs on every commit and pull request as part of the CI pipeline.

Semgrep is the open-source SAST tool that has become standard in modern DevSecOps pipelines. Its rule-based approach allows custom rule authoring for organization-specific security policies, and its speed (typically under 30 seconds for a medium-sized codebase) makes it suitable for pull request feedback. Semgrep maintains a curated ruleset for common vulnerability classes and supports rules for DoD-specific security concerns (insecure crypto primitives that are prohibited by CNSA policy, for example).

Dynamic Application Security Testing (DAST) tests the running application by simulating attacker behavior: sending crafted HTTP requests, attempting injection attacks, testing authentication mechanisms. OWASP ZAP (Zed Attack Proxy) is the standard open-source DAST tool. In a CI/CD pipeline, ZAP runs in "headless" mode against a deployed test instance of the application, generating a findings report that is published to the security dashboard and can gate the deployment pipeline on high-severity findings.

Software Composition Analysis (SCA) identifies known vulnerabilities in third-party libraries and open-source dependencies. Given that modern software applications are typically 70–90% third-party code by component count, SCA is critical for defense programs with supply chain security concerns. Grype (from Anchore) and Trivy (from Aqua Security) are the two leading open-source SCA tools. Both maintain databases of CVEs cross-referenced against package databases for major language ecosystems (npm, PyPI, Maven, Go modules, etc.) and produce structured finding reports that can be ingested by SIEM or security dashboard tooling.

Secrets Detection: Preventing Credential Leaks in Defense Pipelines

Hardcoded secrets — API keys, database passwords, private keys, access tokens — in source code repositories are a perennial security problem. For defense software, the consequences are severe: a leaked API key to a classified system's backend could provide an adversary with direct access to that system without requiring any exploitation of the application layer.

Pre-commit hooks are the first line of defense: git hooks that run before a commit is accepted, scanning the staged changes for patterns matching known secret formats (AWS access keys, Google Cloud credentials, private key headers, etc.). Two tools dominate this space: detect-secrets (from Yelp, widely used in enterprise DevSecOps) and Gitleaks (purpose-built for git history and pre-commit scanning). Both maintain pattern libraries for hundreds of secret types and support custom patterns for defense-specific credential formats.

HashiCorp Vault provides the positive alternative to hardcoded secrets: a centralized secrets management system that applications query at runtime to retrieve credentials, rather than storing them in configuration files or environment variables. Vault's dynamic secrets feature generates short-lived, automatically expiring credentials for each application request — a database password that is valid for 1 hour provides dramatically less attack surface than a static credential that is valid indefinitely. In defense pipelines, Vault is typically deployed on-premises (not the Vault cloud service) to maintain control over the secrets infrastructure.

Container Image Scanning in Defense Registries

Containerization has become standard in defense software programs — Kubernetes deployments on DoD platforms like Platform One (P1) and as-yet-classified cloud environments use container images as the deployment unit. Container images can carry vulnerabilities from their base images and from packages installed during the image build process. Container image scanning integrates vulnerability detection into the container build and registry workflow.

Harbor is the CNCF-graduated open-source container registry with built-in security scanning. In a defense DevSecOps pipeline, Harbor serves as the organization's container image registry and automatically scans images on push using Trivy as the scanner backend. Scan results are attached to each image in the registry, and admission controller policies (implemented via Harbor's built-in policy engine) can prevent deployment of images with critical vulnerabilities.

Admission controller policies enforce security requirements at the Kubernetes API level: any attempt to deploy a pod is evaluated against a policy set before it is admitted to the cluster. For defense environments, policies enforce: no images from unverified registries, no images with critical CVEs above a specified CVSS threshold, no privileged containers, no containers running as root, and resource limit requirements. OPA/Gatekeeper and Kyverno (covered in the Kubernetes hardening article) are the standard admission controller frameworks.

Accreditation-Aware CI/CD: Maintaining STIG Compliance

Security Technical Implementation Guides (STIGs) are configuration standards published by DISA (Defense Information Systems Agency) that define the security configuration requirements for every category of technology used in DoD systems: operating systems, web servers, databases, network devices, and increasingly, container platforms and Kubernetes configurations. STIG compliance is a hard requirement for DoD ATO, not a recommended best practice.

Traditional STIG compliance validation is performed manually at audit time: a security assessor runs a STIG-compliant scanning tool (SCAP-compliant scanner with the STIG XCCDF content) against the deployed system and generates a finding report. This produces a point-in-time compliance picture that may not reflect the current configuration if the system changes after the audit.

An accreditation-aware CI/CD pipeline treats STIG compliance as a continuous output. InSpec (from Chef) with STIG profiles or OpenSCAP provides programmatic STIG compliance checking that can run as a pipeline stage. Container images are built with STIG-compliant base configurations (using DISA-published STIG-hardened base images or building from a known STIG-hardened base), and compliance is verified at build time. Any configuration drift from the STIG baseline triggers a pipeline failure and a finding in the security dashboard, rather than being discovered months later during an audit.