NIST SSDF in Safeguard: What a Scan Checks and What You Still Prove

Safeguard's NIST SSDF framework page decides six requirements automatically on every product scan: provenance data in the SBOM, release integrity hashes, a named supplier for each component, a precise identifier such as a PURL, an exact version for advisory matching, and complete component records. Everything else in NIST SP 800-218, from build environment protection to code review, root cause analysis and the officer's signature on an attestation, is evidence your team still produces, and Safeguard holds it, routes it for approval and shows what is missing.

That split holds for SSDF work in any tool: SSDF is mostly about how your organization develops software, and a scanner sees artifacts, not habits. This post shows where the line falls, using NIST's own practice IDs and wording, and walks the Safeguard flow from switching the framework on to assembling an attestation package.

Key takeaways

• NIST SP 800-218 version 1.1 (February 2022) is still the final SSDF. A version 1.2 draft (SP 800-218 Rev. 1, December 2025) adds practices PO.6 and PS.4; its comment period closed on 30 January 2026.
• OMB M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16. Federal agencies may still choose to use the CISA Secure Software Development Attestation Form and may require an SBOM on request, so buyers keep asking SSDF questions.
• The Compliance and GRC suite (GA) includes NIST SSDF and NIST SP 800-218A as frameworks. Six SSDF requirements are decided by a scan; the rest are catalogue controls you evidence.
• SBOM generation and analysis (GA) produces the inventory those six checks read. Attestation and signing (GA) adds SCAL and LCAL attestation scores for components.
• Vulnerability management (GA), reachability analysis (GA) and policies and gates (GA) supply evidence for the Respond to Vulnerabilities group and turn SSDF expectations into release checks.
• Supporting pieces carry their own labels: CSAF and VEX upload (GA), autonomous remediation (GA, ships switched off), the CLI, local runner and MCP server (GA), and SAST and DAST (early access).
• Safeguard does not sign the attestation form. The CEO or COO of the software producer signs it, or a third party assessor's report replaces the signature.
• Safeguard's control catalogue pairs some SSDF IDs with names that do not match NIST's text. Use NIST's IDs and wording in anything you send to a buyer.

Where SSDF stands in October 2026

SSDF has had a busy two years, and the policy around it moved more than the framework itself. Before mapping anything, it helps to know which documents are final, which are drafts, and which have been withdrawn.

SP 800-218 version 1.1 is the final framework

NIST published SP 800-218, Secure Software Development Framework Version 1.1 in February 2022. It organizes secure development into four practice groups:

• Prepare the Organization (PO): people, processes and technology ready to do secure development, at the organization level and per project.
• Protect the Software (PS): protect every component of the software from tampering and unauthorized access.
• Produce Well-Secured Software (PW): produce software with minimal security vulnerabilities in its releases.
• Respond to Vulnerabilities (RV): find residual vulnerabilities in releases, respond, and prevent similar ones.

Each group contains practices (PO.1, PS.2) and each practice contains tasks (PO.1.1, PS.2.1). Tasks are what buyers and attestation forms cite. SSDF says what to achieve and leaves the how to the producer.

The version 1.2 draft adds two practices

On 17 December 2025 NIST released SP 800-218 Rev. 1, SSDF Version 1.2, as an initial public draft. The draft says it responds to Executive Order 14306 of 6 June 2025, which called for updating secure development practices and implementation examples. Its change log lists:

• New practice PO.6, Define and Implement a Continuous Process Improvement Plan, with tasks such as PO.6.1 (update and improve development environments as threats and tools change) and PO.6.2 (identify new processes, tools and techniques that help avoid software errors).
• New practice PS.4, on making software updates dependable, with tasks such as PS.4.1 (thoroughly test updates) and PS.4.2 (use tiered update and release strategies such as canaries and staged roll out).
• Updated wording for tasks RV.1.2 and RV.3.3, many added or revised examples, and removal of the old appendix that mapped SSDF to EO 14028.

The comment period closed on 30 January 2026. As of this writing the CSRC page still lists Rev. 1 as a draft, so cite version 1.1 as the governing text and treat PO.6 and PS.4 as signals of where the framework is heading. Nothing in the draft changes the IDs of the tasks discussed below.

