26.1: U.S. Executive Order 14028 and Federal Requirements¶

Legal Disclaimer: This chapter provides general educational information about U.S. federal regulatory requirements for software supply chain security. It does not constitute legal advice and should not be relied upon as a substitute for consultation with qualified legal counsel familiar with your specific circumstances, business activities, and applicable law. Regulatory requirements are subject to change, and interpretations may vary. Organizations subject to federal procurement requirements should consult with attorneys experienced in government contracting and cybersecurity law.

The December 2020 SolarWinds compromise (detailed in Book 1, Section 7.2) marked a turning point in how governments approach software supply chain security. The breach exposed critical gaps in federal cybersecurity: attackers had infiltrated SolarWinds' build systems and inserted malicious code into software updates distributed to approximately 18,000 customers (per SolarWinds SEC filing)—including nine federal agencies and numerous Fortune 500 companies. The breach remained undetected for months, exposing the fundamental vulnerability of trusting software without visibility into its origins, components, and development practices.

Five months later, President Biden signed Executive Order 14028: Improving the Nation's Cybersecurity on May 12, 2021. This landmark order represents the most comprehensive federal intervention into software supply chain security to date, establishing requirements that extend well beyond government systems to reshape how software is developed, delivered, and verified across the entire technology industry.

The Policy Imperative: From Incident to Action¶

The SolarWinds attack—formally attributed in April 2021 to the Russian Foreign Intelligence Service (SVR)—demonstrated how compromised build processes could deliver digitally signed, legitimate-appearing updates carrying malicious payloads directly into victim networks. Traditional security controls failed because organizations trusted software from an established vendor without any mechanism to verify the integrity of its supply chain.

"The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people's security and privacy." — Executive Order 14028, Section 1

The attack crystallized several painful lessons. First, software supply chains had become critical infrastructure requiring the same security attention as power grids and financial systems. Second, the federal government lacked visibility into how the software it purchased was developed and what components it contained. Third, voluntary security practices had proven insufficient—binding requirements were necessary to drive meaningful change.

EO 14028 emerged from this recognition, tasking multiple federal agencies with developing standards, guidance, and requirements to address these gaps. Unlike previous cybersecurity directives focused primarily on government systems, this order explicitly targets the software supply chain itself, creating ripple effects throughout the commercial software industry.

Key Provisions of Executive Order 14028¶

The executive order spans eleven sections addressing various aspects of cybersecurity, but several provisions directly impact software supply chain security:

Section 4: Enhancing Software Supply Chain Security establishes the framework for secure software development and verification. It directs the National Institute of Standards and Technology (NIST) to publish guidelines for evaluating software security, including criteria for secure development environments, automated testing, and provenance verification. Critically, it requires agencies to obtain attestations from software vendors regarding their security practices.

Section 5: Establishing a Cyber Safety Review Board creates a mechanism for analyzing significant cyber incidents, modeled loosely on the National Transportation Safety Board. This board examines major attacks to identify lessons learned and recommend improvements—providing ongoing feedback to refine supply chain security practices.

Section 6: Standardizing the Federal Government's Playbook for Responding to Cybersecurity Vulnerabilities and Incidents mandates consistent incident response procedures across agencies, improving coordination when supply chain compromises occur.

Section 10: SBOM Requirements directs NTIA to publish minimum elements for a Software Bill of Materials (SBOM)—a formal, machine-readable inventory of software components. The order explicitly identifies SBOMs as essential for transparency and vulnerability management.

SBOM Requirements and NTIA Guidance¶

The National Telecommunications and Information Administration (NTIA) published "The Minimum Elements for a Software Bill of Materials" in July 2021, establishing baseline requirements for SBOM content and format. These minimum elements define what information an SBOM must contain to be useful for supply chain security purposes.

Data Fields required for each component are detailed in Book 2, Section 12.2, "Software Bills of Materials." In summary, NTIA requires: supplier identification, component name and version, unique identifiers (PURL, CPE) for automated correlation, dependency relationships showing component composition, and SBOM authorship and timestamp information.

