Brief your CEO before signing the CISA secure software attestation

Before your CEO signs the CISA Secure Software Development Attestation Form, give them a one page brief that lists the four practices they are attesting to, the evidence behind each one, where you are thin, and the plan of action for every gap. The signature is a personal statement to the federal government "to the best of my knowledge", so the brief has to make that knowledge real.

The rest of this post is the material to build it: what the form says, what changed when OMB rescinded the memo behind it, the practices and evidence behind each line, how to present gaps, and what liability attaches when an attestation is wrong. Nothing here is legal advice. Your general counsel should read the brief before your CEO does.

Key takeaways

• The CISA form asks a CEO, or a designee who is an employee with authority to bind the company, to attest that the company "presently makes consistent use" of four groups of practices: secure build environments, a trusted source code supply chain, provenance for internal code and third-party components, and ongoing vulnerability checking with a disclosure program.
• OMB Memorandum M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Agencies are no longer required to collect the form, but may still choose to use it and may require a current SBOM on request by contract. CISA's form page is marked archived; the form still carries an OMB control number expiring 31 March 2027.
• An attestation you already submitted binds future versions of the named software until you notify the agency. Whether the rescission changes that is a question for counsel.
• The form warns that willfully false statements may violate 18 U.S.C. 1001. The False Claims Act (31 U.S.C. 3729) reaches reckless disregard, with no proof of intent to defraud, and the Justice Department's Civil Cyber-Fraud Initiative (October 2021) uses it against misrepresented cybersecurity practices.
• Where you cannot attest to a practice, the form allows a plan of actions and milestones (POA&M) with documented mitigations.
• Safeguard can produce part of the technical evidence: SBOM generation per release (GA), attestation and signing with SLSA provenance and in-toto (GA), EO 14028 checks on your SBOMs in the project Compliance tab and Portal Compliance (GA), the NIST SSDF framework in the Compliance suite (GA), policies and gates with exceptions (GA) and Portal audit trails (GA). It does not sign the form, submit it, or evidence your organisational practices on its own.

The situation

A federal agency, a prime contractor or a reseller sends over the CISA Secure Software Development Attestation Form, or asks you to confirm that the one you submitted last year still stands. Contracts sends it to the CEO's office because the signature line says "Signature of CEO or Designee with authority to bind the corporation". The CEO forwards it to you with one line: what am I signing?

That question deserves a better answer than "the security team has it covered". The form fits on two pages, but each clause is a statement of fact about how your company builds software today, across every environment and build behind the product named in Section I. Your CEO does not know whether build environments are separated or whether MFA covers every path into the pipeline. You do, or you can find out.

A bad week looks like this. The form is signed on Friday because the deal needs it. On Tuesday someone mentions that the legacy build server for the on-premises edition still uses a shared service account with no MFA. Nobody lied, but the company has attested without qualification to a practice it does not consistently follow, and that attestation binds future versions until you notify the agency. The time to find that server was before the signature, and the place to record it was a plan of action attached to the form.

The brief prevents that week. It turns a signature into an informed decision with three possible outcomes: sign as is, sign with a documented POA&M, or decline to attest until a gap is closed.

What the form says, and what changed in January 2026

What the form attests to

The form (Version 1.0, OMB control number 1670-0052) has three sections. Section I says what is covered: a new attestation, an attestation following an extension or waiver, or a revised attestation, and whether it is company-wide, for one product, or for a list of products and versions. Section II is the producer's contact details. Section III is the substance.

In Section III the signer attests that, to the best of their knowledge, the company presently makes consistent use of these practices, derived from the SSDF, in developing the software named in Section I:

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, both to the development and build environments and among components within each environment;
   • (c) enforcing multi-factor authentication and conditional access across the relevant environments;
   • (d) documenting and minimizing use of software products that create undue risk within those environments;
   • (e) encrypting sensitive data, such as credentials, to the extent practicable and based on risk;
   • (f) implementing 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 incorporated into the software, maintained to the greatest extent feasible.