SP 800-218A covers AI model development

SP 800-218A, final since July 2024, is an SSDF Community Profile for generative AI and dual-use foundation models. It adds AI specific practices, tasks and considerations and is meant to be used alongside SP 800-218, not instead of it. If you ship models or AI systems, you will meet both.

The federal attestation requirement became optional per agency

Section 4(e) of Executive Order 14028 (12 May 2021) asked NIST to issue guidance covering secure build environments, trusted source code supply chains, automated vulnerability checks, provenance, SBOMs, vulnerability disclosure and "attesting to conformity with secure software development practices". OMB turned that into an attestation requirement with M-22-18 and M-23-16, and CISA released the common Secure Software Development Attestation Form on 11 March 2024.

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 M-23-16 and tells each agency to build assurance processes that match its own risk determinations. The memo also says agencies "may choose to use" the resources built under M-22-18, including the attestation form, may adopt contract terms requiring a current SBOM on request, and can reference SP 800-218. CISA's form page is now marked as archived content.

For a vendor, the single government wide form is no longer mandatory, but agencies, primes and regulated buyers still ask for it, or for SSDF mapped questionnaires, SBOMs and evidence. The work did not go away; it stopped arriving in one standard envelope.

The SSDF practices at a glance

The table below lists every practice in version 1.1 with NIST's own name. PW.3 no longer exists in 1.1; its tasks moved to PO.1.3 and PW.4.4.

Most of these practices describe decisions, roles, environments and reviews. An SBOM shows what is inside a release. It cannot show that someone reviewed the design, that build environments are separated, or that you ran a root cause analysis last quarter.

Which SSDF tasks a Safeguard scan decides

The Compliance and GRC suite (GA) covers a framework in two ways. Some requirements are checked on every scan of a product, against what the scan found, including the product's SBOM. The rest are controls you evidence with automated tests, uploaded evidence, policies or an attestation. Safeguard's compliance frameworks docs mark each scan requirement as decided by a scan, checked for a prerequisite, or needing evidence.

For NIST SSDF, the framework page lists six scan requirements, all decided by a scan. Here they are next to NIST's task text.

Two things stand out. First, "decided by a scan" means decided against the scan's data. A green SSDF-PS-3-2 says your SBOM exists and names its creator, not that you shared it with an agency or protected it from tampering; the CISA form asks you to attest to those parts too. Second, the requirement labelled SSDF-PW-4-2 does not line up with NIST's PW.4.2 task. Safeguard's own description cites "the PW.4 practice group", so map it to PW.4 in any questionnaire, or a reviewer who knows the framework will flag it.

What the scan needs to see

All six checks read the SBOM. SBOM generation and analysis (GA) produces SPDX and CycloneDX documents from sources connected on the Integrations page (code hosts, container registries, uploaded manifests), and the Generate SBOM docs say connected projects are rescanned daily, with optional triggers on push, on a schedule or on release tags. A local safeguard scan --dir . only writes results under ./output; a scan from the interactive terminal while signed in uploads the SBOM and findings, and your source never leaves the machine.

Which practices still need your evidence

Beyond the six scan requirements, the NIST SSDF framework's Controls tab lists controls from Safeguard's control catalogue. You evidence them with automated tests, uploaded evidence, policies or an attestation. The docs note that no automated tests map to SSDF directly today, so linking any connector based test to an SSDF control is a manual step you take yourself.

Be careful with the catalogue's labels. Several entries pair an SP 800-218 ID with a name that belongs to a different NIST task. For example, the catalogue shows PS.1.1 as a design task, while NIST's PS.1.1 is about storing all forms of code under least privilege; it shows PS.2.1 as review and test, while NIST's PS.2.1 is release integrity information; and RV.2.1 appears as root cause analysis, which is NIST's RV.3.1. The catalogue covers the right territory, but the ID to name pairs are not reliable. When you write an evidence note or answer a questionnaire, use NIST's ID and NIST's wording, as in the table below.

