Executive Order 14028, signed in May 2021, changed the landscape for software vendors selling to the United States government. Among its provisions, Section 4 establishes requirements for software supply chain security that include a specific mandate: software vendors providing products to the federal government must provide a Software Bill of Materials (SBOM).
For contractors who build containerized software, this mandate creates both compliance obligations and practical questions about what SBOM generation means in a container-specific context.
What EO 14028 Actually Requires?
The EO directed NIST to publish guidance on software supply chain security standards, and directed federal agencies to adopt those standards in procurement. The practical output:
NIST SP 800-218 (SSDF): The Secure Software Development Framework, which defines secure development practices including component tracking.
NTIA Minimum Elements for SBOM: Published by the National Telecommunications and Information Administration, this document defines the minimum data fields that SBOMs must contain to satisfy the EO’s component transparency requirements.
CISA SBOM Guidance: Supplementary guidance from the Cybersecurity and Infrastructure Security Agency on SBOM formats, tooling, and implementation.
The NTIA minimum elements are the most immediately actionable part of the requirements. An SBOM that satisfies the minimum elements must contain, for each component:
- Supplier name: The organization that provided the component
- Component name: The name of the component as it appears in the package repository
- Version of the component: The specific installed version
- Cryptographic hash of the component: A unique identifier that can verify the exact binary content
- Unique identifier: Such as a PURL (Package URL) or CPE (Common Platform Enumeration)
- Dependency relationship: How the component relates to other components in the artifact
- Author of the SBOM data: Who generated the SBOM
- Timestamp: When the SBOM was generated
Container-Specific SBOM Challenges
The NTIA minimum elements were designed for software generally and did not address container-specific component structures. Container images present several challenges that generic SBOM guidance does not resolve:
Multi-layer component sources: A container image has packages from the OS layer (dpkg, rpm, apk), the language runtime layer (pip, npm, gem), and application-level dependencies. The supplier for an OS package is the Linux distribution, not the application developer. The supplier for a pip package is PyPI. The SBOM must account for all three sources.
Base image inheritance: A Python application container inherits 300+ packages from its Debian base. The application team did not choose those packages — they inherited them. The SBOM must include them because they are present in the deployed artifact, but documenting them as if the application team is the “author” of those components is misleading.
Transitive dependency depth: Container images, particularly for applications with native extensions, can have deep transitive dependency trees. Fully documenting every transitive dependency to the depth required by NTIA minimum elements is technically complex.
Dynamic vs. static linkage: Statically compiled binaries carry their dependencies within the binary. Dynamically linked binaries load libraries at runtime. The SBOM for a container with dynamically linked binaries should ideally document which runtime libraries are actually loaded — which is a behavioral question, not a static analysis question.
Runtime-Informed SBOM for Complete Disclosure
A FedRAMP container scanning platform approach that combines static SBOM generation with runtime profiling produces a more complete disclosure for federal procurement:
Static SBOM: Documents all packages present in the container image based on package manager metadata. This satisfies the minimum elements requirement but includes packages that are never loaded during application operation.
Runtime BOM (RBOM): Documents which packages are actually loaded during representative application execution. This provides the behavioral layer that static SBOM cannot capture.
The combination answers the questions that federal agency security teams ask when evaluating container security:
- What is in the software? (Static SBOM)
- What actually runs? (RBOM)
- What CVEs affect the software that runs? (Scan results mapped against RBOM)
The Hardened Image SBOM Advantage
A software supply chain security program that includes hardening before SBOM generation produces a more accurate and more defensible SBOM for federal procurement:
The SBOM from a hardened image is smaller and more accurate than the SBOM from an unminimized image. It lists only the packages that are retained after runtime-profiling-based removal. The federal buyer who receives this SBOM and cross-references it against current CVE databases sees a component set that actually reflects the production deployment.
An SBOM from an unminimized image may list 400 packages, many of which the application never uses. A federal agency ISSO reviewing this SBOM and finding 30 Critical CVEs will ask how those CVEs are being managed. The answer “those packages are not used by the application” is less satisfying than the answer “those packages were removed before production deployment.”
SBOM Formats for Federal Submission
The federal government has not mandated a single SBOM format, accepting both:
SPDX (Software Package Data Exchange): A Linux Foundation standard with broad tooling support. SPDX 2.3 is the current version recommended for federal submissions.
CycloneDX: An OWASP standard with strong vulnerability management tooling integration. Version 1.4+ supports vulnerability information in addition to component inventory.
Most modern SBOM generation tools support both formats. For federal submissions, providing both formats ensures compatibility with agency tooling regardless of which format their review systems prefer.
Frequently Asked Questions
What executive order affects federal contractors regarding software security?
Executive Order 14028, signed in May 2021, is the primary executive order affecting federal contractors on software security. Section 4 of EO 14028 establishes software supply chain security requirements, including a mandate that software vendors providing products to the federal government must provide a Software Bill of Materials (SBOM). The order directed NIST to publish guidance including the SSDF and directed federal agencies to adopt those standards in procurement.
What does Executive Order 14028 do?
Executive Order 14028 directed a comprehensive modernization of federal cybersecurity practices. For software vendors, its most actionable provisions include the SBOM requirement, adoption of the NIST Secure Software Development Framework (SSDF), and CISA guidance on SBOM formats and tooling. The NTIA Minimum Elements for SBOM defines the specific data fields — including component name, version, cryptographic hash, and dependency relationships — that each SBOM must contain to satisfy the EO’s component transparency requirements.
What specific SBOM requirements apply to containerized software under EO 14028?
Container images present unique SBOM challenges that generic guidance does not fully address, including multi-layer package sources (OS, runtime, and application), base image inheritance of hundreds of packages the application team did not choose, and deep transitive dependency trees. Federal contractors must include all OS, runtime, and application layer packages with NTIA minimum elements, and are encouraged to supplement static SBOMs with runtime execution profiles that document which packages actually load during operation.
Why does generating an SBOM from a hardened container image matter for federal procurement?
An SBOM generated from a hardened image is a more accurate and defensible disclosure than one from an unminimized image. A hardened image’s SBOM lists only packages retained after runtime-profiling-based removal, so a federal agency ISSO reviewing it against current CVE databases sees the actual production component set. An SBOM from an unminimized image may list hundreds of packages the application never uses, creating unnecessary questions about CVE management for components that were never deployed in practice.
Practical SBOM Checklist for Container Workloads
For federal contractors building containerized software:
Generate SBOM from every production image build automatically
Include all OS, runtime, and application layer packages with NTIA minimum elements
Generate SBOM from hardened images rather than unminimized builds
Provide both static SBOM and runtime execution profile as supplementary material
Use SPDX 2.3 or CycloneDX 1.4+ format
Include cryptographic hashes (SHA-256) for all components
Timestamp SBOMs and link to specific image digests
Make SBOMs available to agency contracting teams on request with 24-hour turnaround
Maintain SBOM versions corresponding to each deployed image version
Link SBOMs to CVE scan results for the same image digest
