Vet your suppliers' components before you re-attest to a federal agency

Before you re-attest for a federal option year, you need four things on file for every product the attestation names: a current inventory of the commercial and open source components inside it, the SBOMs and security answers you requested from each commercial supplier (or a record of their refusal), a written open source policy with the results of applying it, and a dated decision log for every exception. The CISA form does not ask you to attest for your suppliers, but its items 2 and 3 ask you to attest that you secure and keep provenance for the third-party components you ship.

This post is the working plan for the person who has to assemble that evidence: the procurement, supplier risk or vendor management owner at a software company that sells to US federal agencies. The first two thirds work with a spreadsheet, a shared drive and whatever scanners your engineering team already runs. Safeguard comes in later, in a clearly marked section. Nothing here is legal advice; your contracts officer and counsel decide what your contract requires.

Key takeaways

• The attestation covers your practices, including how you handle third-party components. CISA's form says third-party open source and proprietary components incorporated into your product do not need their own attestation, but form items 2 and 3 cover your work to secure them and keep their provenance.
• The government-wide mandate changed in January 2026. OMB M-26-05 rescinded M-22-18 and M-23-16. Agencies may still use the Secure Software Development Attestation Form and may ask for an SBOM by contract, so your option year may still require a refreshed or revised attestation. Read your contract, not the old memo.
• SSDF PW.4.1 and PW.4.4 are the practices behind the third-party wording. Acquire well-secured components with provenance (PW.4.1) and verify that acquired commercial, open source and other third-party components keep meeting your requirements through their life cycle (PW.4.4).
• Inventory first, then ask, then judge. Build a per product component inventory, send commercial suppliers a standard request, and judge open source with written policy instead of one-off debates.
• Keep an evidence pack per product and per option year. Inventory snapshot, supplier request log, policy and policy results, exceptions with owners and expiry dates, and the signed form.
• Safeguard capabilities used here, all GA: SBOM generation and analysis (GA), SCA and vulnerability management (GA), TPRM vendor management, SBOM requests and validation (GA), license compliance (GA), policies and gates with Block, Warn and Notify actions and approval through exceptions (GA), and Portal compliance checks for EO 14028 (GA). Safeguard does not sign the attestation and holds no federal authorization for you.

The situation

The contract has an option year coming up. The agency's contracting officer, or the program office, has asked for a current Secure Software Development Attestation, or your contract says one must be on file before the option is exercised. Your CEO, or a designee with authority to bind the company, will sign it. Legal will read it. Engineering will say the pipeline is fine.

And then someone asks the question that lands on your desk: what about the stuff we did not write? The commercial SDK for document rendering. The licensed analytics library. The open source packages pulled in by the open source packages. The container base image. The one component a contractor added three years ago that nobody owns.

The signer is about to say that the company makes "a good-faith effort" to secure third-party components and keeps their provenance "to the greatest extent feasible". Those phrases are about practices, not perfection. If anyone tests them later, the question will be what the company actually did. That evidence is what you are building.

A bad week: the form is due Friday, and on Wednesday a scan finds a known exploited vulnerability in a component of a named product. Nobody knows the supplier, whether there is a fix, or what the old attestation promised. The signer hesitates and legal asks for a POA&M. The plan below exists so that Wednesday is uneventful.

The rules behind it

The CISA Secure Software Development Attestation Form

CISA's common form is the document most agencies use. It carries OMB control number 1670-0052 with an expiration date of 31 March 2027 printed on each page of the version we read. Here is what it says that matters to a supplier risk owner.

Scope of third-party components. The form lists four categories that do not require a self-attestation. The third is "Third-party open source and proprietary components that are incorporated into the software end product used by the agency." The next paragraph says producers who use third-party components "are required to attest that they have taken specific steps", detailed in Section III, to minimize the risks of relying on them. So your suppliers do not sign your form, and you do not sign theirs. You attest to your own handling of what they give you.

Section III, item 2. The producer "makes a good-faith effort to maintain trusted source code supply chains by employing automated tools or comparable processes to address the security of internal code and third-party components and manage related vulnerabilities". The form's mapping table ties it to EO 14028 section 4(e)(iii) and to SSDF tasks including PW.4.1 and PW.4.4.