The pattern is consistent. Safeguard produces evidence where it is a property of the software you ship: inventory, identity, versions, known vulnerabilities, attestation data and gate decisions. For everything else it holds your evidence, with approvals and expiry built in. It does not create evidence of practices it cannot observe.

How SBOM generation, attestation and the EO 14028 checks feed the SSDF page

Three ESSCM features produce most of the software side evidence. Each has its own screen, and each answers a different buyer question.

SBOM generation and analysis (GA)

The SBOM is the input for all six scan requirements. Supplier, version, unique identifier, dependency relationships, author and timestamp all come from it. The SBOM generation post in our product series covers formats and minimum elements in depth. For SSDF, the point is narrower: if a component lacks a supplier or exact version in the SBOM, two or three SSDF requirements fail together, because they read the same fields.

Attestation and signing (GA)

The Attestation docs describe an Attestation tab under a project's Explore SBOM view. It shows each component's Safeguard Component Attestation Level (SCAL), from SCAL 0 (fully attested, with reproducible builds, signatures and transparency log entries) to SCAL 5 (origin cannot be verified). Columns include the attestation type (SLSA, Sigstore, in-toto and others), signature status and provenance. Click a component for build platform, source repository, builder identity, signer identity and transparency log entry. LCAL is the package level score.

This is Safeguard's most direct evidence for the provenance part of PS.3.2 and the verification parts of PW.4.1 and PW.4.4, and the "Unattested Only" filter (SCAL 3 to 5) gives an honest gap list for a PW.4 review. Our attestation and provenance post explains how the levels are assigned.

EO 14028 checks

The EO 14028 checks docs describe SBOM completeness checks against the NTIA minimum elements: supplier name, component name, version, other unique identifiers, dependency relationship, SBOM author and timestamp, plus a machine readable SPDX or CycloneDX format. A project's Compliance tab shows the detailed status, and a dashboard widget shows the organization view. To produce a report, open the project and choose Export, then EO 14028 Compliance Report, and pick PDF, HTML or JSON. The report includes an executive summary, SBOM details, per component completeness, a gap analysis and remediation steps. The docs say there is no CLI command for this report yet, and the page's REST examples sit under a banner saying those /v1 endpoints are not available today, so use the in-app export.

The same docs page also carries an "SSDF Alignment" table whose practice names do not match NIST (for example PS.2 shown as a secure development environment, and PW.4 as source code review). Treat that table as approximate and keep to NIST's names.

Step by step: from switching SSDF on to an attestation package

The steps below follow the Safeguard docs. Where the docs do not show a specific screen, the step describes the outcome instead of inventing one.

1. Confirm the framework is on. NIST SSDF sits under Americas, United States, Government in the framework library and is on by default unless someone switched it off. To check, open Compliance › Manage, then the Frameworks tab, search for NIST SSDF, switch it on if needed and select Save. It then appears on Compliance › Frameworks, Controls and Overview. If you build or ship AI models, switch on NIST SP 800-218A as well; it has its own six scan requirements built on the same PS.2.1, PS.3.2, PW.4 and RV.1.1 tasks. Your Safeguard plan decides which frameworks you can choose.

2. Scope the product you will attest. Make sure the Safeguard product contains exactly the repositories, images and uploads that make up the software you sell. Extra internal tools inflate the gap list; a missing service hides gaps.

3. Scan the product. Connect each repository or image on the Integrations page, or scan from the CLI (GA). 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 .
   

   Use the signed in interactive scan or a connected project so results reach the platform. A connected project is also rescanned daily, which keeps the SSDF page from going stale.

4. Read the six scan requirements. Open Compliance › Frameworks, choose NIST SSDF, and go to the Controls tab. The six scan requirements appear as controls with a met or not met result from the latest product scan. The readiness score beside the framework is the share of in-scope requirements that pass. Requirements waiting for evidence count as not passing, and a requirement scoped out with a written justification leaves the score. Safeguard's docs are clear that the score is its assessment of what it can see, "not an audit opinion or a certification".

5. Fix the inventory gaps first. Failures on these six checks almost always trace back to SBOM data. Work them before collecting process evidence, because one fix often clears several requirements. The gaps section below lists the usual causes.

