How to Prove Secure Software Development to a Federal Buyer

You prove secure software development to a federal buyer with an evidence bundle, not a single form: a signed attestation to the SSDF based practices (when the agency asks for one), a current SBOM for the release you are selling, build provenance, records of how you find and fix vulnerabilities, and a plan of action and milestones for anything you cannot yet attest to. Since OMB Memorandum M-26-05 rescinded M-22-18 and M-23-16 in January 2026, there is no single government-wide checklist; each agency decides what it needs based on its own risk assessment. That makes the bundle more important, because a contracting officer can now ask for whatever their agency's policy says.

Below: what an agency can ask for today, what each artifact must show, how to write a plan of action, and how to generate it all from your pipeline. Safeguard appears near the end, with maturity labels.

Key takeaways

• The government-wide attestation mandate is gone, but the questions are not. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Agencies may still choose to use the CISA Secure Software Development Attestation Form and may write contract terms that require a current SBOM on request.
• The form still defines the vocabulary. Its four attestation items map to Executive Order 14028 section 4(e) and to specific NIST SP 800-218 (SSDF) tasks. If you can evidence those, you can answer most agency variants.
• Who signs matters. The form is signed by the CEO or a designee who is an employee with authority to bind the company, or replaced by an assessment from a qualifying third party assessor. False statements can fall under 18 U.S.C. 1001.
• SBOMs now follow the 2026 minimum elements. CISA and partners published the 2026 Minimum Elements for an SBOM on 29 July 2026, replacing the 2021 NTIA list and adding fields such as component hash, license, SBOM tool name and generation context.
• A gap is not a dead end. The form's instructions let an agency proceed when you name the practices you cannot attest to, describe mitigations, and submit a plan of action and milestones.
• Safeguard capabilities covered, with labels: SBOM generation and analysis (GA); SCA and vulnerability management (GA); reachability analysis (GA); attestation and signing (GA); EO 14028 compliance checks in ESSCM (GA); Portal, the SBOM publish and share product (GA); CSAF and VEX upload (GA); policies and gates (GA); Compliance and GRC suite (GA); autonomous remediation (GA, ships switched off with every category set to Manual); Safeguard CLI and local runner (GA); Trust Center (GA); fork and patch (GA).

What a federal agency can ask for now

The chain of authority, and what changed in 2026

The starting point is still Executive Order 14028, "Improving the Nation's Cybersecurity," published in the Federal Register on 17 May 2021. Section 4(e) told NIST to issue guidance on practices that enhance software supply chain security, and listed what it had to cover. Buyers still cite these items by number: secure development environments, including separate build environments, audited trust relationships, multi-factor authentication and conditional access, minimized build dependencies, encryption, and incident monitoring (4(e)(i)); producing artifacts that show conformance, on request (4(e)(ii) and (v)); automated tools to keep source code supply chains trusted (4(e)(iii)) and to find and fix vulnerabilities at least before each release (4(e)(iv)); accurate provenance for code and components (4(e)(vi)); an SBOM for each product (4(e)(vii)); a vulnerability disclosure program (4(e)(viii)); and attestation of conformity (4(e)(ix) and (x)).

NIST answered with SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published in February 2022. OMB then turned the guidance into an acquisition requirement. M-22-18, dated 14 September 2022, said agencies could use covered software only after the producer attested to SSDF based practices. M-23-16, dated 9 June 2023, amended it. CISA published the common attestation form on 11 March 2024 and opened the Repository for Software Attestations and Artifacts (RSAA) so producers could submit online.

On 23 January 2026, OMB Director Russell Vought issued M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security." It is a short memo with four practical effects:

1. It rescinds M-22-18 and M-23-16. The memo describes M-22-18 as having imposed "unproven and burdensome software accounting processes." The universal requirement to collect a signed attestation for every covered product before use ended on that date.
2. It puts the decision on each agency head. Agencies must keep a complete inventory of software and hardware and build assurance policies that match their own risk determinations and mission needs. The memo says there is no universal, one-size-fits-all method.
3. It keeps the old tools available. Agencies are free to use the government-wide resources developed under M-22-18, naming the Secure Software Development Attestation Form.
4. It invites SBOM contract terms. Agencies may adopt contractual terms requiring a producer to provide a current SBOM on request. A footnote adds that for a cloud platform, the contract should require an SBOM of the runtime production environment. The memo also points agencies to NIST SP 800-218, CISA's SBOM minimum elements, and CISA's Hardware Bill of Materials framework.

M-26-05 rescinds memos. It does not rescind Executive Order 14028, and it does not withdraw the SSDF. A separate order, Executive Order 14306 of June 2025, amended Executive Order 14144 and directed NIST to publish a preliminary update to the SSDF by 1 December 2025 and a final version within 120 days of that. NIST published SP 800-218 Revision 1, the SSDF version 1.2 initial public draft, on 17 December 2025, with comments closing on 30 January 2026. When we checked NIST's publication page for this post, Revision 1 was still listed as an initial public draft and no final version was posted. Version 1.1 remains the final SSDF.

CISA's attestation form page now sits in its archive. The form PDF still carries OMB control number 1670-0052, expiring 31 March 2027, and cites M-22-18 as its authority. It remains a usable template, no longer a universal precondition.

What that means for the person across the table

A contracting officer, contracting officer's representative, or agency CISO can now ask for any of the following, depending on how their agency wrote its post M-26-05 assurance policy:

Read M-26-05 as more possible requests, not fewer. Each agency can ask for the form, more than the form, or something tailored. A producer who can hand over the whole bundle is ready for all three.

What the CISA attestation form actually attests to

The form has three sections. Section I identifies the attestation type (new, following an extension or waiver, or revised) and its scope (company-wide, an individual product, or multiple products or specific versions). Section II collects the producer's details and a primary contact. Section III is the attestation itself.

The four attestation items

In Section III, the signer attests that the producer currently and consistently uses these practices for the identified software:

1. The software is developed and built in secure environments, secured at a minimum by:
   • a) separating and protecting each environment involved in developing and building software;
   • b) regularly logging, monitoring and auditing trust relationships used for authorization and access to development and build environments and among components within each environment;
   • c) enforcing multi-factor authentication and conditional access across those environments;
   • d) documenting and minimizing use of software products that create undue risk within the build environments;
   • e) encrypting sensitive data, such as credentials, to the extent practicable and based on risk;
   • f) defensive practices, including continuous monitoring of operations and alerts and responding to suspected and confirmed incidents.
2. A good-faith effort to maintain trusted source code supply chains, using automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities.
3. Provenance for internal code and third-party components, maintained to the greatest extent feasible.
4. Automated tools or comparable processes that check for security vulnerabilities, and in addition:
   • a) run on an ongoing basis and before product, version or update releases;
   • b) a policy or process to address discovered vulnerabilities before release;
   • c) a vulnerability disclosure program that accepts, reviews and addresses reports in a timely fashion.

The signer also attests that the producer will notify each agency that received the form if it stops making consistent use of these practices. A footnote adds that attestations are binding for future versions of the named product until the producer notifies the agency otherwise. That one sentence is why the evidence has to stay current release after release.

Scope: what the form covers and what it does not

Per the instructions, software needed a self-attestation under the old memos if it was developed after 14 September 2022, received a major version change after that date, or is delivered through continuous changes, as with software as a service. Four categories are out of scope: software developed by federal agencies, open source software obtained directly by an agency, third-party open source and proprietary components incorporated into the end product, and freely obtained public software.

The third exclusion trips people up. You do not attest on behalf of the open source libraries you ship. You do attest that you took the steps in items 2 and 3 to manage the risk of relying on them. The note in Section I makes this explicit: the attestation covers practices for code developed by the producer.

Who must sign, and the alternative

The instructions say the form must be signed by the chief executive officer of the software producer or a designee who is an employee of the producer and has authority to bind the corporation. The signature attests that the software is developed in conformity with the practices in the form.

