Executive Order 14028 and SBOM Compliance for Federal Software

Executive Order 14028, Improving the Nation's Cybersecurity, requires federal agencies to obtain a Software Bill of Materials (SBOM) for all software they acquire, starting with new acquisitions in fiscal year 2023. For suppliers, that means SBOM security, secure development attestation, and build integrity are now baseline expectations in federal procurement.

 

InvisiRisk embeds policy enforcement and SBOM verification directly into the CI/CD pipeline, helping federal suppliers meet these requirements with build-time evidence rather than after-the-fact documentation.

 

Executive Order 14028 Overview

 

Signed in May 2021 following the SolarWinds and Colonial Pipeline attacks, EO 14028 directed federal agencies to strengthen supply chain security, adopt zero-trust principles, and increase software transparency through SBOMs and secure development attestation aligned with NIST SP 800-218.

 

Subsequent directives, including EO 14144 (January 2025) and OMB Memorandum M-26-05 (January 2026), gave agencies more discretion over how they enforce these requirements. In practice, many agencies continue to require SBOMs and attestations as part of procurement.

 

SBOM Requirements for Federal Software Procurement

 

Federal agencies can require machine-readable SBOMs in SPDX, CycloneDX, or SWID formats, following minimum elements defined by NTIA and currently being updated by CISA. Each SBOM must document:

 

• Supplier name

• Component name

• Component version

• Other unique identifiers (such as PURL or CPE)

• Dependency relationships

• Author of SBOM data

• Generation timestamp

 

The challenge is accuracy. A static SBOM generated before or after the build may miss transitive dependencies, unexpected package substitutions, or components pulled from compromised registries. Federal buyers increasingly expect the SBOM to reflect what was actually built, which requires visibility into the build process itself.

 

Federal Supplier Responsibilities Under Executive Order 14028

 

In practice, meeting these expectations means:

 

• Aligning development workflows with NIST SP 800-218

• Producing and delivering machine-readable SBOMs for every version

• Monitoring components against CVE databases on an ongoing basis

• Maintaining audit-ready evidence of secure development practices

 

Senior leadership may bear personal accountability for attestation accuracy under the False Claims Act.

 

Build-Time Controls and SBOM Security

 

Most security tools scan code before or after the build. Neither sees what happens during the build, when dependencies are resolved, packages are downloaded, and the final artifact is assembled. Build-time is where dependency confusion attacks, registry compromises, secrets leaks, and data exfiltration actually occur.

 

InvisiRisk operates as a Build Application Firewall (BAF) that sits inline with your CI/CD pipeline, performing deep packet inspection of every network transaction during the build.

 

Build-Verified SBOMs

 

InvisiRisk sees every dependency pulled in during compilation, so the resulting SBOM reflects what was actually built, not what a manifest file declared.

 

Real-Time Policy Enforcement

 

Custom Rego policies block builds that pull unapproved dependencies or trigger risk indicators. Violations halt the build before the compromised artifact is produced.

 

Day-Zero Threat and Secrets Leak Detection

 

InvisiRisk identifies suspicious network behavior during the build, including unexpected outbound connections, unauthorized pushes to source control, and data exfiltration attempts, even when no known vulnerability signature exists.

 

Tamperproof Build Evidence

 

Every build produces a detailed record of packages pulled, policies evaluated, and actions taken, all of which become auditable evidence for federal compliance.

 

Continuous Compliance for Federal Software Updates

 

Federal compliance applies to every update, patch, and version, not just initial procurement. InvisiRisk integrates with major CI/CD platforms, including GitHub Actions, Azure Pipelines, Jenkins, and GitLab CI, to apply policy enforcement automatically on every build. When a build violates policy, InvisiRisk halts it before any non-compliant artifact is created and alerts the team with specific details about the violation.

 

If a CVE is later published for a component used in a previous build, InvisiRisk flags the affected builds and SBOMs so your team can assess exposure before an agency inquiry arrives.

 

Audit and Attestation Support

 

InvisiRisk generates compliance-ready evidence with every build, including:

 

• Records of network requests and package downloads

• Documentation of which policies were applied and their results

• Traceability connecting each SBOM to the build that produced it

• Details of any flagged or blocked behavior

 

This evidence supports attestation against NIST SP 800-218, the CISA Common Form, and agency-specific frameworks.

 

Learn how InvisiRisk can support your EO 14028 compliance strategy.

 

Frequently Asked Questions

 

Does Executive Order 14028 require real-time enforcement or only SBOM documentation?

 

The order calls out SBOM documentation specifically, but the underlying SSDF requirements address build integrity and secure delivery. Agencies evaluating vendors look favorably on evidence that security controls were actively applied during the build, not only documented afterward. Real-time enforcement through InvisiRisk produces that verifiable proof.

 

Does InvisiRisk replace SBOM generation tools required for federal compliance?

 

No. InvisiRisk complements traditional SBOM generators by adding build-time verification. It monitors every network transaction during the build and confirms that the SBOM reflects what was actually pulled in, not just what was declared in manifest or lock files.

 

Can InvisiRisk help validate third-party software before federal submission?

 

Yes. If a third-party dependency triggers a policy violation (a known vulnerability, an unapproved license, or an untrusted registry origin), InvisiRisk blocks it before it enters the final artifact. You can demonstrate that every component passed documented security checks at build time.

 

What happens if a build violates federal security policy requirements?

 

InvisiRisk halts the build before any artifact is produced. The team receives an alert identifying the specific dependency, transaction, and rule involved. Build logs and policy records are preserved automatically as audit evidence.

 

How does InvisiRisk help organizations prepare for evolving federal cybersecurity guidance?

 

InvisiRisk uses policy-based controls that can be updated as requirements change. New policies can be written and applied without modifying your CI/CD pipeline. As agencies develop risk-based approaches under M-26-05 or CISA finalizes updated SBOM minimum elements, your compliance controls adapt without infrastructure changes.