6. Attach evidence to an evidence-only control. Pick a catalogue control, for example the one covering vulnerability disclosure (NIST RV.1.3). On Compliance › Evidence, add the file or link with a note, the control and dates. Per the approvals docs, evidence starts as submitted, and a compliance reviewer chooses Accept or Reject; the decision is stamped with who, when and why. Changing accepted evidence makes a new version that goes back to submitted. Evidence with an end date becomes expiring inside its reminder window and expired after it, which is useful for annual items such as training records.

7. Start the SSDF policies from templates. Open NIST SSDF on Compliance › Frameworks, then its Policies tab, select New policy and choose Start from template. Templates written for SSDF include Organization-Wide Software Security Requirements, Software Integrity and Supply Chain Protection Policy, Secure Software Development Practices Policy, and Vulnerability Response and Disclosure Policy, alongside the standard set adapted to SSDF. Edit them to describe what you actually do, then Submit for review. An approval covers one version; edits create a new version while the approved one stays in force, and the next review defaults to a year after approval.

8. Add process evidence for PO.5 and PS.1 where connectors exist. Automated tests from connected cloud, identity and code host systems record results that start accepted. Link them to the SSDF controls yourself, since none map directly. If a connector is not live, request it on Compliance › Connectors › Request integration and upload evidence meanwhile.

9. Export the software evidence. From the project, export the EO 14028 Compliance Report and the SBOM in SPDX or CycloneDX. Keep the Attestation tab view or component attestation details for the components a reviewer is likely to ask about. Store these with the release, which also gives you PS.3.1 evidence.

10. Assemble the package and get the signature. Combine the exports, the accepted evidence and the approved policies into the package your buyer asked for. If the buyer still uses the CISA form, the CEO or COO of your company signs it, or you attach a third party assessor's report instead. Safeguard does not sign or submit the form.

How this maps to the CISA attestation form

The CISA form has four attestation statements, each mapped to EO 14028 subsections and SSDF tasks "for reference purposes". The form itself says it must be signed by the CEO or COO, who must be an employee of the producer. A producer can submit an assessment by a FedRAMP certified or agency approved Third Party Assessor Organization instead, and a producer that cannot attest to some practices can submit a plan of action and milestones.

Safeguard's evidence is heavy in rows 2 to 4 and thin in row 1, which is about your environments. Statement 1 is where vendors most often find gaps, and where a scanner helps least.

How policy gates turn SSDF expectations into release blocks

SSDF PO.4.1 asks you to define criteria for software security checks and track them through the SDLC. Statement 4 of the CISA form asks for vulnerability checks "at a minimum, prior to product, version, or update releases". A policy gate is the most direct way to show both.

In Safeguard, policies and gates (GA) work in two layers. A policy describes a condition and has an action. A gate groups policies at a checkpoint such as a pull request, a protected branch or a release job. Gate behaviours include block, warn, notify and require approval. Our plain English policies post walks through the full setup; in short, you create the policy, link it to a gate, and call the gate from CI with the CLI's documented step:

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

For SSDF evidence, two kinds of rule are worth gating:

• Known exploited and critical vulnerabilities before release. A rule starting from a template such as No Critical Vulnerabilities, narrowed to CISA KEV listings, gives PO.4 a concrete criterion and RV.2 a recorded decision every time it fires.
• Attestation levels. Policies can reference SCAL levels, so components with unknown origin can warn or block. That makes PW.4.1 a checked rule rather than a paragraph in a policy document.

Start rules in Warn, watch what they match for a few weeks, then move to Block. Each evaluation is recorded, and a gate history with timestamps is better evidence for PO.4.2 than any written statement that "we check before release".

Common gaps the scan exposes, and how to close them

When the SSDF scan requirements fail, the cause is nearly always one of these. The fixes come from Safeguard's EO 14028 docs and from basic SBOM hygiene.

Fix lockfiles and versions first. One missing lockfile can fail RV.1.1 and the PW.4 records check at once, and it blinds vulnerability matching too.

A decision table: which artifact answers which question

Using Claude with the SSDF evidence