The alternative is a third-party assessment. A Third Party Assessor Organization that is FedRAMP certified, or approved in writing by an appropriate agency official, evaluates conformance to all elements of the form using relevant NIST guidance as the baseline. The producer checks the box in Section III and attaches the assessment, and need not sign the form in that case. The agency is told not to post the assessment publicly.

The form warns that willfully false or misleading information may violate 18 U.S.C. 1001. Treat the signature as a legal act, backed by evidence someone has checked.

Which SSDF practices map to the form, and which artifacts prove them

The form's own crosswalk table maps each item to an EO 14028 subsection and to SSDF tasks. The table below keeps those mappings exactly as the form lists them, then adds the artifact a reviewer can examine. The "artifact" column is our guidance, not part of the form.

Four SSDF tasks tell you what good evidence looks like:

• PO.3.3 asks you to configure tools to generate artifacts of their support for secure development practices. Your pipeline should leave a record by default.
• PO.4.1 asks you to define criteria for software security checks and track them through the lifecycle. A written gate rule is that criterion.
• PS.3.2 asks you to collect, safeguard, maintain and share provenance data for all components of each release, and names the SBOM as an example.
• RV.2.2 asks you to plan and implement risk responses for each vulnerability, including a recorded decision to accept or mitigate rather than fix.

Notice the split. Items 2, 3 and 4 produce machine evidence a pipeline can generate. Item 1 is about how you run your environments, and its evidence lives in identity providers, cloud consoles and logging systems. For a longer item by item crosswalk, see attestation form items mapped to SSDF practices.

When an agency can ask for an SBOM or other artifacts, and in which formats

The legal hooks

There are three. First, EO 14028 4(e)(ii), (v) and (vii) describe producers providing artifacts and SBOMs when a purchaser asks. Second, M-26-05 tells agencies they may put SBOM on request terms in contracts, and for cloud platforms, a runtime production SBOM. Third, the old M-22-18 regime allowed agencies to ask for artifacts beyond the form, and the form's instructions still let agencies attach agency-specific addenda. In practice, read the solicitation and the contract clauses. If an SBOM clause is there, it binds you whatever the memo history says.

What the SBOM must contain in 2026

For four years the reference was NTIA's "The Minimum Elements For a Software Bill of Materials" (July 2021), which listed seven data fields: supplier name, component name, version, other unique identifiers, dependency relationship, author of SBOM data and timestamp.

That baseline has been replaced. On 29 July 2026, CISA, NSA, FBI and international partners released 2026 Minimum Elements for a Software Bill of Materials (SBOM), which says it "updates and replaces" the NTIA document. The changes that matter to a federal deliverable:

• New data fields: SBOM author signature, SBOM data format name and version, SBOM generation context, SBOM tool name and version, SBOM version, component hash value, component hash algorithm, and component license.
• Major updates: SBOM author, component producer (replacing "supplier"), component identifiers, and component version.
• Removed: the separate access controls element, now folded into distribution and delivery.

The 2026 document also says the minimum elements do not create new requirements by themselves; they refine how organizations generate and use SBOMs. The obligation comes from your contract. But an agency reviewer who checks your SBOM will check it against the current document, so a file that met the 2021 list can now look incomplete: no hashes, no licenses, no generation context.

M-26-05 pointed agencies to the August 2025 draft; the final July 2026 version supersedes it, so build to the final. For depth beyond the minimum, CISA's "Framing Software Component Transparency" (third edition, October 2024) sets out minimum, recommended and aspirational practice for each SBOM attribute.

Formats

The 2026 elements require machine processable data and record the data format name and version. In practice that means SPDX or CycloneDX. Pick the one your federal customer's tooling reads; when in doubt, ask, and be ready to produce both from the same build.

For vulnerability status, send VEX: a statement of whether a listed vulnerability affects your product. OASIS CSAF version 2.0 defines a csaf_vex profile for this, and CycloneDX can also carry VEX data. An SBOM without VEX hands the reviewer a list of CVEs to triage alone.