4. Automated tools or comparable processes that check for security vulnerabilities, with three additions: they run on an ongoing basis and before product, version or update releases; there is a policy or process to address discovered vulnerabilities before release; and the company operates a vulnerability disclosure program that accepts, reviews and addresses reports in a timely way.

The signer also attests that the company will notify any agency that received the form if and when it stops making consistent use of those practices.

The scope note matters for the brief. The attestation covers code developed by the producer. The form excludes third-party open source and proprietary components incorporated into the product from what the producer attests to directly, but item 2 and item 3 still require you to show you took specific steps to manage the risk of relying on those components.

Each of those clauses traces back to Executive Order 14028, section 4(e), which told NIST to issue guidance covering secure development environments (separate build environments, auditing trust relationships, multi-factor authentication, minimizing dependencies, encryption, monitoring), trusted source code supply chains, automated vulnerability checks before release, provenance, SBOMs, vulnerability disclosure, and "attesting to conformity with secure software development practices". The form's item 1(a) through 1(f) reads almost line for line like section 4(e)(i)(A) through (F).

Who may sign

The instructions are specific. The form must be signed by the CEO of the software producer or a designee who is an employee of the producer and has the authority to bind the corporation. By signing, that person attests that the software is developed in conformity with the practices on the form.

There is one alternative to a signature. A producer may submit a third-party assessment by a Third Party Assessor Organization (3PAO) that is FedRAMP certified or approved in writing by an appropriate agency official, using NIST guidance that covers every element of the form as its baseline. If you take that route you check the box in Section III, attach the assessment, and the form does not need to be signed.

For a deeper look at the signer question, including designees and what "authority to bind" usually means inside a company, see who signs the CISA secure software attestation form.

What OMB M-26-05 requires of agencies now

On 23 January 2026 OMB issued Memorandum M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security". It says M-22-18 "imposed unproven and burdensome software accounting processes" and rescinds both M-22-18 and its companion M-23-16.

What it keeps is important for your brief:

• Each agency head remains responsible for assuring the security of software and hardware permitted on the agency's network, and each agency should validate provider security using secure development principles and a risk assessment.
• Agencies must continue to maintain a complete inventory of software and hardware, and develop assurance policies and processes that match their risk determinations and mission needs.
• Agencies "may choose" to use the government-wide resources developed under M-22-18, and the memo names the Secure Software Development Attestation Form as one of them.
• Agencies may adopt contract terms requiring a producer to provide a current SBOM on request. For a cloud platform, the memo says that term should cover an SBOM of the runtime production environment.
• It points agencies to NIST SP 800-218, CISA's SBOM minimum elements (it cites the August 2025 draft) and CISA's hardware bill of materials framework.

CISA's pages reflect the change. The main form page now carries an "Archived Content" banner, and the resource page restates the M-26-05 position. The form PDF still shows OMB control number 1670-0052, expiring 31 March 2027, and its instructions still cite M-22-18. Give that one sentence in the brief so the CEO is not surprised if an agency still asks.

Two more current documents matter. NIST published an initial public draft of SP 800-218 Revision 1 (SSDF version 1.2) on 17 December 2025, in response to Executive Order 14306; it is still a draft, so the form rests on SSDF version 1.1. And CISA, with NSA, the FBI and international partners, published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA minimum elements.

So why is your CEO being asked at all?

Because "no longer required" is not "no longer used". The form still reaches you when an agency chooses it under its own risk-based policy, when a contract or solicitation adds it as an agency-specific requirement, when a prime contractor or reseller asks for it, or when an agency asks you to confirm a form you submitted before January 2026.

That last case is the one people miss. Footnote 4 of the form says attestations bind future versions of the named software until the producer notifies the agencies that its practices no longer conform. If you signed in 2024 or 2025, that statement may still sit in an agency file or in CISA's Repository for Software Attestations and Artifacts. The brief should tell the CEO what is already on record.

