Executive Order 14028, signed on May 12, 2021, turned software supply chain security from a best practice into a binding federal procurement requirement, and the deadlines it triggered are still landing on vendors today. By March 11, 2024, the Cybersecurity and Infrastructure Security Agency (CISA) had finalized its Secure Software Development Attestation Form; by mid-2024, companies selling "critical software" to federal agencies were required to self-attest to NIST SP 800-218 practices or submit a third-party assessment. Layer on FedRAMP's roughly 325-control Moderate baseline, NTIA's SBOM minimum elements from July 2021, and a pending Federal Acquisition Regulation (FAR) rule that would make software bills of materials a standard contract clause, and "government application security compliance" has become a distinct discipline with its own tooling demands. Legacy software composition analysis vendors such as Black Duck — built originally for open-source license auditing — are now asked to cover ground outside their original design: build provenance, continuous attestation evidence, and policy enforcement mapped to federal control families. Here's what's actually required, and where the gaps show up.
What does Executive Order 14028 actually require of software vendors?
EO 14028 requires that any software sold to the U.S. federal government come with verifiable evidence of secure development practices, not just a vendor's assurance. Section 4 of the order directed NIST to publish guidance defining what "secure" means in practice, which became NIST SP 800-218, the Secure Software Development Framework (SSDF), released in February 2022. From there, the Office of Management and Budget issued M-22-18 on September 14, 2022, instructing federal agencies to collect self-attestations from software producers confirming SSDF conformance before using their products. A follow-up memo, M-23-16, arrived on June 9, 2023, and extended timelines while clarifying that attestation applies to "critical software" first — a category the order defines broadly to include anything with direct or privileged access to networking, computing resources, or sensitive data, from identity management tools to CI/CD platforms. The practical effect: vendors can no longer treat secure development as an internal engineering concern. It has to produce documentation an agency's contracting officer can file.
What is the CISA Secure Software Development Attestation Form, and who has to sign it?
The attestation form is a standardized document, finalized by CISA on March 11, 2024, that a company's CEO or a designated senior executive must personally sign, attesting compliance with specific SSDF practices across four control areas: development environment security, provenance of internally developed and third-party code, use of automated tools to check for security vulnerabilities, and maintenance of a vulnerability disclosure process. Under OMB's phased schedule, attestations for critical software delivered to agencies became due roughly three months after the form's finalization — around June 2024 — with attestation for all other software due within an additional three-month window. Vendors that can't attest truthfully have two options: submit a Plan of Action and Milestones (POA&M) documenting remediation timelines, or lose the contract. This is a meaningfully different bar than a SOC 2 report or a one-time penetration test summary; it requires an ongoing, evidentiary trail tied to a named executive's signature.
Why are SBOMs now a procurement requirement instead of a nice-to-have?
SBOMs became a procurement requirement because EO 14028 explicitly directs agencies to be able to request a software bill of materials for any purchase, building on the minimum elements NTIA published on July 12, 2021 — fields like supplier name, component name and version, dependency relationships, and a unique identifier, deliverable in one of three machine-readable formats: SPDX, CycloneDX, or SWID. A proposed FAR rule, published for comment in October 2023 as part of a broader federal cybersecurity rulemaking package, would go further and make SBOM delivery a standard clause across most federal software and cloud contracts, not just those touching "critical software." For vendors, this means SBOM generation has to move from a point-in-time export ahead of an audit to a continuously regenerated artifact tied to every build, because an SBOM that's stale by even one release cycle doesn't satisfy an agency asking "what's actually running in production right now."
How does FedRAMP factor into application security compliance for cloud software?
FedRAMP matters because any cloud service offering sold to a federal agency — SaaS, PaaS, or IaaS — has to be authorized against a NIST SP 800-53 Rev. 5 control baseline before agencies can legally use it, and those baselines run from roughly 125 controls at the Low impact level up to around 421 controls at High. Several of those controls map directly onto application security tooling: RA-5 requires vulnerability scanning on a defined cadence (typically monthly for the underlying infrastructure and more frequently for web-facing components), SI-2 requires flaw remediation within timeframes the agency's Authorization to Operate (ATO) specifies, and SA-11 requires evidence of security testing during development. The FedRAMP Program Management Office has also been running a modernization effort, branded FedRAMP 20x, through 2024 and 2025, aimed at cutting authorization timelines that have historically run 12 to 18 months. None of this replaces EO 14028 attestation — a vendor can hold a FedRAMP ATO and still owe CISA a separate SSDF attestation — which is exactly the kind of overlapping-but-distinct requirement that trips up point-solution tooling.
Where does Black Duck fit — and where does it fall short — for government compliance?
Black Duck covers SBOM generation and open-source license risk well, because that's the problem it was built to solve starting in 2002, long before SSDF attestation or FedRAMP existed as compliance targets; it operated as part of Synopsys's Software Integrity Group until it was spun out as an independent company in a deal with Clearlake Capital and Francisco Partners that closed in September 2024 at a reported valuation near $4.1 billion. That heritage shows in the product: strong dependency inventory, license conflict detection, and known-vulnerability matching against components. What it wasn't built to do is generate the artifacts CISA's attestation form and NIST SSDF assessments actually ask for — build provenance chains (the kind SLSA and in-toto attestations formalize), continuous evidence that a specific control was enforced on a specific build rather than checked once during a scan window, and a centralized place to assemble the documentation a compliance team hands to a contracting officer or an assessor. Government buyers evaluating Black Duck for compliance purposes frequently end up stitching together additional tools for provenance and policy enforcement — the SBOM is necessary but not sufficient once attestation, not just inventory, is the deliverable.
What's changing next for public sector application security requirements?
The requirements are getting stricter, not lighter, even as the specific executive orders shift. Executive Order 14144, "Strengthening and Promoting Innovation in the Nation's Cybersecurity," was signed on January 16, 2025, expanding on EO 14028's software supply chain provisions before a new administration's June 2025 cybersecurity executive order trimmed some sections while explicitly preserving SBOM and secure-development attestation requirements. In parallel, several states — including agencies in Texas, Virginia, and California — have begun referencing NIST SSDF and SBOM minimum elements in their own procurement language, meaning the federal bar is becoming a de facto floor for state and local contracts too. Vendors that treat this as a one-time compliance project rather than a standing engineering practice will keep re-scrambling every time a new memo lands.
How Safeguard Helps
Safeguard is built around the assumption that government-grade application security compliance is a continuous, evidentiary problem, not a periodic audit. Every build produces a fresh SBOM in SPDX and CycloneDX formats automatically, so agencies asking "what's in this release" get an answer that matches what's actually deployed, not a document generated ahead of last quarter's review. Safeguard attaches build provenance and attestation records to each artifact — mapped directly to NIST SP 800-218 SSDF practice families — so the evidence a CEO needs to sign CISA's attestation form, or that a third-party assessor needs for a formal assessment, already exists rather than requiring a scramble to reconstruct it after the fact. Policy-as-code gates in the CI/CD pipeline enforce controls that echo FedRAMP's RA-5 and SI-2 requirements, blocking builds that introduce components with unpatched critical vulnerabilities or that lack required provenance metadata, with remediation SLAs teams can point to during an ATO review. And because Safeguard treats SBOM and attestation generation as a pipeline output rather than an add-on scan, compliance artifacts stay current release over release — which is the difference between passing an audit once and staying eligible for federal and state contracts as the requirements keep evolving.