Safeguard's MCP server (GA) is listed in Claude's connector directory as a community connector: open the entry, connect, sign in to Safeguard and authorize access (see our connector directory post). The tools the companion guidance names, such as list projects and list vulnerabilities, are read only; which tools appear depends on your plan and administrator settings. For SSDF, that is useful for drafting RV.1 and RV.2 answers from live data. Check the last scan date before quoting numbers, and remember the approvals rule: an assistant can draft and submit, never accept or approve.

What Safeguard does not do

• It does not sign or file the attestation. The CISA form requires the CEO or COO of the software producer, or a third party assessor's report. Safeguard prepares evidence; your officer attests, and the legal weight of that signature sits with your company.
• It does not see your development environments through a product scan. PO.5 separation, MFA and conditional access, logging of trust relationships and endpoint hardening are outside what an SBOM shows. Connector tests can help where a connector is live (roughly 50 today, more on request), but none map to SSDF automatically, and you link them yourself.
• It does not perform your code review, design review or root cause analysis. PW.2, PW.7, PW.8 and RV.3 are activities your people run. SAST and DAST are early access in Safeguard, so if you use them as PW.7 or PW.8 evidence, confirm coverage for your languages and targets first.
• It does not see what it does not scan. Repositories outside the product, binaries vendored without manifests, and build steps that inject components after the scan are invisible to the six checks. A green page covers the scanned scope only.
• Its readiness score is not an audit opinion. The score is the share of in-scope requirements that pass on Safeguard's view of your data. A third party assessor, an agency or your buyer makes the judgment.
• Its catalogue labels for SSDF are not NIST's text. Several catalogue controls pair an SP 800-218 ID with the wrong task name, and the EO 14028 docs' SSDF alignment table does the same. Use NIST's wording in anything external.
• It does not run your vulnerability disclosure program. RV.1.3 asks for a policy, roles and a process. Safeguard gives you a policy template and a place to hold evidence; receiving and answering reports is yours.
• It does not interpret federal policy for your contract. With M-22-18 rescinded, each agency sets its own requirements. Read your contract and the agency's instructions; do not assume the old common form deadlines still apply.

Common mistakes

• Quoting the catalogue's ID and name pairs in a questionnaire. A reviewer who reads "PS.2.1, Review and test software" will doubt the rest of your answers. Take IDs and names from SP 800-218.
• Treating six green checks as SSDF conformance. The scan decides six inventory properties. The CISA form cites far more tasks than that, most of them about process.
• Citing version 1.2 practices as final. PO.6 and PS.4 are in a draft. Mention them as planned direction, and attest against version 1.1 unless your buyer says otherwise.
• Assuming the attestation requirement vanished. M-26-05 removed the government wide mandate, not agency discretion. Expect agencies and primes to keep asking, sometimes with their own forms.
• Fixing the report, not the build. Hand editing an SBOM to add suppliers or versions makes the next scan fail again and breaks PS.3.2 creator data. Fix lockfiles and generation instead.
• Leaving policies as unedited templates. A template describes a generic company. An approved policy that does not match your actual practice is worse evidence than none, because an assessor will test it.
• Gating in Block on day one. A noisy Block gate gets bypassed, and the bypasses become your PO.4 evidence. Start in Warn.

FAQ

Does Safeguard support NIST SSDF?

Yes. NIST SSDF is one of the frameworks in the Compliance and GRC suite (GA). Six requirements are decided by each product scan, and the rest of the framework is covered by catalogue controls you evidence with uploads, policies, automated tests or attestations.

Which SSDF practices can be checked automatically?

In Safeguard, six requirements are decided by a scan. They relate to NIST tasks PS.3.2 (provenance and SBOM), PS.2.1 (integrity verification information), PW.4.1 and PW.4.4 (component sourcing and verification), RV.1.1 (vulnerability information) and the PW.4 practice's component records. Each checks properties of the SBOM, not your whole process.

Is SSDF version 1.2 final?

Not as of October 2026. NIST released SP 800-218 Rev. 1, describing SSDF version 1.2, as an initial public draft on 17 December 2025, and comments closed on 30 January 2026. It adds practices PO.6 and PS.4. Version 1.1 remains the final publication.