Section III, item 3. The producer "maintains provenance for internal code and third-party components incorporated into the software to the greatest extent feasible". The mapping table ties it to section 4(e)(vi) and to tasks including PO.1.3, PW.4.1 and PW.4.4.

Section III, item 4. Vulnerability checks run on an ongoing basis and before releases, there is a process to address discovered vulnerabilities before release, and the producer runs a vulnerability disclosure program. Third-party components supply most of what item 4 will find.

Types of attestation. Section I offers New Attestation, Attestation Following Extension or Waiver, and Revised Attestation, company-wide, per product, or for specific versions. A footnote says attestations "are binding for future versions" of the named product until the producer notifies the agencies that its practices no longer conform. So for an option year you may be confirming an existing attestation rather than writing a new one; the contract decides which.

When you cannot attest. An agency may still use the software if the producer identifies the practices it cannot attest to, documents mitigations and submits a plan of action and milestones (POA&M). A Third Party Assessor Organization (3PAO) assessment is another route the form allows.

Who signs. The CEO or a designee with authority to bind the company. Your job is to make sure that person has the evidence to stand behind items 2 and 3.

The form's instructions still reference M-22-18 as amended by M-23-16, because it was written under them. That brings us to the change you need to know about.

OMB M-26-05: the mandate became agency discretion

On 23 January 2026, OMB issued M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security". It rescinds M-22-18 and its companion M-23-16. In OMB's words, the earlier policy "prioritized compliance over genuine security investments".

What the memo keeps is what matters to you:

• Agencies "shall continue to maintain a complete inventory of software and hardware" and develop assurance policies that match their risk determinations.
• Agencies "may choose to use" the resources developed under M-22-18, naming the Secure Software Development Attestation Form.
• Agencies may adopt contractual terms requiring a producer to provide a current SBOM on request. For a cloud platform, the memo's footnote says the SBOM should cover the runtime production environment.
• Agencies can reference NIST SP 800-218 and CISA's SBOM minimum elements guidance. The memo cites the 2025 draft; CISA has since published the final 2026 version.

So there is no longer one government-wide rule that every producer must attest. There is your contract and your agency's own policy. If the option year asks for the form, treat it exactly as before; if it asks for an SBOM on request, the inventory work below produces it.

NIST SP 800-218 (SSDF) PW.4.1 and PW.4.4

The SSDF, version 1.1, is the source of the practices the form draws on. Practice PW.4 is "Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality". Two of its tasks are the core of your work.

PW.4.1: acquire and maintain well-secured components "from commercial, open-source, and other third-party developers". Its examples include reviewing components in the context of their expected use (Example 1), obtaining provenance such as an SBOM for each component and analyzing it (Example 3), keeping a list of approved commercial components and versions with provenance data (Example 5), and building from verified source when binary provenance cannot be confirmed (Example 8).

PW.4.4: verify that acquired commercial, open source and other third-party components comply with the requirements, "as defined by the organization, throughout their life cycles." Its examples include checking for public vulnerabilities vendors have not fixed, automatic detection in the toolchain, confirming components are maintained and not end of life, planning for unmaintained ones, and confirming integrity through signatures or other mechanisms.

"As defined by the organization" means the SSDF gives you no license list, severity threshold or maintenance rule. You write those, which is why the policy step below matters.

PO.1.3 says to communicate requirements to third parties who provide commercial components. Its examples include putting security requirements into contracts, selection criteria such as the supplier's vulnerability disclosure program, and asking third parties to attest that their software meets your requirements. This is the basis for what you ask suppliers for.

The SSDF maps PW.4.1 and PW.4.4 to NIST SP 800-161 controls including SA-4, SR-3 and SR-4. SP 800-161 Rev. 1 (May 2022, updated November 2024) is NIST's broader supply chain risk management guidance and the source of many agencies' own supplier expectations.

CISA's 2026 Minimum Elements for an SBOM

On 29 July 2026, CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials. CISA says it "updates and replaces" the NTIA 2021 minimum elements. If your contract asks for an SBOM, or you ask suppliers for one, this is the current baseline.