Automation Support requirements specify that SBOMs must be machine-readable and generated automatically as part of the software build process. The guidance endorses three formats: SPDX (ISO/IEC 5962:2021), CycloneDX, and SWID tags.

Practices and Processes requirements establish that organizations must define how frequently SBOMs are updated, how they are distributed to recipients, and how access control is managed for SBOM data.

CISA has built upon NTIA's foundation, publishing additional guidance on SBOM sharing, consumption, and integration with vulnerability management programs. The agency's SBOM sharing lifecycle emphasizes that SBOMs are living documents requiring updates as software evolves and as new vulnerabilities are discovered in components.

Organizations implementing SBOM requirements should refer to Book 2, Section 12.2 for detailed guidance on SBOM generation approaches, format selection criteria (SPDX vs. CycloneDX vs. SWID), consumption workflows, and accuracy validation.

Secure Software Development Attestation¶

Perhaps the most significant ongoing impact of EO 14028 comes through the Secure Software Development Attestation Form, finalized by CISA in March 2024. This form requires software producers selling to the federal government to formally attest that their development practices conform to NIST's Secure Software Development Framework (SSDF).

The attestation covers four categories of practices:

1. Prepare the Organization (PO): Ensuring people, processes, and technology are prepared to perform secure software development
2. Protect the Software (PS): Protecting all components of software from tampering and unauthorized access
3. Produce Well-Secured Software (PW): Producing well-secured software with minimal security vulnerabilities
4. Respond to Vulnerabilities (RV): Identifying residual vulnerabilities and responding appropriately

Signatories must be company executives who can legally bind the organization. False attestations carry potential consequences under federal law, including civil and criminal liability for fraud. This personal accountability provision significantly elevates the stakes beyond typical compliance checkboxes.

Software producers must attest that they:

• Develop and maintain secure software development environments
• Employ automated tools to check for vulnerabilities and remediate them
• Maintain provenance data for internal code and third-party components
• Provide SBOMs upon request
• Operate a vulnerability disclosure program
• Attest to the security practices of their software supply chain

OMB Memoranda: M-22-18 and M-23-16¶

The Office of Management and Budget translated EO 14028 requirements into binding agency guidance through two key memoranda.

OMB M-22-18 (September 14, 2022), titled "Enhancing the Security of the Software Supply Chain through Secure Software Development Practices," established initial timelines and requirements. It mandated that agencies only use software from producers who attest to following secure development practices, with deadlines based on software criticality.

The memorandum introduced the concept of critical software (as defined in OMB M-21-30)—software that performs functions critical to trust, such as operating systems, hypervisors, network management software, remote access tools, and identity management systems. Agencies faced accelerated timelines for obtaining attestations for critical software.

OMB M-23-16 (June 9, 2023) extended and clarified M-22-18 requirements. Key provisions include:

• Software producers must complete self-attestation forms before September 14, 2024 for critical software
• Agencies may require third-party assessments for high-risk software
• Open source software is explicitly included in scope
• Agencies must inventory all software, including components within larger systems
• Waivers are available under specific circumstances but require documentation

The memoranda create a framework where federal purchasing power drives security improvements. Vendors unwilling or unable to attest to secure practices face exclusion from federal contracts—a powerful market incentive for compliance.

Impact on Federal Contractors and Suppliers¶

Organizations selling software to the federal government face substantial compliance obligations. The requirements apply broadly: any software "developed, manufactured, sold, procured, or obtained" for use by federal agencies falls within scope. This includes:

• Commercial off-the-shelf (COTS) software
• Custom-developed software
• Software as a Service (SaaS) offerings
• Firmware and embedded software
• Open source components incorporated into products

Immediate compliance requirements include:

1. Completing the Secure Software Development Attestation Form
2. Providing SBOMs for products upon agency request
3. Implementing vulnerability disclosure programs
4. Maintaining software development security documentation
5. Ensuring subcontractors and suppliers meet equivalent requirements

