Agile Cloud Sub Delivery for Government IT

The DoD DevSecOps Reference Design established a framework for integrating security throughout the software delivery lifecycle rather than bolting it on at the end. Platform One (P1) operationalized this with Big Bang and Repo One. For programs building their own DevSecOps pipelines, these templates provide a starting point aligned with DoD guidance.

DoD DevSecOps Pipeline Structure

A compliant DoD DevSecOps pipeline enforces security at multiple stages:

Source → SAST → DAST → SCA → Container Build → Image Scan → Sign → Deploy → Runtime Monitor

Each stage has required checks, and failure at any gate blocks deployment — security is a hard stop, not an advisory.

Stage 1: Static Analysis (SAST)

SAST tools scan source code for security vulnerabilities before compilation:

# .gitlab-ci.yml snippet for DoD SAST integration
sast-scan:
  stage: sast
  image: registry1.dso.mil/ironbank/openssf/semgrep:latest  # Iron Bank sourced
  script:
    - semgrep --config=auto
              --config=p/owasp-top-ten
              --config=p/cwe-top-25
              --json
              --output=sast-results.json
              src/
    - python scripts/evaluate_sast.py sast-results.json
      --max-high=0        # Zero high-severity findings allowed
      --max-critical=0    # Zero critical findings allowed
  artifacts:
    reports:
      sast: sast-results.json
    paths:
      - sast-results.json
    expire_in: 90 days    # Retain for audit evidence
  allow_failure: false    # Hard gate

Stage 2: Software Composition Analysis (SCA)

SCA checks open-source dependencies for known vulnerabilities (NIST NVD):

sca-scan:
  stage: sca
  image: registry1.dso.mil/ironbank/anchore/syft:latest
  script:
    - syft dir:. -o cyclonedx-json > sbom.json
    - grype sbom:sbom.json
              --fail-on high       # Fail on high+ CVEs
              --output json
              --file grype-results.json
    - python scripts/evaluate_grype.py grype-results.json
  artifacts:
    paths:
      - sbom.json
      - grype-results.json
    expire_in: 90 days
  allow_failure: false

The Software Bill of Materials (SBOM) output is increasingly required by DoD contracts per Executive Order 14028 and subsequent DoD guidance.

Stage 3: Container Image Build and STIG Scanning

Build from Iron Bank base images and scan with OpenSCAP:

# Use DoD-approved Iron Bank base image
FROM registry1.dso.mil/ironbank/redhat/ubi/ubi8:8.9

# Install application dependencies
RUN dnf update -y && \
    dnf install -y python39 python39-pip && \
    dnf clean all

# Non-root user required by STIG
RUN useradd -u 1001 -r -g 0 -s /sbin/nologin appuser
USER 1001

COPY --chown=1001:0 requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt

COPY --chown=1001:0 src/ /app/
WORKDIR /app
ENTRYPOINT ["python3", "main.py"]

container-stig-scan:
  stage: image-scan
  script:
    - docker build -t mission-app:$CI_COMMIT_SHA .
    - docker run --rm
        -v /var/run/docker.sock:/var/run/docker.sock
        registry1.dso.mil/ironbank/opensource/anchore/enterprise-scanner:latest
        anchore-cli image add mission-app:$CI_COMMIT_SHA
    - anchore-cli image wait mission-app:$CI_COMMIT_SHA
    - anchore-cli image vuln mission-app:$CI_COMMIT_SHA all
      --output json > anchore-results.json
  allow_failure: false

Stage 4: Container Image Signing

All DoD container images must be signed. Use cosign with a KMS-backed signing key:

# Sign image with cosign using AWS KMS key
cosign sign \
  --key awskms:///arn:aws-us-gov:kms:us-gov-east-1:ACCOUNT:key/KEY-ID \
  registry.example.com/mission-app:$CI_COMMIT_SHA

# Verify signature before deployment
cosign verify \
  --key awskms:///arn:aws-us-gov:kms:us-gov-east-1:ACCOUNT:key/KEY-ID \
  registry.example.com/mission-app:$CI_COMMIT_SHA

Enforce signature verification in your Kubernetes cluster with a Kyverno policy that blocks unsigned images.

Compliance Evidence Archive

Every pipeline run must archive evidence for ATO and audit purposes:

def archive_pipeline_evidence(
    pipeline_id: str,
    artifacts: dict[str, str],
    s3_bucket: str
) -> str:
    """
    Archive all pipeline security artifacts to S3 with metadata.
    Returns the S3 key for the evidence package.
    """
    import boto3
    import json
    from datetime import datetime, timezone
    
    s3 = boto3.client('s3', region_name='us-gov-east-1')
    timestamp = datetime.now(timezone.utc).isoformat()
    
    evidence_manifest = {
        'pipeline_id': pipeline_id,
        'timestamp': timestamp,
        'artifacts': {}
    }
    
    for artifact_name, local_path in artifacts.items():
        s3_key = f'evidence/{pipeline_id}/{artifact_name}'
        s3.upload_file(local_path, s3_bucket, s3_key)
        evidence_manifest['artifacts'][artifact_name] = s3_key
    
    manifest_key = f'evidence/{pipeline_id}/manifest.json'
    s3.put_object(
        Bucket=s3_bucket,
        Key=manifest_key,
        Body=json.dumps(evidence_manifest, indent=2)
    )
    
    return manifest_key

See Rutagon's cybersecurity ATO process and DoD cloud FedRAMP High deployment for broader authorization context.

Explore Rutagon's cloud engineering capabilities.

FAQ

What is Iron Bank and why is it required for DoD DevSecOps?

Iron Bank is the DoD's Hardened Container Repository — a curated library of container base images that have been scanned, hardened to STIG standards, and approved for use in DoD environments. Using Iron Bank images reduces the STIG compliance burden on mission teams by starting from a hardened base rather than a commercial distribution that requires extensive hardening.

What is Platform One and how does it relate to DoD DevSecOps?

Platform One (P1) is the DoD's DevSecOps platform program that provides shared services — Big Bang (a Kubernetes platform reference architecture), Repo One (GitLab-based source control), Iron Bank (hardened container registry), and Party Bus (application deployment). Programs can either use P1 services directly or build P1-aligned pipelines for non-P1-hosted programs.

Is DAST required in DoD DevSecOps pipelines?

Dynamic Application Security Testing (DAST) is required per the DoD DevSecOps Reference Design for web application workloads. OWASP ZAP and Burp Suite Enterprise are common DAST tools used in DoD pipelines. DAST scans must target a deployed test instance of the application, making pipeline integration slightly more complex than SAST.

How do you handle SAST findings in legacy codebases?

Legacy codebases often have a significant number of SAST findings that cannot all be remediated before pipeline deployment. A common approach is a progressive remediation model: document existing findings as accepted risks or planned remediations in the POA&M, enforce a "no net new high/critical findings" gate on new code, and systematically remediate the backlog per the POA&M schedule.

What software licenses are acceptable for DoD open-source components?

DoD policy generally permits permissive licenses (MIT, Apache 2.0, BSD) but restricts copyleft licenses (GPL, AGPL) for software incorporated into DoD systems — particularly if the software is distributed externally or would require releasing DoD source code. Your SCA tool should flag GPL/AGPL components for legal review. The DoD CIO has issued guidance on open source software use in DoD.