US Executive Order 14028 and Federal SBOM Procurement Guidance

On May 12, 2021, then-President Biden signed Executive Order 14028, "Improving the Nation's Cybersecurity," which triggered a chain of federal actions around secure software development, supplier attestations, and software transparency. For SBOM work, the important point is not that the executive order alone created one universal procurement rule, but that it led to NIST, OMB, CISA, and agency-specific requirements that now shape how federal buyers evaluate software suppliers.

Executive Order 14028 Overview

What is Executive Order 14028?

Executive Order 14028 is a broad cybersecurity directive covering incident response, cloud security, zero trust, and software supply chain security. Its SBOM impact is indirect but important: it accelerated the federal standards, attestation forms, and procurement language that software vendors now need to understand.

Key Objectives

• Modernize cybersecurity defenses across federal agencies
• Improve information sharing between government and private sector
• Enhance software supply chain security through transparency
• Accelerate migration to secure cloud services and zero trust architecture
• Create standard playbooks for cyber incident response

Why It Matters for SBOMs

The executive order includes the now-familiar SBOM definition:

"The term 'Software Bill of Materials' or 'SBOM' means a formal record containing the details and supply chain relationships of various components used in building software."

Who Needs to Pay Attention?

Highest-Impact Cases

Software Vendors to Federal Agencies

You should treat this as high priority if you:

• Sell software directly to federal agencies
• Provide software services under federal contracts
• Develop custom software for government use
• Supply software used in critical government operations

Critical Software Providers

Federal scrutiny is typically higher if your software:

• Has privileged access to networks or administrative privileges
• Has direct or privileged access to networking or computing resources
• Is designed to run with elevated privilege or manage privileges of other software
• Has direct access to security functions of the platform
• Is designed to control access to data or operational technology

Indirect Compliance Impact

Subcontractors and Suppliers

• Prime contractors often flow security and documentation expectations down to subcontractors
• Software supply chains may be asked to provide attestations, inventories, or supporting SBOM material up the chain
• Third-party components should be documented and tracked

Private Sector Ripple Effects

• State and local governments adopting similar requirements
• Private companies requesting SBOMs from vendors
• Industry standards aligning with federal requirements
• Competitive advantage for compliant vendors

📋 Detailed Requirements Breakdown

NTIA Minimum Elements for SBOMs

The Executive Order delegates SBOM standards to the National Telecommunications and Information Administration (NTIA), which defined three categories of minimum elements:

1. Data Fields (What information must be included)

• Legal name of the entity that created, modified, or provided the component
• Must be consistently identifiable across all SBOMs
• Can include both original creator and distributor

• Designation assigned to a unit of software defined by the original supplier
• Should be human-readable and machine-processable
• Must be unique within the supplier's namespace

• Identifier used by supplier to characterize the change state
• Can be semantic version, build number, or other versioning scheme
• Must be sufficient to identify the exact component build

• Package URLs (PURLs) for standardized identification
• Common Platform Enumeration (CPE) identifiers where applicable
• Software Heritage identifiers for open source components
• Cryptographic hashes for integrity verification

• Characterization of upstream component X used by downstream component Y
• Must include both direct and transitive dependencies
• Should specify relationship type (runtime, build-time, optional, etc.)

• Name of entity that created the SBOM data for this component
• Can be different from the component supplier
• Important for SBOM data quality and accountability

• Record of the date and time when the SBOM data assembly was completed
• Must be in ISO 8601 format for consistency
• Critical for understanding SBOM freshness and validity

2. Automation Support (How SBOMs are generated and consumed)

• Must be available in at least one machine-readable format
• JSON, XML, YAML, or other structured formats
• Human-readable formats (PDF, Word) are insufficient alone

• SBOMs should be generated automatically during build process
• Manual creation acceptable only for components without build automation
• Integration with CI/CD pipelines strongly recommended

• Must be consumable by common security and compliance tools
• Should follow established format standards (CycloneDX, SPDX, SWID)
• API access preferred for programmatic consumption

3. Practices and Processes (How SBOMs are maintained and distributed)

• Must be updated when components change
• Should reflect current state of deployed software
• Real-time updates preferred, but batch updates acceptable

• Must include all components with security implications
• Should cover transitive dependencies where possible
• Minimum viable depth defined per software category

• Must be provided to government customers upon request
• Should be available through secure, authenticated channels
• Integration with procurement and deployment processes

• Must protect sensitive information while meeting transparency goals
• Should balance security needs with supply chain visibility
• Established procedures for handling proprietary information

⚖️ Legal and Contractual Implications

Federal Acquisition Regulation (FAR) Updates

Contract Language Requirements

Federal contracts now must include specific SBOM requirements:

"The Contractor shall provide Software Bills of Materials (SBOMs) 
for any software delivered under this contract, in accordance with 
NIST guidelines and NTIA minimum elements. SBOMs must be provided 
in machine-readable format within [timeframe] of software delivery."