For provenance, the common format is the SLSA provenance predicate inside an in-toto attestation. The SLSA v1.0 provenance specification records a buildDefinition (build type, external parameters, resolved dependencies) and runDetails (the builder's identity and run metadata). It requires that external parameters be complete at SLSA Build L3, so that nothing outside the recorded inputs can influence the build. More on what reviewers look for: NIST 800-53 SR-4 provenance.

For a hosted service, the M-26-05 footnote matters: a repository SBOM is not a runtime SBOM. Produce SBOMs from the container images you deploy as well as from source.

What a plan of action for an unmet practice should look like

What the form says

The form's "Additional Information" section is short. If an agency cannot obtain a completed self-attestation, it may still decide to use the software if the producer:

1. identifies the practices to which it cannot attest;
2. documents the practices it has in place to mitigate the associated risks; and
3. submits a plan of action and milestones (POA&M) to the agency.

Under the old memos the agency then sought an OMB extension or waiver; now it is each agency's own policy, but the three part structure is still what a contracting officer will recognize.

A POA&M that a reviewer can accept

A good POA&M is specific, dated and owned. For each unmet practice, include:

Three rules keep a POA&M credible. Do not use it for item 1 controls you could simply turn on, such as MFA on the build system; reviewers read that as unwillingness. Do not set milestones beyond the contract period. And update it on a schedule you state, because a stale POA&M is worse than none.

How to keep the evidence current release after release

Treat the bundle as a pipeline output, not a document. If a person assembles it, it drifts the day after submission. A tool agnostic method:

1. Define the release unit. A tag, a container digest or a SaaS deployment. The SBOM, provenance and form scope must all match it.
2. Generate the SBOM in the build, from the build inputs. Use lockfiles and the actual artifact, and record the generation context.
3. Sign and attest the artifact. Bind SLSA provenance and the SBOM to the artifact digest, and verify before deploy.
4. Scan every build and rescan shipped versions when new CVEs appear (form item 4a).
5. Gate on written criteria and keep the pass, fail and exception log (item 4b, PO.4.1).
6. Record a decision for every finding: fix, accept with a reason, or mark not affected with a VEX statement (RV.2.2).
7. Archive the release record immutably (PS.3.1), and collect item 1 process evidence such as access reviews and MFA policy exports on a quarterly calendar, linked to the releases in that period.

If a practice stops being true, the form obliges you to notify the agencies that hold it, so make that a named owner's job. The same approach is covered from the SSDF side in how to produce an SBOM for every release (SSDF PS.3.2).

The bundle, as a checklist

When a contracting officer asks "show me," this is what to hand over for the version in scope:

• The signed attestation form or third-party assessment, scoped to the product and versions.
• An SBOM in SPDX or CycloneDX, meeting the 2026 minimum elements, with a hash so the reviewer can confirm it matches the delivered artifact.
• For a cloud service, an SBOM of the runtime production environment.
• Signed build provenance for each delivered artifact, and the public key or identity needed to verify it.
• The vulnerability scan report for the release, with the gate decision and any approved exceptions.
• VEX statements for vulnerabilities that do not affect the product.
• Your vulnerability disclosure policy and the address where reports go.
• A summary of process evidence for item 1 (environment separation, access reviews, MFA, credential handling, monitoring).
• A POA&M for anything you cannot attest to, with dates and owners.

If you are answering an RFP rather than a post-award request, AppSec RFP questions on secure development attestation covers the wording buyers tend to use.

How Safeguard does this job, step by step

Safeguard covers the machine evidence half of the bundle: SBOMs, vulnerability results, gate decisions, signed attestations, EO 14028 completeness checks and controlled sharing. It does not cover item 1 process evidence or the signature.

Step 1: Connect the code and produce an SBOM for each release

SBOM generation and analysis is GA. In ESSCM, go to Integrations in the sidebar and use Add Project/Product to connect a source repository (GitHub, GitLab, Bitbucket or a generic Git URL), a container image registry, or an uploaded manifest. During setup you choose the branch or tag and a version for the project. Safeguard's docs say generation supports SPDX and CycloneDX, with options to include dev dependencies and to run a Deep Analysis.

For a federal release, connect the release tag, not just the main branch, so the SBOM matches the version you name on the form. For a cloud service, also connect the container images you deploy, so you can answer the runtime SBOM request in M-26-05.

From a developer machine or a build agent, the Safeguard CLI (GA) does the same from the terminal, exactly as the docs show:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the terminal, then type /login and /scan .
safeguard

# Or scan from the command line, writing results under ./output
safeguard scan --dir .

Per the docs, a signed in scan from the interactive terminal uploads the SBOM and findings, and your source never leaves the machine. The local runner (GA) runs scans on your own machine after you approve it with a device code, for build networks a SaaS service should not reach into.

Step 2: Keep it current with continuous scanning

Per the docs, Safeguard rescans projects daily to catch newly disclosed vulnerabilities, and you can add triggers On Push, Scheduled, or On Release (when a new tag is created). The On Release trigger is the one that matters for the attestation: every new version gets its own SBOM and findings automatically, which is form item 4a evidence that checks run before each product, version or update release.

Step 3: Prioritize and fix what the scan finds

SCA and vulnerability management are GA, with CVE data enriched with EPSS and CISA KEV. Reachability analysis and prioritization is GA; Safeguard says it cuts findings by roughly 60 to 80 percent, its stated figure rather than a guaranteed result.

Autonomous remediation is GA and ships switched off, with every category set to Manual. When you turn it on for a category, Griffin opens a tested, policy gated pull request that moves a dependency to a fixed version, for one repository or in bulk. For the federal file, the pull request and its review are the record that a known vulnerability was addressed before release (form item 4b, SSDF RV.2.2).

Step 4: Write the release criteria as a gate

Policies, gates and guardrails are GA. Policies generate findings; gates enforce them at checkpoints, with actions block, warn or notify and approval through exceptions, and the offering files describe policy creation from plain English. Write your PO.4.1 criteria here: for example, block a release with a critical, reachable vulnerability, or block a KEV listed CVE unless an approver grants an exception. The gate outcomes become your decision log.

Step 5: Sign and attest each build

Attestation and signing is GA. Safeguard's attestation docs list five attestation types, all in in-toto v1 format: SLSA Provenance v1, a CycloneDX SBOM, an SPDX SBOM, a vulnerability scan snapshot at build time, and a Griffin generated review of what changed. Produce SLSA provenance in CI with your build platform's own attestation tooling, for example GitHub's artifact attestations or the SLSA GitHub generator. To check attestations that Safeguard signs, verify them against Safeguard's published public key as described at https://docs.safeguard.sh/docs/attestation-signing.

Tell your federal reviewer how verification works. Per the docs, attestations are signed with Safeguard's own ECDSA P-256 key held in a cloud key management service, and signatures are not written to a public transparency log, so verification uses the published public key with Cosign, skipping the transparency log check. There is no CLI command yet for signing container images and packages or for verifying and listing attestations; records appear on the Attestation tab in the app, and the attestation docs give the verification commands and the key's location.

The SLSA level you reach depends on your build platform. The docs say an isolated build on a hosted CI reusable workflow or on Safeguard's runner on a dedicated VM can reach Build L3.

Step 6: Run the EO 14028 checks and export the report

Safeguard's EO 14028 compliance checks in ESSCM are part of the GA Compliance and GRC suite. Per the docs, they validate each SBOM's completeness against the NTIA minimum elements (supplier name, component name, version, other unique identifiers, dependency relationship, author and timestamp) and check for a machine readable SPDX or CycloneDX structure. Each project gets a score (completeness, format, component coverage, freshness) and a status of Compliant, Partially Compliant or Non-Compliant.

To view it, open a project from Projects and go to its Compliance tab, or use the EO 14028 Compliance widget on the Dashboard for an organization view. To produce the document for a federal file, open the project, click Export, choose EO 14028 Compliance Report, select PDF, HTML or JSON, and download it. The report includes a gap analysis and remediation steps. There is no CLI command for it yet, so use the app flow.

Two cautions. First, the docs describe checks against the 2021 NTIA list. They do not claim to check the new fields in CISA's 2026 minimum elements, so review hashes, licenses, tool name and generation context yourself before you submit. Second, read "Compliant" as "this SBOM file is complete against that list," not as "this company meets EO 14028." Only the practices and the signature can say that.

Step 7: Publish the release record and share it under control

Portal, the SBOM publish and share product, is GA. Publishing moves an artifact from ESSCM into Portal as an immutable copy, which is a clean way to freeze the exact SBOM that went with a federal release. Portal's Compliance view runs the same kind of EO 14028 and NTIA checks per SBOM, with a gap analysis and reports you can export as PDF or Excel.

Portal's sharing docs describe direct shares with View, Download or Full permission, expiring and password protected links, approved domain restrictions, NDA acceptance, instant revocation, and tracking of who accessed which SBOM. A direct share to the contracting officer's agency address, plus the access log, answers "provide on request" and records that you did.

Portal's compliance docs also mention FedRAMP HIGH control mapping. Be precise about what that means: it is a check on your own SBOMs and documentation, not a FedRAMP authorization for you or for Safeguard. Safeguard describes FedRAMP HIGH only as an architecture its platform is designed for, and it holds no federal authorization.

Step 8: Add VEX and keep the vulnerability story straight

CSAF and VEX upload is GA. Upload your CSAF or VEX files through the Upload CSAF/VEX integration so the platform holds the exploitability statements alongside the SBOM. When an agency scanner flags a CVE in your SBOM that does not affect your product, the VEX record is your answer, and it should already be in the bundle.

Step 9: Map the rest of the program

The Compliance and GRC suite is GA, with NIST SSDF, EO 14028, SLSA and VEX among its supported frameworks and roughly 50 evidence connectors live today, more on request. Use it to track the SSDF tasks from the crosswalk, attach the process evidence for item 1 that comes from other systems, and keep the POA&M items as tracked controls with owners and dates. If you want to publish your posture on your own domain, Trust Center is GA; position it as expanding, and check what it covers before you rely on it for a federal response.

Requirement versus Safeguard versus you

What stays with the producer

Even with every artifact generated automatically, four things remain yours. The signature, a statement by an officer of your company made under the 18 U.S.C. 1001 warning. The practices themselves: a scanner records that a check ran, it does not make engineers review code or respond to incidents. Process evidence for item 1, which lives in your identity provider, cloud accounts, CI configuration and monitoring tools. And scope decisions: which products and versions, and when to notify agencies that a practice lapsed.

What Safeguard does not do

• It does not sign, submit or file the attestation. It produces evidence for the person who signs. It does not submit to an agency or to CISA's repository for you, and it is not a Third Party Assessor Organization.
• It holds no federal authorization. Safeguard is not FedRAMP authorized. FedRAMP HIGH is an architecture target for the platform, not a certification, and any FedRAMP wording in the Portal docs refers to checks on your own artifacts.
• It does not produce evidence for item 1 practices on its own. Environment separation, MFA, access reviews and incident monitoring need evidence from your identity, cloud and operations systems. The GRC suite can hold it, not create it.
• Its EO 14028 checks follow the 2021 NTIA elements as documented. The docs do not claim coverage of the 2026 CISA minimum elements, so verify the new fields yourself.
• SBOM accuracy depends on build inputs. If a deliverable is not connected, or a component is vendored without metadata, it will not appear correctly. An SBOM from source is not a runtime SBOM.
• No CLI or public API for some steps yet. The docs say there is no CLI command for the EO 14028 report, for signing container images and packages, or for verifying and listing attestations, .
• Remediation is off until you turn it on. Autonomous remediation ships with every category set to Manual, and every fix still goes through your review.

Common mistakes

Treating M-26-05 as the end of the requirement. The memo removed a universal mandate and moved the decision to agencies. Contracts signed under the old memos, agency-specific policies and SBOM clauses still bind you. Read the solicitation.

Signing a company-wide attestation for a product line you have not checked. The form allows company-wide scope, and it binds future versions until you notify agencies. If one product team does not meet item 1, scope the form to the products that do and use a POA&M for the rest.

Sending a 2021 style SBOM in late 2026. No hashes, no licenses, no generation context. It may pass an old checklist and still look incomplete to a reviewer reading the 2026 elements.

Writing a POA&M with no dates or owners. "We are working on it" is not a milestone. Name the role, the date and the evidence of closure.

Forgetting the notification duty. The signed form says you will tell agencies if a practice lapses. Assign that duty to a person and review it quarterly.

FAQ

Is the CISA secure software development attestation still required in 2026?

Not government-wide. OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Agencies may still use the form, and contracts may still require it.

Who signs the secure software development attestation form?

The CEO of the software producer or a designee who is an employee with authority to bind the company. Alternatively, a qualifying 3PAO assessment can be attached instead of a signature.

Do I attest for the open source libraries in my product?

No. The form excludes third-party open source and proprietary components incorporated into your product. You do attest that you manage their risk, through items 2 and 3.

What SBOM format do federal agencies accept?

SPDX or CycloneDX, the machine processable formats in practice. Ask which one the agency's tooling reads.

What changed in the 2026 SBOM minimum elements?

The July 2026 CISA document replaced the 2021 NTIA list. It adds fields such as component hash value and algorithm, component license, SBOM tool name and version, generation context, and author signature, and it renames supplier to component producer.

What happens if I cannot attest to one of the practices?

The form's instructions let an agency still use the software if you identify the practices you cannot attest to, document mitigations, and submit a plan of action and milestones.

Is NIST SSDF version 1.2 final?

Not as of this writing. SP 800-218 Revision 1 (version 1.2) was published as an initial public draft on 17 December 2025. Version 1.1 remains final.

Does Safeguard have FedRAMP authorization?

No. Safeguard describes FedRAMP HIGH as an architecture target, not a certification. Any FedRAMP language in its Portal docs refers to checks on your own artifacts, not to an authorization of Safeguard.

Keeping the promise between submissions

A federal attestation commits you to finding and fixing vulnerabilities in what you ship, release after release. Keeping that promise between submissions means closing the gap between a fix existing and that fix shipping in your build.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix the lodash CVE in a repository: it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. For a federal file, that session is what item 4b evidence looks like in practice: a vulnerability found, a fix made with a human approving each step, and a test run on record.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. Producers who sell to agencies often keep build systems on restricted networks; the runner lets you generate SBOMs and findings where the code already lives, which is how you keep the release record current without opening the build environment you are attesting to under item 1.

Click through it at your own pace, or open it full screen.

To try this on your own release, download Safeguard at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security (whitehouse.gov, 23 January 2026)
• Executive Order 14028, Improving the Nation's Cybersecurity (Federal Register, 2021-10460, via govinfo.gov)
• Executive Order 14306, Sustaining Select Efforts To Strengthen the Nation's Cybersecurity (Federal Register, 2025-10804, via govinfo.gov)
• CISA, Secure Software Development Attestation Form (archived page)
• CISA, Secure Software Development Attestation Form resource page
• CISA, Secure Software Development Attestation Form and instructions (PDF)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (CSRC)
• NIST SP 800-218 version 1.1 (PDF)
• NIST SP 800-218 Rev. 1, SSDF version 1.2, initial public draft (CSRC)
• NTIA, The Minimum Elements For a Software Bill of Materials (2021)
• CISA, 2025 Minimum Elements for a Software Bill of Materials (draft for comment)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA, 2026 Minimum Elements for an SBOM (PDF)
• CISA, Framing Software Component Transparency, third edition (2024)
• SLSA v1.0, Provenance specification
• OASIS, Common Security Advisory Framework version 2.0
• Safeguard docs, EO 14028 Compliance Checks
• Safeguard docs, Generate SBOM
• Safeguard docs, Attestation and Signing
• Safeguard docs, Portal Compliance
• Safeguard docs, Portal Sharing

Related reading: CISA secure software development attestation form explained and OMB M-26-05 and the end of the federal attestation mandate.

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.