The SDLC compliance surface: what federal frameworks actually require from your build pipeline

Federal compliance frameworks collectively contain hundreds of controls. Most address infrastructure, physical security, personnel, and organizational risk management — areas far from the development team’s daily work. But a significant subset targets the SDLC directly: how software is built, tested, scanned, packaged, and deployed.

For platform teams at defense technology companies and federal software vendors, knowing which controls apply to the SDLC — and what they require in practice — determines what to automate. A companion article, The compliance tax, covers the operational cost of satisfying these requirements manually. This article is the technical counterpart: the specific controls, organized by framework, and what addressing them requires.

The landscape

The frameworks below differ in scope, specificity, and audience — but they overlap heavily in what they require from software development. A quick orientation before the detailed sections:

• EO 14028 / NIST SSDF targets software producers selling to the federal government. It prescribes secure development practices and is the closest thing to a direct SDLC specification among the frameworks covered here.
• DISA STIGs are prescriptive, technology-specific requirements. The Container Image Guide and Application Security STIG contain the most SDLC-relevant controls.
• CMMC / NIST 800-171 targets defense contractors handling CUI (Controlled Unclassified Information). Its 110 practices span 14 control families; the SDLC-relevant subset concentrates in Configuration Management, System Integrity, and Audit.
• FedRAMP targets cloud service providers selling to federal agencies. Of its 323 Moderate-baseline controls, the SDLC-relevant ones cluster in the SA, SR, CM, RA, and SI families.
• FISMA and ITAR have peripheral SDLC relevance — FISMA governs agency security programs, ITAR controls data access by nationality.

The overlap between these frameworks is substantial. SBOM requirements appear in EO 14028, FedRAMP, and CMMC. Vulnerability scanning is required by every framework that touches the pipeline. Container hardening requirements in the DISA STIGs align with NIST 800-53 controls that both CMMC and FedRAMP reference. The sections below catalog the SDLC-relevant requirements framework by framework, then synthesize the cross-cutting themes at the end.

EO 14028 and the NIST Secure Software Development Framework

Executive Order 14028 (May 2021) mandated baseline security requirements for all software sold to the federal government. The implementation framework is the NIST SSDF (SP 800-218) — 19 practices organized into 42 tasks across four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV).

Of all federal compliance frameworks, the SSDF maps most directly to SDLC automation. Its practices read like a specification for what a pipeline enforcement system should do.

SDLC-relevant practices

The CISA attestation form

CISA’s attestation form (required for software producers selling to federal agencies) distills EO 14028 into four categories, each mapping to concrete SDLC controls:

1. Secure development environments — branch protection, signed commits, no force-push to protected branches
2. Trusted source code supply chains — SCA execution, SBOM generation, approved container registries
3. Provenance data — SBOM existence and format validation, digest-pinned container images
4. Vulnerability management — SAST, SCA, and container scan execution with severity enforcement

OMB rescinded the government-wide mandatory attestation in January 2026 (M-26-05), but individual agencies retain discretion to require it — and Department of War (DoW, formerly DoD) procurement almost certainly will. The underlying SSDF practices remain the de facto standard regardless of attestation status.

DISA STIGs: container and DevSecOps requirements

DISA’s Security Technical Implementation Guides (STIGs) are prescriptive — they specify individual technical requirements with associated IA (Information Assurance) controls. The Container Image Guide and the Application Security & Development STIG contain the most SDLC-relevant requirements.

Container image creation (Container Image Guide §2)

Container deployment (Container Image Guide §3)

Application Security & Development STIG (V6 R2)

DevSecOps Playbook pipeline categories

The DoW DevSecOps Playbook defines expected testing categories for “meaningful pipelines.” Each maps to a concrete CI/CD integration:

Some STIG requirements resist pipeline-level automation entirely: SSH disabled in containers (2.1), SECCOMP profile enforcement (3.2), and kernel namespace isolation (3.10) require runtime enforcement mechanisms like Kubernetes admission controllers or pod security standards.

CMMC Level 2 and NIST 800-171

CMMC (Cybersecurity Maturity Model Certification) Level 2 maps to the 110 security practices in NIST SP 800-171. The majority address infrastructure, access control, and organizational processes. But a meaningful subset — particularly in Configuration Management (CM), System & Information Integrity (SI), Audit & Accountability (AU), and Risk Assessment (RA) — targets the SDLC.

SDLC-relevant practices

The 5-point controls

CMMC weights each practice by criticality. Several SDLC-relevant practices carry 5 points — the maximum weight. These cannot be deferred via a Plan of Action and Milestones (POA&M); failure on any 5-point control means automatic certification failure.

Four 5-point controls map directly to SDLC automation:

• AU.L2-3.3.1 (audit logs) — requires CI pipeline tracing, build provenance, and deployment records
• SI.L2-3.14.1 (flaw remediation) — requires active vulnerability management with timely resolution
• SI.L2-3.14.2 (malicious code protection) — requires code scanning at the pipeline level
• SI.L2-3.14.3 (security monitoring) — requires continuous dependency and vulnerability monitoring

For organizations pursuing CMMC Level 2 certification, these are non-negotiable. They require automated scanning and vulnerability management integrated into the pipeline — periodic manual reviews are insufficient.

Scope and gaps

CMMC’s remaining practices address physical protection (PE), personnel security (PS), maintenance (MA), media protection (MP), and identification & authentication (IA). These are infrastructure and organizational concerns outside the SDLC’s scope.

One partially addressable area: incident response (IR) plans and awareness & training (AT) documentation increasingly live in git — especially in organizations adopting docs-as-code workflows. To the extent these artifacts are version-controlled, their existence and structure can be verified as part of the development process.

FedRAMP: the SA, SR, CM, RA, and SI families

FedRAMP’s baseline contains 323 controls at Moderate impact level, drawn from NIST SP 800-53 Rev 5. The SDLC-relevant subset spans five control families: System and Services Acquisition (SA), Supply Chain Risk Management (SR), Configuration Management (CM), Risk Assessment (RA), and System & Information Integrity (SI).

FedRAMP 20x

FedRAMP’s modernization direction (20x) shifts toward continuous automated evidence over periodic manual narratives, OSCAL-formatted machine-readable packages, and persistent validation. Any SDLC compliance automation built today should generate machine-readable evidence as a byproduct of normal development — not as a separate process assembled before audits.

Scope and gaps

FedRAMP’s remaining controls address physical security (PE), personnel security (PS), the 51 System & Communications Protection (SC) controls (encryption, network segmentation, FIPS 140-2), and organizational risk management. These are infrastructure and organizational concerns outside the SDLC.

Contingency planning (CP) and incident response (IR) documentation is a partial overlap — when these artifacts live in git, their existence, structure, and recency can be verified through the same pipeline mechanisms that enforce other SDLC standards.

FISMA and ITAR: peripheral fit

FISMA

FISMA (Federal Information Security Modernization Act) governs federal agency information security programs, not vendor software directly. Its SDLC relevance is indirect: agencies evaluating vendor software may reference FISMA’s functional areas — supply chain risk management (GOVERN), software asset management (IDENTIFY), configuration management (PROTECT), and continuous monitoring (DETECT) — when setting procurement requirements. FISMA’s shift toward the Continuous Diagnostics and Mitigation (CDM) program parallels the continuous evidence model, but the overlap is structural rather than prescriptive.

ITAR

ITAR (International Traffic in Arms Regulations) controls who can access defense-related technical data — citizenship, deemed exports, DDTC registration — not how software is built. But ITAR has concrete SDLC consequences that are easy to underestimate.

Repositories containing ITAR-controlled data must be private (a public repository constitutes an export). More specifically, private repositories on GitHub.com are not considered ITAR-compliant — GitHub personnel worldwide may have access. The compliant options are GitHub Enterprise Server self-hosted in GovCloud or on-premises. The same constraint extends to all CI/CD tooling: build artifacts, container images, and test results are themselves technical data subject to the same access restrictions as source code. SaaS CI/CD services running on public infrastructure are non-compliant for ITAR work.

Every developer with access to ITAR-controlled repos or pipelines must be verified as a U.S. person. Foreign national employees — including those on H-1B, L-1, or OPT visas — cannot be assigned to ITAR projects without a DDTC export license. This affects team composition, access provisioning, and onboarding processes.

The indirect relevance is that ITAR-controlled technical data is classified as CUI, which triggers CMMC Level 2 requirements. The CMMC practices cataloged above cover the cybersecurity side of ITAR compliance.

What addressing these requirements looks like

Across all frameworks, the SDLC-relevant controls cluster around recurring themes. Each represents a category of automation that platform teams need to build or integrate — regardless of which specific framework drives the requirement.

SBOM generation and validation

Every framework that touches software supply chain requires SBOMs. But the requirements go beyond existence. The NTIA Minimum Elements Report specifies seven required data fields (supplier name, component name, version, unique identifiers, dependency relationship, author, timestamp), three approved formats (SPDX, CycloneDX, SWID), and operational practices including: a new SBOM for every build or release, all transitive dependencies listed, and explicit distinction between “no further dependencies” and “dependencies unknown.” Auditors ask follow-up questions beyond existence: Is it in an approved format? Does it contain license data? Are there disallowed licenses? Is the component count plausible, or was the generator misconfigured? Addressing this means generating SBOMs at build time and validating their contents against configurable criteria.