Table 1 of the document lists the data fields: Component Dependency Relationship, Component Hash Algorithm, Component Hash Value, Component Identifiers, Component License, Component Name, Component Producer, Component Version, SBOM Author, SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Timestamp, SBOM Tool Name, SBOM Tool Version and SBOM Version.

Compared with 2021, the changes a supplier risk owner will notice: component hashes and license identifiers are now minimum elements, the SBOM should carry an author signature, the tool and its version are recorded, and "Known Unknowns" is replaced by explicitly identifying unknown information, separating what is unknown from what the author knows but chooses to withhold. That last change is useful when a commercial supplier hands you a partial SBOM: you can ask them to say which parts are withheld and which are simply unknown.

OpenSSF Scorecard as a public signal for open source

The OpenSSF Scorecard project runs automated checks of an open source project's practices, including Maintained, Vulnerabilities, Security-Policy, Signed-Releases, Code-Review and Pinned-Dependencies. Maintained gives the top score for at least one commit a week over 90 days, and its docs say a lack of maintenance "is not necessarily always a problem" for small utilities. Treat Scorecard as one input, not a verdict.

Step by step: re-attestation readiness for third-party components

These ten steps work with any tooling. Start them at least six weeks before the attestation is due; an option year date is usually known months ahead, so you can plan.

Step 1. Confirm what you are attesting to, and for which products

Get the contract language and the previous attestation, and answer in writing: does the option year need a new form, a revised one, a confirmation, an SBOM on request, or nothing new? Is the attestation company-wide, per product or per version? Which named products have shipped a major version since? The answers bound your work.

Step 2. Build the supplier register

List every third party whose code ends up in a named product. Separate them into four groups, because you will handle each differently:

Give each commercial supplier a risk tier. A simple rule: tier 1 if the component handles authentication, cryptography, parsing of untrusted input or agency data; tier 2 if it runs in production without those; tier 3 if it is build time or test only.

Step 3. Inventory components per product and per version

You need an SBOM, or an equivalent inventory, for each named product and version. Generate it from the build or the lockfiles, not from memory. Make sure it includes transitive dependencies, because most open source components arrive that way.

Check each inventory against the 2026 minimum elements; producer, hashes, licenses and dependency relationships are the fields most often missing. Save it with a date, the product version and the generating tool. This is your item 3 provenance evidence.

Step 4. Send commercial suppliers a standard request

Use one template for every commercial supplier, tiered by risk. A tier 1 request might look like this:

Tier 2 suppliers get the first four rows. Tier 3 suppliers get the first and fourth. Set a deadline two to three weeks before the attestation date and log every send, view, reply and follow-up.

Step 5. Decide what happens when a supplier refuses or stalls

Some will. Write the rules before replies arrive:

1. Partial SBOM with explicit unknowns: accept and record. The 2026 minimum elements expect authors to separate unknown from withheld information.
2. No SBOM, but an advisory feed and a support policy: accept for tier 2 and 3; for tier 1, compensate with your own binary or composition analysis of what you receive, and record it as a risk with an owner and a review date.
3. No answer at all: escalate through the contract owner. Record what you asked, when, and the follow-ups. For a tier 1 component, consider whether the signer can stand behind item 2 for that product; if not, that is a POA&M conversation, not a silent omission.
4. A refusal and a known exploitable vulnerability: this is a replacement decision. Bring it to engineering and the signer immediately.

A dated, complete request log is how you show "good-faith effort" when a supplier does not cooperate.

Step 6. Write the open source policy

Open source has no supplier to ask, so policy does the asking. Keep it to one page and make every rule testable. A starting point:

The thresholds are yours to set. Make the policy "as defined by the organization", in the SSDF's words, and get engineering and legal to sign off on it once, not per component.

Step 7. Run the policy against every named product

Apply the policy to each inventory and record the result per product and version: passed, passed with warnings, or failed. For each failure, the outcome is one of fix, replace, or exception. Do not leave a failure without one of those three.

Step 8. Record exceptions with an owner and an expiry

Every exception needs the same fields, or it will not survive an audit or a second option year:

• Component, version and product
• The rule it breaks
• Business justification and the compensating control
• Owner (a named person, not a team)
• Approver
• Expiry date, set before the next attestation or option year
• Triggers that reopen it early, such as a KEV listing or a supplier end of life notice

