DevSecOps Subcontracting: What a Prime Gets from Rutagon
When a prime contractor wins a federal IT modernization or software development program, one of the first delivery questions they face is the pipeline question: who builds, owns, and maintains the DevSecOps infrastructure that the entire program runs on?
For many primes, especially those coming from a program management background rather than a software engineering background, the DevSecOps pipeline is the invisible foundation that determines whether the program delivers on time or not. Getting it right from the start is the difference between sprint velocity and sprint chaos.
This article describes exactly what Rutagon delivers as a DevSecOps sub — the specific components, the compliance posture, and the operational impact for a prime managing a federal IT program.
The DevSecOps Pipeline Problem in Government Programs
Federal IT programs have stricter security requirements than commercial ones. Code that ships to a DoD environment needs to pass vulnerability scanning, comply with DFARS 252.204-7012 incident reporting requirements, and eventually satisfy CMMC Level 1 or Level 2 controls depending on whether the program handles Federal Contract Information (FCI) or Controlled Unclassified Information (CUI).
The pipeline that delivers that code needs to be designed for those requirements from day one, not retrofitted during an audit.
Common failure modes Rutagon addresses:
- Long-lived credentials in CI/CD — API keys and access tokens stored in pipeline environment variables. When those rotate or leak, everything breaks. A single exposed credential in a government pipeline can trigger a DFARS incident report to DoD CISA within 72 hours.
- Container scanning as an afterthought — Running Trivy or Grype on images post-deployment rather than gating the pipeline. By the time a CVE surfaces in production, it's already in a deployed container.
- Manual ATO evidence collection — Screenshots of dashboards pasted into Word documents every 90 days for continuous monitoring reporting. This is unsustainable and creates FISMA compliance gaps.
- No signed artifact chain — Images deployed to production that can't be traced to a verified source. SLSA Level 2+ compliance requires provenance attestation; most pipelines don't have it.
What Rutagon's DevSecOps Stack Delivers
Rutagon builds DevSecOps pipelines that are compliant by design, not compliant by documentation.
OIDC-Federated Authentication: Zero Long-Lived Credentials
The foundation of Rutagon's pipeline architecture is OpenID Connect (OIDC) federation between the CI/CD system and the cloud provider. Instead of storing AWS access keys in GitLab CI variables or GitHub Actions secrets, the pipeline exchanges a short-lived OIDC token for temporary AWS credentials with a session duration of minutes.
# GitLab CI OIDC AWS authentication — no stored access keys
assume_role:
image: amazon/aws-cli:2.15.0
script:
- >
export $(printf "AWS_ACCESS_KEY_ID=%s AWS_SECRET_ACCESS_KEY=%s AWS_SESSION_TOKEN=%s"
$(aws sts assume-role-with-web-identity
--role-arn "${AWS_ROLE_ARN}"
--role-session-name "gitlab-ci-${CI_JOB_ID}"
--web-identity-token "${CI_JOB_JWT_V2}"
--duration-seconds 3600
--query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
--output text))This approach eliminates the single largest credential risk in government pipelines: stored, rotatable-only-when-something-breaks API keys. Credentials expire automatically. Blast radius from a compromised pipeline job is limited to the session duration.
For CMMC Level 2 control IA.3.083 (authenticating systems and components before allowing access) and AC.2.007 (employing least privilege), this architecture is the native solution — not a compensating control.
Container Security Scanning: Gate, Don't Just Scan
Rutagon integrates Trivy vulnerability scanning as a pipeline gate, not a reporting step. Scans run on every commit, and images with CRITICAL or HIGH severity CVEs with fixes available do not proceed to deployment.
container_scan:
stage: security
image: aquasec/trivy:0.49.1
script:
- trivy image --exit-code 1 --severity CRITICAL,HIGH --ignore-unfixed
--format json --output trivy-results.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
artifacts:
reports:
container_scanning: trivy-results.json
allow_failure: false # Hard gate — pipeline fails on fixable CVEs
The allow_failure: false is intentional. For government programs where a deployed vulnerability requires DFARS incident reporting, preventing deployment of vulnerable images is not optional.
Automated SAST/DAST Integration
Static Application Security Testing (SAST) runs on every merge request. For Python services, Bandit. For TypeScript/JavaScript, ESLint security plugins with no-eval, no-prototype-builtins, and injection-pattern rules. For infrastructure code, Checkov scans Terraform plans before terraform apply.
Dynamic Application Security Testing (DAST) runs against staging environments before any production promotion. OWASP ZAP in API scan mode covers OWASP Top 10 checks, and results feed into the continuous monitoring dashboard alongside Trivy results.
Artifact Signing and SLSA Provenance
Every container image that Rutagon delivers is signed with Cosign using a key pair managed in AWS KMS. The signature attestation ties the image to its build pipeline run, the Git commit SHA, and the Trivy scan results. Verification at deployment time confirms the image came from the pipeline, not an ad hoc build.
For SLSA Level 2 compliance (increasingly expected in DoD software supply chain requirements following EO 14028), this provenance chain is the required mechanism.
Continuous ATO Evidence Generation
One of the highest-overhead activities on a government IT program is ATO maintenance. FISMA requires continuous monitoring; NIST SP 800-137 defines the framework. In practice, this means regular evidence collection showing that controls are in place and operating effectively.
Rutagon's approach generates evidence automatically from the pipeline:
- Scan results (Trivy, SAST, DAST) are archived as pipeline artifacts with timestamps and commit SHAs
- Infrastructure compliance scans (Checkov) produce control mapping reports in JSON
- Deployment manifests with image digests and signatures provide provenance records
- Access logs from OIDC-federated sessions replace the audit trail that stored credentials can never produce
When an authorization decision needs to be renewed or an assessment is triggered, the evidence package is drawn from the artifact store — not assembled manually from memory and screenshots.
The Prime's Perspective: What This Changes
For a prime managing a federal IT program with Rutagon as a DevSecOps sub, here's what the operational picture looks like:
Reduced PM overhead. A DevSecOps sub who can't self-manage their pipeline creates a second job for the prime's PM. Rutagon's team owns the pipeline from design through operation, surfaces issues proactively, and escalates only when a program-level decision is required.
Compliance confidence on DCSA or DCAA audits. When a CO or assessor asks for evidence that the system has been maintained in compliance, the artifact store provides it. The prime doesn't need to reconstruct a compliance history from email threads.
Delivery velocity sustained through security gates. Security gates that block bad code don't need to slow the program if they're designed correctly. Rutagon's pipeline architecture is built for velocity — gate configuration is tuned to block genuine risks, not produce noise that engineers learn to ignore.
CPARS-recordable delivery. Every contract delivered through this infrastructure generates a CPARS performance record for Rutagon. That record builds the independent past performance history that supports both Rutagon's growth and the prime's ability to point to a sub with a verified delivery track record on future proposals.
Capability and Contact
Rutagon's DevSecOps delivery infrastructure is documented at rutagon.com/government. For a technical discussion of pipeline architecture, compliance posture, or specific program requirements, contact rutagon.com/contact.
For context on the zero-trust credential approach, see Zero Trust: Eliminating Long-Lived Credentials. For the CMMC compliance architecture, see CMMC Level 2 Cloud Infrastructure: Our Approach.
Frequently Asked Questions
What is OIDC federation in CI/CD and why does it matter for government programs?
OIDC (OpenID Connect) federation allows a CI/CD pipeline to exchange a short-lived token for temporary cloud credentials instead of using stored API keys. For government programs, this eliminates long-lived credentials from the pipeline environment, which directly addresses CMMC and DFARS cybersecurity requirements around credential management and least privilege access.
How does container scanning work as a pipeline gate versus a reporting step?
In a pipeline gate configuration, the CI/CD system runs a vulnerability scanner (like Trivy) on every container image and fails the pipeline if fixable CRITICAL or HIGH CVEs are found. This prevents vulnerable images from ever reaching deployment. A reporting-only configuration scans after deployment and reports findings, but doesn't block the deployment — meaning vulnerable images can already be running in production when the report is generated.
What is SLSA provenance and when does a federal program require it?
SLSA (Supply-chain Levels for Software Artifacts) is a security framework that defines levels of supply chain integrity. Level 2 requires that build provenance — a record of what produced an artifact, from which source code, through which pipeline — is generated and verifiable. Executive Order 14028 on improving the nation's cybersecurity directed NIST to define secure software development guidance, and SLSA provenance is increasingly expected on DoD software supply chain requirements.
Does Rutagon's pipeline architecture satisfy DFARS 252.204-7012 requirements?
DFARS 252.204-7012 requires, among other controls, rapid reporting of cyber incidents (within 72 hours to DoD CISA), preservation of images of compromised systems, and implementation of NIST SP 800-171 controls for protecting CUI. Rutagon's pipeline architecture addresses the access control, audit logging, incident detection, and configuration management controls most directly implicated by the clause.
What is continuous ATO and how does automated evidence generation support it?
Continuous Authority to Operate (cATO) is a DoD approach that replaces point-in-time ATO assessments with ongoing monitoring. Instead of collecting evidence every 3 years for a re-authorization, cATO requires demonstrating that controls are continuously operating. Rutagon's pipeline generates timestamped scan results, deployment manifests, and access logs automatically, providing the evidence stream that cATO frameworks require without manual collection overhead.