Executive Order 14028 reshaped the federal software market by tying procurement to attestations of secure development. The order itself was issued in 2021, but the implementation reached full force through the OMB memos and CISA forms that followed. By 2026, vendors selling software to federal agencies are expected to provide a self-attestation against the NIST Secure Software Development Framework, often supplemented by an SBOM and additional artifacts on agency request.
For vendors with mature engineering practices, the attestation is rarely about whether the practices exist. It is about whether the evidence supporting the practices can be produced quickly, consistently, and at the level of fidelity the federal program offices increasingly expect. The attestation form is short. The conversations behind it are not.
The shape of the attestation
The CISA self-attestation form maps to a defined subset of SSDF practices, organized into four groups. Prepare the organization, focused on policy, training, and accountability. Protect the software, focused on integrity controls in the supply chain and the build process. Produce well-secured software, focused on secure design, secure coding, and verification. Respond to vulnerabilities, focused on disclosure, triage, and remediation.
Each group breaks down into specific practices, and each practice has implementation examples in the SSDF that suggest the kinds of evidence that satisfy it. The vendor's attestation is a statement that the practices are in place. The evidence behind the attestation is what the agency or third-party assessor will request when they want to verify.
Why the pipeline matters
Attestations are not annual events. They are tied to specific software products, and they need to remain accurate as the software evolves. A vendor that signs an attestation in January and ships a major dependency change in March needs the attestation to still hold true in April.
The way to keep the attestation true without renegotiating it constantly is to make the practices, and the evidence, continuous. The SSDF practices are not aspirational checkpoints. They are operational behaviors that should be visible on every release.
Building the attestation evidence into the pipeline means each release produces the artifacts that support the attestation, and the attestation is a statement about a practice that is observable in the records.
The artifacts that anchor each SSDF group
For Prepare the Organization (PO), the artifacts are largely policy and accountability records. The secure software development policy, the roles and responsibilities, the training records, and the toolchain inventory satisfy this group. These artifacts are typically slow-moving, but they should be versioned and reviewable.
For Protect the Software (PS), the artifacts are pipeline integrity records. The SCM access controls, the signed commits or tags, the build provenance attestations, and the artifact integrity records satisfy PS practices. SBOMs play a role here as well, because they describe the integrity of the composition the build produced.
For Produce Well-Secured Software (PW), the artifacts are the verification records. Secure design reviews, threat models, code review records, static analysis results, dynamic analysis results, and the dispositions of findings satisfy PW. The evidence has to show not just that the analyses ran, but that the results were addressed.
For Respond to Vulnerabilities (RV), the artifacts are the disclosure and remediation records. The published disclosure policy, the inbound report log, the triage decisions, the patches issued, and the customer notifications satisfy RV.
How Safeguard produces the pipeline evidence
Safeguard sits across the PS, PW, and RV groups, with structured outputs that align to the SSDF practices.
For PS, Safeguard generates SBOMs on every build, captures provenance attestations linking the artifact to the source commit and the build environment, and integrates with SCM controls to verify that the inputs to the build were authorized. The integrity records are produced as a side effect of normal pipeline operation.
For PW, Safeguard's policy gates evaluate composition against defined criteria, producing logged decisions on every build. The findings from vulnerability scanning, license analysis, and component risk assessment are captured against the SBOM that produced them, and the dispositions, whether fix, mitigate, or accept, are logged with rationale and ownership.
For RV, Safeguard captures the inbound disclosure flow, the assessments performed, the triage decisions, and the eventual remediations. When a fix is shipped, the new SBOM links back to the original finding, closing the loop. The customer notification, when issued, is recorded with its scope and timing.
The aggregate of these artifacts is the evidence base behind the attestation. When an agency requests supporting documentation, the export covers the period and the product in scope, with each artifact tied to the SSDF practice it supports.
The SBOM dimension
The OMB memo that operationalized EO 14028 places significant weight on the SBOM. Agencies can request SBOMs as part of their procurement diligence, and some have moved toward making the SBOM a default expectation rather than an exception.
For the attestation pipeline, the SBOM is produced on every build and stored against the release. When an agency requests an SBOM, the export is the latest record, with full lineage to the source code and build environment. When the vendor needs to respond to a vulnerability disclosure that affects a specific historical version, the SBOM history makes the deployment-impact question tractable in hours rather than days.
The SBOM format expectation has consolidated around CycloneDX and SPDX, both of which Safeguard supports natively. The exported SBOM carries the metadata an agency reviewer expects, including author, timestamp, components, dependencies, and where applicable, license and provenance information.
The 30-60-90 cadence for vulnerability response
The RV group's vulnerability response practices imply timely action. While SSDF does not prescribe specific timeframes, the federal context establishes expectations that critical vulnerabilities are addressed within a defined window, often interpreted as 30 days for critical, 60 for high, and 90 for medium severity.
The attestation pipeline's evidence has to support whatever cadence the vendor commits to. Safeguard's policy gates can enforce the cadence by blocking releases that carry unaddressed critical vulnerabilities past the policy window, with the gate evaluation as the evidence of enforcement. The timeline records on each finding produce the population an assessor would sample.
When the agency asks for more
Self-attestations are not the end of the conversation. Some agencies request third-party assessment, particularly for higher-impact systems. When that happens, the assessor walks through the attestation claims and asks for the evidence behind them.
A vendor with a continuous evidence pipeline answers these requests with exports rather than reconstructions. The assessor picks a release. The vendor produces the SBOM, the build provenance, the policy gate evaluations, the findings present at the time, and the triage decisions. The chain is unbroken, and the assessor's confidence in the attestation grows.
The compounding return
The investment in an EO 14028 attestation pipeline pays back across other federal frameworks. FedRAMP ConMon draws on the same evidence. CMMC Level 2 and Level 3 supply chain controls overlap heavily. Future federal expectations, including the rumored expansion of attestation requirements to additional product categories, will draw on the same evidence base.
For vendors planning to grow their federal footprint, the attestation pipeline is not just a procurement requirement. It is the foundation of a federal-ready engineering practice, and the evidence it produces is the most direct demonstration that the practice is real.