Step 9. Assemble the evidence pack

One folder per product, per option year. A checklist:

• Contract excerpt showing what the option year requires
• Previous attestation and any notifications sent since
• Supplier register with tiers
• Dated SBOM or inventory per named product version, with generating tool and version
• Supplier request log: sent, viewed, replied, follow-ups, outcome
• Supplier responses (SBOMs, VDP links, support dates, attestations)
• Open source policy, version and approval record
• Policy results per product and version
• Exception register with owners and expiry dates
• Vulnerability status at the time of signing, with any fixes in progress
• A one-page summary for the signer
• The signed form, or the POA&M and supporting material

Step 10. Brief the signer

Give the CEO or designee one page, not the folder: products and versions covered, component counts, supplier responses (full, partial, none), open source policy failures and how each is handled, and anything that would make item 2 or 3 untrue for a named product. If there is such an item, recommend the POA&M route in writing.

What does the CISA attestation form say about third-party components?

Two things that read as contradictory until you put them together. Third-party open source and proprietary components incorporated into the product do not need their own self-attestation. But producers who use them must attest that they have taken the Section III steps to minimize the risks of relying on them.

So no supplier signs the CISA form for you, and you still need evidence that your process covers their components under items 2 and 3. The form's note says the producer attests to practices "for code developed by the producer", which is why your evidence is about how you handle supplier code, not about the supplier's internal development.

For a deeper read on the signer's role and the item by item SSDF mapping, see who signs the CISA secure software attestation form and the attestation form items mapped to SSDF practices table.

What do SSDF PW.4.1 and PW.4.4 expect when acquiring and reusing software?

PW.4.1 is the front door: acquire well-secured components and know where they came from. PW.4.4 is the life cycle: keep verifying they still meet your requirements. Read together with their examples (quoted in the rules section above), they describe three recurring activities: inventory with provenance, policy evaluation against requirements you define, and continuous monitoring. Your evidence pack should show all three for each named product, with dates.

How do you inventory commercial and open source components in every product?

Generate inventories from what you actually build, not from a questionnaire to engineering. For each named product:

1. Source dependencies. Generate an SBOM from the repository's lockfiles and manifests, including transitive dependencies.
2. Container images. Generate an SBOM for each image you ship, including the base image layers.
3. Commercial binaries. List them with the supplier as producer, the version and a hash of the file you ship. Mark internals as unknown until the supplier's SBOM arrives, then attach it.
4. Runtime environment for cloud products. If you run a hosted service for the agency, M-26-05's footnote says an SBOM request for a cloud platform should cover the runtime production environment. Plan for that scope.

Then reconcile. An illustrative example with round invented numbers: a product with 20 direct open source dependencies can show several hundred components once transitive dependencies and image layers are counted. If your inventory shows only the 20, it came from the wrong place.

Regenerate on every release of a named product and keep each version's SBOM, because the later question will be about the version the agency ran.

The related post on federal software procurement SBOM requirements covers what agencies tend to ask for in SBOM delivery.

What do you request from commercial suppliers, and what if they refuse?

Ask for what you will use, and nothing more. The tiered template in Step 4 is built from PO.1.3 and PW.4.1 and PW.4.4: an SBOM meeting the 2026 elements, the supplier's vulnerability disclosure program, how and how fast they notify you of vulnerabilities, support and end of life dates, any secure development attestation of their own, and integrity mechanisms.

Requests that name a deadline and cite a contract obligation get faster answers. Send tier 1 first, remind once before the deadline and once at it, and escalate a week after.

When they refuse, the Step 5 rules apply: refusal is a fact to record and manage, not a gap to hide. For a tier 1 component you can compensate with your own analysis, replace it, accept the risk with an owner and expiry, or raise a POA&M item if the signer cannot stand behind item 2. That is a business decision, and it should be written down.

Then fix it for next year in the contract. PO.1.3 Example 1 suggests putting a core set of security requirements into software contracts. SBOM delivery, vulnerability notification and support period clauses turn next year's request into a reminder.

How do you assess open source components by policy instead of case by case?

Case by case review does not scale and produces decisions you cannot defend. Policy scales and shows the requirements were "defined by the organization", as PW.4.4 says. Principles that make the Step 6 policy work:

• Separate the rule from the review. People look only at failures; every pass is evidence by itself.
• Use public signals for maintenance and practices. OpenSSF Scorecard checks such as Maintained, Security-Policy, Signed-Releases and Vulnerabilities give consistent, repeatable signals. Use them to sort, not to approve automatically.
• Make license review a list, not a debate. Counsel sets allowed, blocked and review licenses once. The policy applies them.
• Apply the same rule at intake and at release. Vulnerability data changes after a dependency is merged.
• Review new direct dependencies with a short checklist. The post on how to review a new dependency in 30 minutes with OpenSSF practical checks is a good companion to the policy.

A policy will not catch everything, but it makes decisions consistent and explainable, which is what "good-faith effort" needs.

What evidence do you keep for the agency and the option year after?

Keep the Step 9 pack per version. Later questions are specific: which version did the agency run, what was in it, what did you know, and what did you do.

Your records policy and contract govern retention. Next option year, this pack is the baseline: what changed, which suppliers changed, which exceptions expired, and whether anything requires notifying the agency under the form's "binding for future versions" footnote.

What stays the producer's job?

Whatever tools you use, these remain yours:

• The attestation itself. The CEO or designee signs; no tool or supplier signs for you.
• Supplier contracts. Deliverables and remedies live in your contracts.
• Practices outside software. Item 1 (build environments, trust relationship logging, MFA, encryption, defensive operations) is security engineering and IT work.
• Your vulnerability disclosure program under item 4(c).
• The judgement calls. Which exceptions to accept, and when to choose a POA&M over a signature.
• Notifying agencies if your practices stop conforming, as the form's last paragraph requires.

How Safeguard does this

Everything above works with spreadsheets and your existing scanners. Here is how the same plan maps onto Safeguard, using only what its offering documentation and docs.safeguard.sh describe; screens and commands are as the docs show them.

1. Generate an SBOM for every named product

Safeguard's SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs, with continuous scanning on push, on a schedule or on release, according to the offering documentation. Its software composition analysis (GA) builds a full transitive inventory, including container layers.

Per the Generate SBOM docs, you start from Integrations in the sidebar, which lists source code (GitHub, GitLab, Bitbucket, generic Git), container image registries and uploads such as package manifests. When connecting a repository you set a project name and a version, which keeps one SBOM per named product version.

If engineering prefers CI, the CI/CD integration docs describe one step that runs the Safeguard CLI; each push becomes a new version of its project, and --local scans on the runner so only results leave it. For you, the outcome is what matters: a dated, versioned inventory per release that nobody compiled by hand.

2. Register commercial suppliers and their contracts

TPRM, Safeguard's Third-Party Risk Manager (GA), keeps the supplier register. The Vendor Management docs describe adding a vendor from Vendors, Add Vendor with company name, primary contact, contact email, website, products used and risk tier, and a bulk import from a CSV template. Each vendor record carries contract status, a risk tier of Critical, High, Medium or Low, SBOM status (received, requested or none) and the last assessment date.

Contracts can be linked with dates, SLA terms, security requirements and SBOM obligations, which is where your PO.1.3 clauses go. Manual tier changes require a documented justification. A vendor portal lets suppliers update their details, submit SBOMs and answer questionnaires.

3. Send SBOM requests and track every response

This is the part of TPRM (GA) that replaces the request spreadsheet. Per the SBOM Requests docs:

1. Navigate to the vendor.
2. Click Request SBOM.
3. Select the products.
4. Choose a request template.
5. Customize the message if needed.
6. Set a deadline.
7. Click Send.

For many suppliers at once, the docs describe Bulk Request from the Vendors list. The standard template asks for SPDX or CycloneDX, the required fields and submission instructions; you can create custom templates under Settings, Request Templates, which is where your tiered request goes.

Each request moves through Sent, Viewed, In Progress, Submitted, then Validated or Rejected, with automatic reminders seven days before the deadline and at it, and an escalation seven days after. That status trail is your item 2 request log, including silence.

On submission, the docs say Safeguard validates the SPDX or CycloneDX format, checks required fields, verifies EO 14028 compliance, runs a vulnerability scan and notifies you. If the SBOM falls short, Request Revision sends the supplier the corrections.