Compliance Verification

• Pre-award evaluations may include SBOM capability assessment
• Contract deliverables must include complete and accurate SBOMs
• Performance monitoring includes SBOM quality and timeliness metrics

Risk and Liability Considerations

Contractual Risk Allocation

• Indemnification clauses may cover SBOM accuracy
• Warranty provisions for SBOM completeness and currency
• Limitation of liability for third-party component vulnerabilities

Intellectual Property Concerns

• Trade secret protection balanced with transparency requirements
• Proprietary information handling in SBOM data
• Licensing compliance verification through SBOM content

🛠️ Implementation Strategy Guide

Phase 1: Assessment and Preparation (Months 1-3)

Current State Analysis

• Inventory existing software products sold to federal agencies
• Identify critical software requiring immediate compliance
• Map current development and build processes
• Assess existing tool capabilities for SBOM generation

Gap Analysis Framework

Gap Assessment Questions:
□ Can we automatically generate SBOMs for all products?
□ Do our SBOMs meet all NTIA minimum elements?
□ Are our SBOMs machine-readable and tool-compatible?
□ Do we have processes for SBOM updates and distribution?
□ Are development teams trained on SBOM requirements?
□ Do we have legal review processes for SBOM content?

Tool Selection Criteria

• Support for your programming languages and build systems
• Output in standard formats (CycloneDX, SPDX)
• Integration with existing CI/CD pipelines
• Automated dependency discovery
• Regular updates and active maintenance

Phase 2: Pilot Implementation (Months 4-6)

Pilot Project Selection

Choose pilot projects that are:

• Representative of your technology stack
• Non-critical to allow for learning and iteration
• Federal-facing to demonstrate compliance capability
• Well-documented with clear component dependencies

Implementation Checklist

• Install and configure chosen SBOM generation tools
• Integrate SBOM generation into build processes
• Validate SBOM content against NTIA minimum elements
• Test SBOM consumption by common security tools
• Document processes and create team training materials
• Establish quality assurance procedures for SBOM accuracy

Quality Validation Process

1. Automated checks for NTIA minimum elements compliance
2. Manual review of component identification accuracy
3. Dependency verification against known project structure
4. Format validation using standard tools and the SBOM Validator
5. Security tool integration testing for consumption capability

Phase 3: Full-Scale Deployment (Months 7-12)

Organization-Wide Rollout

• Standardize tooling across all development teams
• Implement governance processes for SBOM quality and consistency
• Create customer delivery mechanisms for SBOM distribution
• Establish monitoring and maintenance procedures

Process Integration Points

graph LR
    A[Code Commit] --> B[Build Process]
    B --> C[SBOM Generation]
    C --> D[Quality Validation]
    D --> E[SBOM Storage]
    E --> F[Customer Delivery]
    F --> G[Ongoing Monitoring]

Phase 4: Optimization and Maintenance (Ongoing)

Continuous Improvement Areas

• Automation enhancement to reduce manual effort
• Tool integration improvements for better workflows
• Process optimization based on operational experience
• Training programs for new team members and technologies

💼 Practical Compliance Examples

Example 1: Web Application for Federal Agency

• All JavaScript libraries (React, lodash, moment.js, etc.)
• Backend dependencies (Node.js modules, Python packages)
• Infrastructure components (database drivers, message queues)
• Container base images and system packages
• Third-party integrations and APIs

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": {
      "type": "application",
      "name": "fedapp-portal",
      "version": "2.1.3",
      "supplier": {
        "name": "Example Federal Solutions Inc."
      }
    }
  },
  "components": [
    {
      "type": "library",
      "name": "react",
      "version": "18.3.1",
      "purl": "pkg:npm/react@18.3.1",
      "supplier": {
        "name": "Meta Platforms, Inc."
      },
      "licenses": [{"license": {"name": "MIT"}}]
    }
  ]
}

Example 2: Custom Software Development Contract

• SBOM delivery within 30 days of each software release
• Updates within 48 hours of dependency changes
• Machine-readable format with API access
• Vulnerability impact assessment within 24 hours of disclosure

1. Automated generation integrated into deployment pipeline
2. Real-time delivery through secure API endpoint
3. Change notifications through automated alerting system
4. Vulnerability monitoring with automated impact assessment

Example 3: Commercial Off-The-Shelf (COTS) Software

• Third-party component licensing restrictions
• Proprietary algorithm protection
• Multi-tenant architecture considerations
• Frequent update cycles

• Layered SBOM approach with public and restricted sections
• Component abstraction to protect proprietary details
• Automated update distribution to maintain currency
• Legal review process for sensitive component disclosure

🔍 Monitoring and Enforcement

Federal Agency Oversight

Contract Oversight Bodies

• Contracting Officer's Technical Representative (COTR) - Daily oversight
• Contracting Officer - Contract compliance and modifications
• Agency CIO Office - Technical standards and implementation
• Inspector General - Audit and compliance verification