The supply chain nature of these requirements creates cascading obligations. A prime contractor must verify that their software suppliers have completed attestations, who in turn must verify their suppliers. This chain extends to the component level, including open source libraries.

Small and medium businesses face particular challenges. Many lack dedicated security teams or established compliance infrastructure. However, the requirements apply regardless of company size—a startup selling monitoring software to a federal agency faces the same attestation requirements as established enterprise vendors.

Implementation Timeline and Current Status¶

The EO 14028 implementation has proceeded through phases, with deadlines repeatedly extended as agencies and industry grappled with practical challenges:

As of late 2024, implementation continues with varying levels of agency enforcement. Some agencies have aggressively pursued compliance, requiring attestations before contract award. Others have taken more measured approaches, focusing on new acquisitions while developing strategies for existing software inventories.

CIRCIA and Incident Reporting Requirements¶

The Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA), signed into law on March 15, 2022, complements EO 14028 by establishing mandatory incident reporting for critical infrastructure entities. While technically separate legislation, CIRCIA reinforces supply chain security by ensuring visibility into attacks targeting the software supply chain.

Key CIRCIA provisions include:

• 72-hour reporting for covered cyber incidents
• 24-hour reporting for ransomware payments
• Coverage of entities in 16 critical infrastructure sectors
• CISA designated as the receiving agency for reports
• Liability protections for reporting entities

Software supply chain attacks affecting critical infrastructure trigger reporting obligations. An attack resembling SolarWinds—where compromised software updates penetrate multiple sectors—would generate mandatory reports from affected organizations, enabling faster coordinated response.

CISA is developing final rules implementing CIRCIA, with the final rule now expected in 2026 following an extension from the original timeline. The rules will define covered entities, reportable incidents, and specific reporting procedures.

Industry Spillover Effects¶

While EO 14028 requirements formally apply only to federal procurement, their effects extend far beyond government contracts. Several mechanisms drive broader adoption:

Commercial customer expectations: Federal requirements increasingly influence private sector procurement. Organizations observe federal standards as indicators of security maturity, incorporating similar requirements into their vendor assessments.

Vendor efficiency: Maintaining separate development and documentation practices for federal versus commercial customers proves operationally complex. Many vendors choose to apply secure development practices universally, achieving compliance once rather than maintaining dual processes.

Insurance and liability: Cyber insurance underwriters reference federal standards when evaluating applicants. Organizations demonstrating EO 14028-aligned practices may receive more favorable coverage terms.

International harmonization: The European Union's Cyber Resilience Act and similar international regulations share conceptual alignment with EO 14028 requirements. Vendors serving global markets benefit from harmonized practices meeting multiple regulatory frameworks.

Open source ecosystem effects: Requirements for SBOM provision and vulnerability disclosure extend to open source components. This drives investment in open source security tooling, vulnerability databases, and maintainer security practices that benefit all consumers of open source software.

Recommendations for Affected Organizations¶

We recommend organizations subject to federal software supply chain requirements take the following actions:

1. Inventory software assets comprehensively, including embedded components and dependencies, to understand the scope of compliance obligations

2. Assess current practices against NIST SSDF requirements, identifying gaps requiring remediation before attestation

3. Implement SBOM generation as an automated part of build processes, selecting a standard format (SPDX or CycloneDX) and establishing update procedures

4. Establish vulnerability disclosure programs if not already present, with clear intake processes and response commitments

5. Engage legal counsel regarding attestation implications, ensuring appropriate executives understand personal liability aspects

6. Extend requirements to suppliers through contract modifications and vendor assessment programs, recognizing that your attestation depends on supply chain security

7. Monitor evolving guidance from CISA, OMB, and NIST, as requirements continue to develop and clarify

8. Document compliance activities thoroughly, maintaining evidence of secure development practices for potential agency audits

The federal government's software supply chain security requirements represent a permanent shift in expectations for software producers. Organizations that treat EO 14028 compliance as a strategic investment rather than a regulatory burden will find themselves better positioned for both government and commercial opportunities in an increasingly security-conscious market.