4. Write the open source and license policy as policies and gates

License compliance (GA) parses SPDX license expressions and classifies licenses from permissive to network copyleft, per the offering documentation. The Suppliers and Licenses docs show, per project, each component's supplier and type (open source project, commercial vendor, internal or unknown) and a license status of Compliant, Review Needed, Violation or Unknown.

To create a license policy, the docs describe: go to Settings, License Policies, click New Policy, configure allowed or blocked licenses, set the scope to organization or project, and save. Rule types are allowlist, blocklist and review list. That review list is your counsel's "needs approval" list from Step 6.

The rest of the policy uses policies and gates (GA): policies evaluate your SBOMs and generate findings, and gates enforce them. Per the docs, you go to Settings, Policies, Create Policy, define conditions in the visual builder or YAML (severity, CVSS, EPSS, license, component age, maintenance), set severity and actions, then save and enable. Templates include No Critical Vulnerabilities and No Abandoned Packages.

Each policy has one action, and it decides what a failed policy does to the gate:

• Block: the gate fails.
• Warn: the gate passes, with a warning naming the policy.
• Notify: the gate passes, and a notification is sent.

Your Step 6 table maps directly: KEV and critical rules on Block, high and maintenance on Warn, and informational rules on Notify. For a release check, the docs show safeguard ci scan --wait --fail-on-gate <gate>, which fails the CI job when the gate is not Passed or Warning, with policy outcomes on for your workspace.

5. Record exceptions with an expiry

Approval in Safeguard runs through exceptions, not a separate gate action. Per the Policies and Gates docs, a requester clicks Request Exception, selects the policy and finding, gives a business justification, sets an expiration date and submits it. Approvers are notified, decide, and an audit trail is recorded. The docs list compliance reporting on exception history and violation trends.

For suppliers, TPRM's Risk Assessment docs describe accepting a vendor risk with a justification, review date and approvals, and tracking vendor remediation commitments. Together these are your Step 8 register.

6. Check SBOM quality before you rely on it

The Portal's compliance checks (GA) validate SBOMs against EO 14028 requirements. In this sense Portal means the SBOM publish, share and management product, not the free entry tier. Per the Portal Compliance docs, checks cover minimum fields, component identifiers, supplier information, version information, dependency relationships and hash values, with a compliance score and a gap analysis you open from the SBOM's Compliance tab. Reports include an EO 14028 compliance report, a minimum elements report, a gap analysis report and a full audit package, exported as PDF or Excel.

The EO 14028 Compliance Checks docs add a per project Compliance tab and an organization widget on the Dashboard. There is no CLI command for this report yet and the page's /v1 REST endpoints are not available today, so use the in-app export. Safeguard's docs describe these checks against the NTIA elements; check the 2026 additions (author signature, tool name and version, generation context) yourself.

7. Keep monitoring after you sign

PW.4.4 says "throughout their life cycles". Vulnerability management (GA) matches components against sources including NVD, GHSA, OSV and CISA KEV, per the offering documentation, and TPRM monitoring (GA) alerts on a new critical vulnerability, a KEV addition, a risk change or an SBOM expiry. That last alert is your reminder for the next option year.

What Safeguard does not do

• It does not sign or file the attestation. The CEO or designee signs. Safeguard holds no federal authorization on your behalf. Safeguard's own posture is designed for FedRAMP High, and its SOC 2 Type II audit is in progress; neither changes what your company attests.
• It cannot make suppliers respond. TPRM tracks requests, reminders and escalations, but a supplier that refuses still refuses. The contract and your relationship do that work.
• Policy evaluation is not a guarantee. A component that passes your policy can still carry an undisclosed flaw. Policies make decisions consistent; they do not make components safe.
• It does not decide your thresholds or exceptions. Safeguard enforces the rules you set. Which licenses are acceptable, which vulnerabilities can wait and which exceptions to grant are your decisions.
• It does not cover item 1 of the form. Build environment separation, MFA, logging of trust relationships and incident response are outside component vetting.
• Its SBOM quality checks follow the NTIA elements in the docs. Validate the 2026 additions yourself.
• It is not legal advice. Nothing in the product or this post interprets your contract.

Common mistakes