Which SSDF practices sit behind each attestation item

The final Version 1.0 form says its practices are derived from the SSDF (NIST SP 800-218 version 1.1) but does not print a task-by-task mapping. The table below is a reading of the form against the SSDF task text. Use it to tell your CEO what the engineering work behind each line actually is, and to tell your teams which SSDF tasks they must evidence. For a longer, item-by-item treatment see attestation form items mapped to SSDF practices.

Note that items 1(a) to 1(f) are about infrastructure and identity, not code, so your cloud, identity and logging systems evidence them. PS.3.2 is the task that names the SBOM directly, and PS.2.1 (publishing integrity information such as hashes) sits beside it.

What evidence backs each item, and where it lives

The test for every line in the brief is simple: if an agency, an inspector general or a lawyer asked "how do you know", what would you hand them, and who owns it? Here is a working evidence map. Replace the "typical system" column with the real names of your systems.

The column that surprises most CEOs is "Owner": half the form is owned by teams outside security, so the brief should name an accountable owner for each line.

Step by step: build the CEO brief this week

This works with whatever tools you have. Plan on four to six working days the first time, and much less on refresh.

1. Pin the scope. Read Section I with contracts. Is the request company-wide, one product, or specific versions? Write down exactly which product names and versions are in scope, and which deployment models (cloud service, on-premises package, both). A company-wide attestation covers every build pipeline you run, including the old ones.
2. Check what is already on record. Ask contracts and sales operations for every attestation form submitted since 2024, to which agencies, and through which channel (email or the online repository). Note the product, version and date of each. Those are live statements unless you have notified otherwise.
3. Assign an owner per line. Use the evidence map above. One named person per item, with a deadline two days before the brief is due.
4. Collect evidence, not assurances. Each owner supplies an artifact (an export, a log sample, a policy, a ticket) and one sentence on how far it covers the scope. "MFA is enforced for all human users; two service accounts on the legacy build host use static credentials" is useful. "MFA is in place" is not.
5. Grade each line. Three grades only: Consistent (in place across the full scope, evidence attached), Partial (named exceptions), Not in place. "Mostly" is where liability lives.
6. Write a POA&M entry for every Partial and Not in place line. Practice, gap, mitigation today, owner, milestone date.
7. Choose the recommendation with the decision table below.
8. Have counsel review the brief, evidence index and POA&M before the CEO does, including whether any existing attestation needs a notification.
9. Brief the CEO in person. Fifteen minutes: summary, gaps, recommendation. Record the decision.
10. File everything (brief, evidence index, signed form, POA&M, date) in one folder with restricted write access.

The decision table

A brief template you can copy

The template is a plain text block so you can paste it into your own memo format.

TO:      [CEO name]
FROM:    [CISO name]
CC:      General Counsel
DATE:    [date]
RE:      CISA Secure Software Development Attestation Form: [product, versions]

1. WHAT YOU ARE BEING ASKED TO SIGN
   Requested by: [agency / prime / reseller], for [contract or renewal].
   Scope: [company-wide | product | versions]. Deployment: [SaaS | on-prem | both].
   You attest, to the best of your knowledge, that we presently make consistent
   use of four practice groups (summary attached), and that we will notify the
   agency if we stop.

2. CURRENT POLICY CONTEXT
   OMB M-26-05 (23 Jan 2026) rescinded M-22-18 and M-23-16. Agencies may still
   choose to use this form. The form warns that willfully false statements may
   violate 18 U.S.C. 1001. Counsel's note on False Claims Act exposure attached.

3. ALREADY ON RECORD
   [List prior attestations: agency, product, version, date, channel.]

4. LINE BY LINE
   Item | Grade (Consistent / Partial / Not in place) | Evidence | Owner
   1(a) ...
   1(b) ...
   ...
   4(c) ...