Compliance Monitoring Methods

• Regular SBOM audits during contract performance reviews
• Automated compliance checking through government tools
• Vulnerability response testing during security incidents
• Third-party assessments by government-approved auditors

Consequences of Non-Compliance

Contract-Level Consequences

• Corrective Action Requests with mandatory timelines
• Performance rating impacts affecting future contract awards
• Financial penalties through contract modification or withholding
• Contract termination for material non-compliance

Business Impact

• Debarment from federal contracting (rare but possible)
• Reputation damage in federal marketplace
• Competitive disadvantage in proposal evaluations
• Customer relationship strain and trust erosion

📊 Cost-Benefit Analysis

Implementation Costs

Initial Setup Costs

• Tooling: $0-$100K+ depending on commercial vs. open source choices
• Process development: 2-6 months of engineering time
• Training: $5K-$25K for team education and certification
• Legal review: $10K-$50K for contract and compliance analysis

Ongoing Operational Costs

• Tool maintenance: 0.25-0.5 FTE for tool management and updates
• Quality assurance: 0.5-1.0 FTE for SBOM validation and monitoring
• Customer support: Additional support time for SBOM-related inquiries
• Process overhead: 5-15% increase in development cycle time

Business Benefits

Direct Financial Benefits

• Federal market access: Maintained eligibility for $50B+ annual federal IT spending
• Competitive advantage: Differentiation from non-compliant competitors
• Premium pricing: Ability to charge for compliance and security capabilities
• Reduced audit costs: Streamlined compliance verification processes

Risk Mitigation Benefits

• Vulnerability response: 50-80% faster response to supply chain incidents
• Legal protection: Reduced liability through demonstrated due diligence
• Supply chain visibility: Better understanding and management of component risks
• Customer trust: Enhanced reputation for security and transparency

Strategic Advantages

• Market positioning: Early leadership in supply chain security
• Technology advancement: Improved development and deployment processes
• Partnership opportunities: Enhanced vendor and customer relationships
• Future readiness: Preparation for expanding compliance requirements

🚀 Future Outlook and Recommendations

Expanding Requirements

Other Government Agencies

• State and local governments adopting federal standards
• International allies implementing similar requirements
• Critical infrastructure sectors facing regulatory pressure
• Defense contractors cascading requirements through supply chains

Private Sector Adoption

• Enterprise customers requesting SBOMs from software vendors
• Industry standards incorporating SBOM requirements
• Cyber insurance policies requiring SBOM capabilities
• Investment due diligence processes including supply chain transparency

Technology Evolution

Emerging Standards

• Enhanced SBOM formats with richer metadata and relationships
• Automated SBOM analysis for risk assessment and compliance checking
• Integration standards for seamless tool interoperability
• Blockchain-based provenance and authenticity verification

Tooling Advancements

• AI-powered dependency discovery and analysis
• Real-time SBOM generation and distribution
• Advanced visualization for complex dependency relationships
• Integrated security analysis and vulnerability management

Strategic Recommendations

Immediate Actions (Next 90 Days)

1. Audit current federal contracts for SBOM requirements
2. Assess existing capabilities against NTIA minimum elements
3. Select and pilot appropriate SBOM generation tools
4. Begin team training on SBOM concepts and requirements

Medium-Term Initiatives (6-18 Months)

1. Implement full compliance for all federal-facing products
2. Develop competitive advantage through superior SBOM capabilities
3. Establish supplier requirements for third-party component SBOMs
4. Create customer value propositions around supply chain transparency

Long-Term Strategy (18+ Months)

1. Lead industry standards development and best practices
2. Expand capabilities to address emerging requirements
3. Leverage SBOM data for business intelligence and optimization
4. Prepare for global expansion of similar requirements

📚 Resources and Tools

Official Government Resources

• NIST Cybersecurity Framework
• NTIA SBOM Initiative
• CISA Software Supply Chain Security
• Executive Order 14028 Full Text

Implementation Tools

• CycloneDX Generator Tools
• SPDX Tools and Libraries
• NTIA SBOM Tool Classification

Industry Guidance

• BSA Federal SBOM Framework
• Linux Foundation SBOM Everywhere
• Cloud Security Alliance SBOM Guide

Related Articles

• EU Cyber Resilience Act Guide
• US Executive Order Requirements
• Complete Compliance Checklist
• SBOM Implementation Guide
• Vulnerability Management with SBOMs

Conclusion

Executive Order 14028 still matters, but vendors should not treat it as a stand-alone checklist. The operational work is to build evidence that your software development practices, supplier documentation, vulnerability handling, and SBOM generation can withstand federal review.

For organizations selling software to federal agencies, the right question is not "Are we EO 14028 compliant?" The right question is whether you can support agency, contract, and attestation requests with current, machine-readable software inventory and defensible development practices.

The question isn't whether your organization will implement SBOM capabilities—it's whether you'll be ready when your customers require them.