Is the CISA secure software attestation form still required?

The government wide requirement ended when OMB M-26-05 rescinded M-22-18 and M-23-16 on 23 January 2026. Agencies may still choose to use the form and may require an SBOM on request, so check each contract.

Who signs the secure software development attestation?

The form says the CEO or COO of the software producer signs, and the signatory must be an employee. Alternatively, the producer attaches an assessment by a qualifying Third Party Assessor Organization. Safeguard does not sign it.

Can Safeguard generate the SBOM an agency asks for?

Yes. SBOM generation and analysis (GA) produces SPDX and CycloneDX documents for connected repositories, images and uploads. The EO 14028 Compliance Report, exported from the project, checks the SBOM against the NTIA minimum elements.

Does a Safeguard readiness score mean we conform to SSDF?

No. The readiness score is the share of in-scope requirements that pass on what Safeguard can see. Its docs say it is not an audit opinion or a certification. Requirements waiting for evidence count as not passing.

How does Safeguard handle SP 800-218A for AI models?

NIST SP 800-218A is a separate framework in the suite, with its own scan requirements built on the same SSDF tasks (PS.2.1, PS.3.2, PW.4 and RV.1.1) plus AI specific catalogue controls and policy templates. Switch it on next to NIST SSDF if you develop or ship models.

Can an AI assistant approve SSDF evidence in Safeguard?

No. Per Safeguard's approvals docs, a change made through Safeguard's assistant or an MCP client can draft and submit, but never accept, approve, launch or acknowledge. A compliance reviewer decides.

From SSDF findings to fixes

SSDF's Respond to Vulnerabilities group asks you to plan and carry out a response for every vulnerability you find, and RV.2.2 is the task most teams struggle to evidence quickly. The options below are how Safeguard helps you act on those findings (autonomous remediation, Gold Open Source and Gold Registry are GA; fork and patch is early access), and each leaves a record you can attach as RV.2 evidence.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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 CLI session. It shows installing the CLI, opening the interactive terminal with safeguard, asking it to fix a lodash CVE, approving each command as it edits package.json, runs npm install and npm test, and prints a summary without pushing anything, then /permissions, /model and /scan .. For SSDF, the same /scan . from a signed in session is what feeds the six scan requirements, and the approved fix is RV.2 evidence.

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

The second demo sets up the local runner (GA) on your own machine, approves it with its device code, then scans from the terminal. Teams that cannot send source to a hosted scanner use this route to produce the SBOM the SSDF checks read, while code stays in their environment.

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

The third demo connects Claude to Safeguard with OAuth and shows choosing which tools Claude can use. In your own workspace, add Safeguard from Claude's connector directory rather than configuring a server by hand; once connected, Claude can read your vulnerability data to draft RV.1 and RV.2 answers that a person then reviews.

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

To try this on your own product, install a Safeguard client from safeguard.sh/download and follow the setup guides at docs.safeguard.sh/docs.

For more depth on SSDF itself, read our practical guide to the NIST SSDF, the PW.4 explainer and our walkthrough of the CISA secure software development attestation form. For how the suite handles evidence across frameworks, see continuous compliance in Safeguard, and for sharing SBOMs with customers, publish versus share in Portal.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework Version 1.1 (PDF)
• NIST SP 800-218 Rev. 1 initial public draft, SSDF Version 1.2 (CSRC)
• NIST SP 800-218r1 ipd (PDF)
• NIST SP 800-218A, SSDF Community Profile for generative AI and dual-use foundation models
• NIST CSRC, Executive Order 14306
• Executive Order 14028, Improving the Nation's Cybersecurity (Federal Register PDF)
• OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security (PDF)
• CISA, Secure Software Development Attestation Form page
• CISA, Secure Software Development Attestation Form (PDF)
• Safeguard docs, NIST SSDF framework
• Safeguard docs, NIST SP 800-218A framework
• Safeguard docs, Compliance frameworks
• Safeguard docs, Approvals
• Safeguard docs, EO 14028 compliance checks
• Safeguard docs, Attestation
• Safeguard docs, Generate SBOM

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