5. GAPS AND PLAN OF ACTION
   [Each Partial or Not in place line: practice, gap, mitigation today,
    owner, milestone date.]

6. RECOMMENDATION
   [Sign | Submit with identified practices and POA&M | Do not sign yet]
   Reason in two sentences.

7. WHAT CHANGES THIS ANSWER
   We will re-brief you before signing for any new product, major version,
   new build pipeline, acquisition, or material incident in a build system.

Keep the body to two pages. Attach the evidence index and the POA&M as appendices. The CEO reads sections 1, 3, 5 and 6; counsel reads all of it.

How gaps are handled, and what the CEO should see

The form's instructions anticipate gaps. If an agency cannot obtain a complete self-attestation, it may still decide to use the software if the producer identifies the practices it cannot attest to, documents the practices it has in place to mitigate the associated risks, and submits a plan of actions and milestones. Under the rescinded memos the agency then had to seek an extension or waiver from OMB for continued use. Under M-26-05 that decision sits with the agency's own risk-based process, so expect the agency to judge the POA&M on its merits.

A POA&M entry that an agency can act on, and that a CEO can stand behind, has six fields:

What the CEO should see is short: how many lines are not fully in place, what each gap means in one sentence of business language, the mitigation, and the date. If the CEO would be surprised to learn about a gap from a third party, it belongs on the first page.

Put each milestone into the owning team's normal planning system and report monthly until it closes. When it closes, decide with counsel whether to send a revised attestation (Section I has a "Revised Attestation" box).

What liability attaches to an inaccurate attestation

This section is the reason the CEO wants a brief, so be plain about it, and then let counsel speak to your specific facts.

The warning printed on the form. The Privacy Act statement on the form's first page says that willfully providing false or misleading information may constitute a violation of 18 U.S.C. 1001, a criminal statute. Section 1001 covers anyone who, in a matter within federal jurisdiction, knowingly and willfully makes a materially false statement or uses a false document, and it carries fines and up to five years' imprisonment in the ordinary case.

The False Claims Act. Under 31 U.S.C. 3729(a)(1), a person who knowingly presents a false claim for payment, or knowingly makes or uses a false record or statement material to a false claim, is liable for a civil penalty (stated in the statute as 5,000 to 10,000 dollars per violation, adjusted for inflation) plus three times the government's damages. Two definitions matter for a CEO:

• "Knowingly" in section 3729(b)(1) covers actual knowledge, deliberate ignorance of the truth, and reckless disregard of the truth, and it requires "no proof of specific intent to defraud".
• "Material" in section 3729(b)(4) means having a natural tendency to influence payment.

Read together, a signature placed without checking, on a form an agency relied on to buy software, is the shape of risk that statute describes. That is not a prediction about any case. It is why "to the best of my knowledge" has to be backed by actual knowledge.

Who can bring a case. The Attorney General may sue under 31 U.S.C. 3730(a), and section 3730(b) lets a private person bring a civil action in the government's name. A current or former employee who knows a practice was not in place can start that process, so your dated record of gaps and owners matters.

How the Justice Department applies it to cybersecurity. On 6 October 2021 the Deputy Attorney General announced the Civil Cyber-Fraud Initiative, which uses the False Claims Act against government contractors and grant recipients that knowingly provide deficient cybersecurity products or services, knowingly misrepresent their cybersecurity practices or protocols, or knowingly violate obligations to monitor and report cyber incidents. Since then the Department has announced settlements with contractors and research institutions over alleged misrepresentations of security controls. The details of each are allegations resolved by settlement, so read them as signals of where enforcement looks, not as findings.

What the brief should say. Three sentences: the form warns about false statements; the False Claims Act reaches reckless disregard, not only intent; and the Justice Department targets misrepresented cybersecurity practices. Then point to counsel's note.

Keeping the brief current for the next release or contract

