NIST SP 800-218, the Secure Software Development Framework (SSDF), defines the practices that federal agencies and their contractors must implement for software supply chain security under Executive Order 14028. For software vendors with federal customers, SSDF is the standard their customers will reference when asking “how do you develop secure software?”
The SSDF practices are abstract by design—the framework is meant to apply across programming languages, deployment architectures, and organizational sizes. That abstraction makes the framework durable but difficult to apply concretely. For teams building containerized products, the question is: what does SSDF compliance actually look like in a container-based development and delivery pipeline?
SSDF Structure and the Container Relevance
The SSDF is organized into four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Each practice group contains specific practices with outcomes and implementation examples.
For containerized products, the most directly relevant practices are:
PW.4: Reuse existing, well-secured software. This practice addresses how teams select and use third-party components. Container base images, OS packages, language ecosystem packages, and libraries all fall within PW.4’s scope. The SSDF expects evidence that third-party components were evaluated for security before adoption and are maintained at current, secure versions.
PW.7: Review and/or analyze human-readable code. Container build definitions (Dockerfiles, Containerfiles) are human-readable code that defines how containers are built. Security review of Dockerfiles—checking for secure practices in package installation, capability handling, and user configuration—applies PW.7 to container build infrastructure.
RV.1: Identify and confirm vulnerabilities. Ongoing vulnerability identification in delivered software. For containerized products, this means SCA scanning of container images at build time and monitoring of deployed images against current CVE databases.
RV.2: Assess, prioritize, and remediate vulnerabilities. The process that turns RV.1 findings into remediation actions. SSDF expects documented processes for severity assessment, remediation timelines, and closure verification.
SSDF doesn’t describe what security tools to use. It describes what security outcomes to demonstrate and evidence to produce. Container programs must map their tools and processes to the evidence SSDF expects.
Mapping Container Practices to SSDF Requirements
PW.4 Implementation for Container Products
Secure software supply chain practices for PW.4 include:
- Component evaluation: Document how base images are selected (minimal footprint, verified publisher, CVE baseline review).
- Inventory documentation: SBOM generation for every released container image, capturing all OS and language ecosystem components.
- Update processes: Documented base image update cadence and dependency version management policies.
- Hardening: Unused package removal that reduces the inherited third-party component inventory to what the application actually requires.
Evidence for PW.4 audits: SBOMs from production images, base image selection criteria documentation, hardening pipeline logs showing package removal.
RV.1 and RV.2 Implementation for Container Products
Software supply chain security practices for RV.1 and RV.2 include:
- Scanning: CI-integrated SCA scanning on every build, with results stored as build artifacts.
- Prioritization criteria: Documented methodology for moving from raw CVE list to prioritized remediation queue (CVSS thresholds, runtime reachability criteria, EPSS scores).
- Remediation process: Documented ownership assignments, SLA tiers by severity, escalation procedures.
- Closure verification: Evidence that remediated CVEs were re-scanned and confirmed resolved.
Evidence for RV audits: historical scan results per image version, remediation tickets with closure dates, MTTR metrics by severity level.
Practical Steps for SSDF-Aligned Container Security
Generate and store SBOMs as versioned artifacts tied to image digests. SSDF attestations reference the software version delivered. SBOMs attached to container images by digest provide auditable evidence of what each released version contained, retrievable for any released image.
Document the vulnerability identification and remediation process before you need it for an audit. Federal customers requesting SSDF attestations will ask for the process document. Write it once, keep it current, and it’s ready for every attestation request. The document should describe: how vulnerabilities are identified (tools, frequency), how they’re prioritized (criteria), who owns remediation (role-based ownership), and how closure is verified (re-scan requirement).
Map your current tooling explicitly to SSDF practice IDs. Create a document that says “PW.4 is implemented by: base image selection policy, automated SBOM generation (Syft/cdxgen), hardening pipeline removing unused packages.” This mapping is the attestation evidence—it demonstrates that each practice is implemented, not just described.
Include runtime inventory evidence for RV practices. SSDF’s RV practices require identifying vulnerabilities in deployed software, not just built software. Runtime inventory (RBOM) that documents which components are executing in production extends the RV evidence to the deployment lifecycle, not just build-time.
Establish a SSDF attestation response playbook. Federal customers, particularly through the post-EO 14028 self-attestation process, will request SSDF evidence on a recurring basis. A playbook that maps each SSDF practice to existing evidence artifacts allows the security team to respond to attestation requests without starting from scratch each time.
Frequently Asked Questions
What is NIST SSDF and why does it matter for container-based products?
NIST SP 800-218, the Secure Software Development Framework (SSDF), defines secure software development practices that federal agencies and their contractors must implement under Executive Order 14028. For teams building containerized products, SSDF provides the standard that federal customers reference when evaluating a vendor’s software supply chain security. The framework’s four practice groups—Prepare, Protect, Produce, and Respond—map directly to container pipeline controls like SBOM generation, CVE scanning, and vulnerability remediation processes.
How does a secure software supply chain program satisfy SSDF compliance for container images?
A secure software supply chain program satisfies SSDF compliance by producing the evidence artifacts each practice group requires. PW.4 is demonstrated through SBOM generation, base image selection criteria documentation, and hardening pipeline logs. RV.1 and RV.2 are demonstrated through CI-integrated scan results stored as build artifacts, documented remediation timelines with ownership assignments, and closure verification via re-scan evidence. The key is mapping existing tooling explicitly to SSDF practice IDs so attestation responses reference real artifacts rather than descriptions.
What evidence do federal customers expect for SSDF attestation of container products?
Federal customers expect documented evidence across three categories: component inventory evidence (SBOMs tied to image digests for every released version), vulnerability identification evidence (historical scan results per image version with timestamps), and remediation evidence (tickets with closure dates, MTTR metrics by severity, documented escalation procedures). Container programs that generate and store this evidence continuously—rather than assembling it retroactively for each attestation request—can respond to SSDF attestations as a reporting exercise rather than a research project.
What is the difference between SSDF compliance and genuine supply chain security?
SSDF compliance achieved through retroactive evidence assembly produces marginal security programs and expensive audit cycles. Genuine supply chain security means designing the container pipeline to produce SSDF-required evidence as a continuous output—SBOMs attached to every build, scan results stored as artifacts, remediation tracked with documented SLAs. Organizations that build this way find that SSDF attestation becomes a reporting function on an already-operating program, not a scramble to reconstruct evidence that the program existed.
SSDF as Architecture, Not Audit Exercise
Organizations that implement SSDF as an audit exercise—assembling evidence retroactively when a federal customer requests it—find that each attestation cycle is expensive and the evidence quality is marginal. Organizations that implement SSDF as an architecture standard—designing their container pipeline to produce SSDF evidence continuously—find that attestation responses are a reporting exercise on an existing, documented program.
The distinction is the same as any compliance framework: build the security program first, and compliance evidence is a natural output. Build for the audit, and the security program never quite materializes.