• Treating the old mandate as current. M-22-18 and M-23-16 are rescinded; read the contract.
• Assuming suppliers must sign the CISA form. They do not.
• Inventorying direct dependencies only. Most open source arrives transitively.
• One SBOM for all versions. Keep one per named version.
• Sending requests two weeks before signing. Start six weeks out.
• Exceptions without an expiry. They become permanent, undocumented policy.
• Hiding a refusal. A recorded refusal with a compensating control shows good faith; a missing entry looks like a gap.
• Using Scorecard as a gate on its own. Small, stable utilities can score low and still be fine.
• Forgetting the runtime for hosted products. M-26-05 points cloud SBOM requests at the runtime production environment.

FAQ

Do our third-party suppliers have to sign the CISA attestation form?

No. Components incorporated into your product need no attestation of their own. You attest that your practices address their security and provenance.

Is the CISA secure software attestation still required after M-26-05?

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 may add contract terms requiring an SBOM on request, so your contract or agency decides.

What does "to the greatest extent feasible" mean for provenance?

The form does not define it. Keep dated SBOMs per version and document what is unknown and why; counsel interprets the phrase for your contract.

What should we ask a commercial software supplier for before re-attesting?

An SBOM meeting CISA's 2026 minimum elements, their vulnerability disclosure program, how they notify you of vulnerabilities, support and end of life dates, any attestation of their own, and integrity mechanisms for releases.

What if a supplier refuses to provide an SBOM?

Record the request and refusal, compensate with your own analysis of what you receive, consider replacement, or accept the risk with an owner and expiry. If the signer cannot stand behind item 2 for a product, discuss a POA&M with the agency.

Which SSDF practices cover third-party components?

PW.4.1 (acquire well-secured components), PW.4.4 (keep verifying them) and PO.1.3 (communicate requirements to suppliers). The form maps items 2 and 3 to these and more.

What are CISA's 2026 SBOM minimum elements?

Published 29 July 2026, they replace the NTIA 2021 elements. Fields include component name, version, producer, identifiers, license, hash and dependency relationship, plus SBOM author, signature, tool, timestamp, format and generation context.

How often should we re-check third-party components after signing?

Every release of a named product, and continuously for new vulnerabilities and KEV additions. PW.4.4 says throughout the life cycle, and item 4(a) of the form says on an ongoing basis and before releases.

Can an open source policy replace manual review of every package?

For most packages, yes. Keep manual review for policy failures and new direct dependencies in sensitive roles.

What happens if we cannot attest to every practice?

The form's instructions allow the producer to identify the practices it cannot attest to, document mitigations and submit a plan of action and milestones. A 3PAO assessment is another route the form allows.

Third-party components are where the fix often depends on someone else's release schedule, which is exactly the gap that makes a supplier risk owner nervous before signing. The section below is Safeguard's standard description of how fixes move into your builds when upstream is slow or silent.

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 sets up the Safeguard local runner on your own machine, approves it with its device code, and then scans from the terminal. For a supplier risk owner, this is the shape of the inventory step: an engineer runs the scan where the code lives, and the dated SBOM and findings land in Safeguard for your evidence pack.

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

The second demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It 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. When your policy fails a release because of an open source component with a known fix, this is how an engineer can clear it before the signing date while a person stays in charge.

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

Quick check

To try the flow on your own products, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

Sources

• CISA, Secure Software Development Attestation Form
• CISA, Secure Software Development Attestation Form resource page
• CISA, Secure Software Development Attestation Common Form (PDF)
• OMB 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 publication page
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA, 2026 Minimum Elements for a Software Bill of Materials
• CISA, 2026 Minimum Elements for an SBOM (PDF)
• OpenSSF Scorecard
• OpenSSF Scorecard checks documentation
• Safeguard Docs, TPRM SBOM Requests
• Safeguard Docs, TPRM Vendor Management
• Safeguard Docs, TPRM Risk Assessment
• Safeguard Docs, Suppliers and Licenses
• Safeguard Docs, Policies and Gates
• Safeguard Docs, Portal Compliance
• Safeguard Docs, EO 14028 Compliance Checks
• Safeguard Docs, Generate SBOM
• Safeguard Docs, CI/CD Integration

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