A signed attestation is a standing statement: it binds future versions, and the signer promises to notify if practices stop being consistent. Write these refresh triggers into the brief's last section:

The cheapest way to keep the brief current is continuous evidence: SBOMs and scans on every release, gate results and exception records that exist whether or not anyone is preparing a brief. Then a refresh is an export and a review.

For how this evidence package looks from the agency's side, see how to prove secure software development to a federal contracting officer, and for the form in general, the CISA secure software development attestation form explained.

How Safeguard does this

Safeguard can carry the technical half of the evidence: items 2, 3 and 4 of the form, and the release-time proof that sits behind them. Every capability below is GA. The steps follow Safeguard's own docs; where the docs show a command or YAML, it is reproduced as shown, and we did not run those snippets for this post.

1. Generate an SBOM for every release (SBOM generation and analysis, GA). Safeguard produces SBOMs in SPDX and CycloneDX and can scan continuously on push, on a schedule or on release. From the CLI (GA), the docs show a scan of a local directory, which builds an SBOM, matches it against vulnerability databases and writes JSON results under ./output:

   safeguard scan --dir .
   

   The same command takes --image, --repo or --sbom targets. The docs note that it exits 0 whenever the scan ran, whatever it found; gating on findings is done by policy gates in the platform. To see results in the platform, scan from the interactive terminal (/scan .) while signed in. This is evidence for item 3 and SSDF PS.3.2.

2. Attest each build with SLSA provenance and in-toto (attestation and signing, GA). Safeguard's attestation docs describe in-toto v1 attestations for SLSA provenance, CycloneDX and SPDX SBOMs, and a vulnerability scan snapshot taken at build time. The documented CI step is:

   - name: Attest build
     uses: safeguard/attest@v2
     with:
       artifact: ./dist/app.tar.gz
       predicates:
         - slsa-provenance
         - sbom-cyclonedx
         - vuln-scan
   

   The docs say this step runs in common CI systems and in Safeguard's runner. Each attestation carries the artifact's SHA-256 digest, so a change to the artifact invalidates it. Attestation records for projects, products and components appear on their Attestation tab in the app, where the ESSCM view shows provenance fields such as build platform, source repository and build timestamp, plus a SCAL score for each component. This is evidence for items 3 and 4(a), and for SSDF PS.2.1 and PS.3.2.

3. Check SBOMs against EO 14028 requirements (EO 14028 checks in ESSCM and Portal Compliance, GA). Open a project from the Projects page and go to its Compliance tab to see the EO 14028 status; at organization level the Dashboard has an EO 14028 Compliance widget. To produce a report, open the project and choose Export, then EO 14028 Compliance Report, in PDF, HTML or JSON. The report includes an executive summary, SBOM details, component analysis, a gap analysis and remediation steps. In Portal (the SBOM publish and share product, not the free tier), the Compliance view scores each SBOM and shows its gaps. One caution: the docs describe these checks against the NTIA minimum elements, which CISA's 2026 Minimum Elements replaced. Treat the result as a completeness test on your own artifacts, not a Safeguard authorization of your product.

4. Track SSDF as a framework (Compliance and GRC suite with NIST SSDF, GA). In the Compliance suite, the NIST SSDF framework page lists scan requirements that a product scan decides, tied to SP 800-218 tasks including PS.3.2 (provenance data and SBOM), PS.2.1 (release integrity), PW.4.1 and PW.4.4 (well-secured and verified components) and RV.1.1 (identify vulnerabilities in components). The framework's other controls, such as secure development environments and developer training, are evidenced with automated tests, uploaded evidence, policies or an attestation. That split is useful for the brief: it shows exactly which lines a scan can decide and which need evidence from your other systems.