Referenced by: SSDF PS.3.2, FedRAMP SR-4, SA-4(10), CM-8, CMMC CM.L2-3.4.10, DISA V-222645, CISA Attestation Category 3

Security scanning enforcement

Frameworks require evidence that scans ran and that results fall within acceptable thresholds — not just that scanning tools are configured. This means SAST, SCA, container scanning, and IaC scanning integrated into the pipeline with configurable severity limits, and results captured as structured audit evidence.

Referenced by: SSDF PO.3.1–3.3, PO.4.1–4.2, PW.7.1–7.2, FedRAMP SA-11, RA-5, CMMC SI.L2-3.14.1–3.14.5, RA.L2-3.11.2, DISA DevSecOps Playbook, CISA Attestation Category 4

Container image hardening

The DISA Container Image Guide maps to specific Dockerfile and Kubernetes manifest practices: non-root execution, health checks, resource limits, approved base images, and digest pinning. These are verifiable at build time through static analysis of Dockerfiles and K8s YAML — no runtime instrumentation required.

Referenced by: DISA Container Image Guide §2–§3, SSDF PW.6.1–6.2, PW.9.1–9.2, CMMC CM.L2-3.4.6

Build provenance and artifact signing

Increasingly, frameworks require not just what was built but proof of how it was built. Build provenance — cryptographically signed attestations that link artifacts to their source code, build process, and builder identity — is the technical mechanism. Standards like SLSA (Supply-chain Levels for Software Artifacts) define maturity levels for provenance, from unsigned provenance at Level 1 to hermetic, reproducible builds at Level 3. Signed container images (via cosign/sigstore) and in-toto attestations satisfy the integrity verification requirements that appear across multiple frameworks.

Referenced by: SSDF PS.3.2, FedRAMP SI-7, CMMC AU.L2-3.3.1, DISA V-222645

Secret scanning and credential management

Embedded secrets — API keys, passwords, tokens checked into source code — are a recurring finding in both audits and incidents. DISA’s Container Image Guide explicitly prohibits embedded credentials (2.9), and CMMC’s malicious code protection requirement (SI.L2-3.14.2) is broadly interpreted to include detecting credential leakage. In practice, this means running secret scanning tools (gitleaks, truffleHog, GitHub secret scanning) in CI and pre-commit hooks, with findings treated as blocking.

Referenced by: DISA Container Image Guide 2.9, CMMC SI.L2-3.14.2, SSDF PO.3.1

Version control and change management

Multiple frameworks require change tracking, access controls, and integrity verification for source code. In practice: branch protection, required pull requests with minimum approvals, required CI status checks, signed commits, and CODEOWNERS enforcement — applied at the organization level, not configured per-repo.

Referenced by: SSDF PS.1.1, FedRAMP SA-10, SI-7, CMMC AC.L2-3.1.4, CM.L2-3.4.3, AU.L2-3.3.2

Testing and code quality

Frameworks require evidence that code is tested — not just that test infrastructure exists. This means verifying that tests executed, passed, and met coverage thresholds, with results captured as auditable artifacts.

Referenced by: SSDF PW.8.1–8.2, FedRAMP SA-11, DISA DevSecOps Playbook

Continuous evidence collection

The consistent direction across all frameworks — FedRAMP 20x, CMMC’s continuous monitoring requirement (CA.L2-3.12.3), the DevSecOps Playbook’s continuous ATO (cATO) model, FISMA’s CDM program — is that compliance evidence should be generated continuously as a byproduct of development, not assembled retroactively before audits. This requires structured, machine-readable output from every compliance-relevant pipeline step, stored centrally and queryable on demand.

Referenced by: CMMC CA.L2-3.12.3, FedRAMP 20x, FISMA CDM, DevSecOps Playbook cATO

How Lunar fits

The requirements cataloged above describe the problem space Earthly Lunar was built to address. Lunar is a guardrails engine that centrally instruments repositories and CI/CD pipelines, collects structured SDLC posture data, and continuously evaluates standards in pull requests — generating compliance evidence as a byproduct of normal development.

For the specific frameworks covered here, Lunar ships pre-built guardrails for SBOM validation, security scanning enforcement, container hardening, VCS configuration, testing requirements, and vulnerability management — each with configurable thresholds that map to the practice-level requirements above. For organization-specific requirements that no vendor ships out of the box (specific Iron Bank image lists, contract-specific STIG checks, internal tool version mandates), Lunar’s Bash and Python SDKs allow platform teams to encode custom guardrails — and Lunar ships with Claude and Codex skills that generate and locally test new guardrails in minutes.

A companion article covers the operational context — the cost of satisfying these requirements manually and the organizational dynamics that make automation necessary.

If the requirements in this article describe what your platform team is working to address, we’d like to hear from you.