5. Enforce the release policy and record exceptions (policies, gates and guardrails, GA). Item 4(b) asks for a policy or process to address vulnerabilities before release. In Safeguard, policies evaluate SBOMs and generate findings, and gates enforce them. Each policy's action decides what a failure does to the gate: Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and a notification is sent). When a team needs to ship with a known issue, it requests an exception with the policy, the finding, a business justification and an expiration date; approvers decide, and the audit trail records it. The docs show a CI job failing on a gate with:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   Exception history becomes the evidence that discovered vulnerabilities are addressed or consciously accepted before release, which is precisely what item 4(b) and SSDF RV.2.2 ask about.

6. Keep an audit trail of what you shared (Portal audit trails, GA). If you share SBOMs or reports with an agency through Portal, the audit trail logs SBOM creation, changes, views, downloads, sharing events and permission changes, each with timestamp, actor, action and resource. When the brief says "we provided SBOM version X on date Y", this is where that line comes from.

7. Close the gaps you find (autonomous remediation, GA, ships off). When a scan before release finds a vulnerable dependency with a fixed version, Safeguard's Griffin models can open a fix pull request for one repository or in bulk. Autonomous remediation ships switched off, with every category set to Manual, so your team chooses what runs automatically. For the brief, merged fix pull requests are dated evidence that item 2's "manage related vulnerabilities" is happening, not just being measured.

Here is how that lines up with the form:

What Safeguard does not do

Be as clear about this in the brief as about anything else.

1. It does not sign or submit the form, and it holds no federal authorization for your product. The signature is your CEO's, and submission happens through the agency's email channel or CISA's repository. Safeguard's EO 14028 checks and compliance scores describe your artifacts; they are not a government determination. Safeguard's own posture is designed for FedRAMP High, with a SOC 2 Type II audit in progress, and none of that transfers to your product.
2. It does not evidence your organisational practices on its own. Environment separation, MFA, trust relationship reviews, encryption, build system monitoring, developer training and incident response live in your identity, cloud, logging and HR systems. You can upload that evidence against controls, but someone still has to produce it.
3. It cannot see build systems it is not connected to. A pipeline that never runs a scan or the attestation step leaves no record. The brief's scope must match the pipelines that are actually instrumented.
4. An SBOM is only as accurate as its inputs. Vendored code, copied binaries, unpinned versions and private packages can be missed or misidentified. Review SBOM completeness for your highest-risk products by hand at least once.
5. It gives no legal advice. It cannot tell you whether a gap is material, whether a prior attestation needs a notification, or how the False Claims Act applies to your facts. That is counsel's job.
6. It does not run your vulnerability disclosure program. Item 4(c) needs a public policy, an intake channel and response times that you operate.
7. The EO 14028 checks follow the older NTIA elements in the current docs. Compare outputs against CISA's 2026 Minimum Elements yourself. The REST endpoints on some of these docs pages are marked as not yet available, so use the app, the CLI or CI.

Common mistakes

• Signing because the deal needs it this week. The form allows a POA&M path. A late but honest submission is better than a fast and wrong one.
• Treating "no longer required" as "no longer relevant". M-26-05 removed the mandate, not the form. Agencies may still ask, and earlier attestations still say what they say.
• Forgetting what is already on record. Many teams brief the new signature and never check the forms signed in 2024 and 2025 that bind future versions.
• Grading on intent, not evidence. "We have a policy" is not the same as "the policy runs on every pipeline". Grade only what you can export.
• Scoping by product name, not by pipeline. One product can ship from several pipelines (cloud service, on-premises package, government region). Each one is in scope.
• Leaving item 1 to the security team alone. Most of item 1 is owned by platform and IT. Get their names on the evidence index.
• Treating a compliance score as an attestation. A green dashboard means your SBOM fields are populated. It says nothing about MFA on your build host.
• No refresh trigger. Without named triggers, the brief goes stale the day the next pipeline ships.

FAQ

What should a CEO know before signing the CISA secure software attestation form?

That they are attesting, to the best of their knowledge, that the company presently and consistently uses four groups of secure development practices for the named software, and will notify the agency if that stops. They should see the evidence behind each line, every gap with its plan of action, and counsel's note on liability.

Is the CISA attestation form still required in 2026?

Not government-wide. OMB M-26-05, dated 23 January 2026, rescinded M-22-18 and M-23-16, which had required agencies to collect it. The memo says agencies may still choose to use the form and may require a current SBOM on request by contract. So an agency, a contract or a prime can still ask for it.

Who is allowed to sign the attestation form?

The CEO of the software producer, or a designee who is an employee of the producer and has authority to bind the corporation. If you submit a qualifying third-party assessment by an approved 3PAO instead, the form does not need a signature.

Does an attestation we signed in 2024 still count?

The form says attestations bind future versions of the named software until the producer notifies the agencies that its practices no longer conform. The rescission removed the requirement to collect forms; it did not withdraw statements already made. Ask counsel how that applies to your submissions.

What happens if we cannot attest to every practice?

The form's instructions describe the path: identify the practices you cannot attest to, document the mitigations you have in place, and submit a plan of actions and milestones. The agency then decides whether to use the software.

Can a false attestation lead to False Claims Act liability?

It can be the kind of statement the False Claims Act reaches. Section 3729 covers knowingly false records material to a claim, and "knowingly" includes reckless disregard without proof of intent to defraud. The form itself also warns about 18 U.S.C. 1001. Whether a specific statement creates liability is a legal question for counsel.

Do we need an SBOM to sign the attestation form?

The form does not ask you to attach one. But item 3 requires provenance for internal code and third-party components, and the SSDF task behind it (PS.3.2) names an SBOM as the example. M-26-05 also lets agencies require a current SBOM on request by contract, so having one per release is the practical answer.

How often should the CEO brief be refreshed?

On every trigger that changes scope or evidence: a new product or major version, a new pipeline, an acquisition, a material build-system incident, a POA&M milestone closing or slipping, or a new request for the form. At minimum, review it when each federal contract renews.

Everything above assumes you can fix the gaps you find before the next signature. When the gap is a vulnerable open source dependency, the fastest route to an item 4(b) answer you can defend is a fix that ships, whether or not upstream has released one yet.

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, Safeguard's Griffin models open 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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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 a lodash CVE in a repository. The CLI reads the finding and the 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; it then shows /permissions, /model and /scan . For an attestation brief, this is what item 4(b) looks like in practice: a found vulnerability addressed before release, with a person approving each change.

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. If some of the products in your attestation scope build on machines you control, this is the route to get SBOMs and findings for those pipelines into the same place as the rest of your evidence.

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

Quick check

To try the CLI and local runner on your own pipelines, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs.

Sources

• CISA: Secure Software Development Attestation Form (main page, archived content)
• CISA: Secure Software Development Attestation Form resource page
• CISA: Secure Software Development Attestation Form and instructions (PDF, Version 1.0)
• OMB Memorandum M-26-05, Adopting a Risk-based Approach to Software and Hardware Security (PDF)
• NIST SP 800-218, Secure Software Development Framework version 1.1 (PDF)
• NIST SP 800-218 Rev. 1, SSDF version 1.2, initial public draft
• Executive Order 14028, Improving the Nation's Cybersecurity, Federal Register (PDF)
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• 31 U.S.C. 3729, False claims (govinfo)
• 31 U.S.C. 3730, Civil actions for false claims (govinfo)
• 18 U.S.C. 1001, Statements or entries generally (govinfo)
• U.S. Department of Justice: Deputy Attorney General announces the Civil Cyber-Fraud Initiative
• Safeguard docs: EO 14028 Compliance Checks
• Safeguard docs: Attestation and Signing
• Safeguard docs: ESSCM Attestation
• Safeguard docs: Portal Compliance
• Safeguard docs: NIST SSDF framework
• Safeguard docs: Policies and Gates
• Safeguard docs: Portal Audit Trails
• Safeguard docs: CLI usage

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