NIST CSF 2.0 in Safeguard: Govern, Supply Chain and Automated Tests

Safeguard's Compliance and GRC suite (GA) carries NIST CSF 2.0 as a framework you can switch on: every product scan checks a set of software inventory and supply chain outcomes such as ID.AM-02, GV.SC-04, GV.SC-07 and ID.RA-01, automated tests from connected systems evidence many Protect, Detect and Respond outcomes, and you evidence the rest with policies, uploads and attestations. What Safeguard does not do is write your Organizational Profiles or assign your Tier. Those stay your judgement, and this post shows where the line sits.

Key takeaways

• NIST CSF 2.0 (CSWP 29, 26 February 2024) added the Govern function, moved supply chain risk into Govern as GV.SC with ten subcategories, and made Current and Target Organizational Profiles the main way to use the framework. Tiers are optional context, not a score.
• Compliance and GRC suite (GA): NIST CSF 2.0 is in the framework library. A product scan decides a small set of CSF requirements against the SBOM and scan results; the framework's Controls tab adds catalogue controls you evidence yourself.
• Automated compliance tests (GA, part of the suite): tests that read connected systems map directly to CSF 2.0 subcategories, mostly in PR.AA, PR.DS, PR.PS, PR.IR, DE.CM, ID.RA and RS.MA. A passing test is evidence toward a control, not proof on its own. Safeguard's offering says roughly 50 evidence connectors are live today, more on request.
• Policy templates (GA, part of the suite): CSF 2.0 has its own governance, risk assessment and recovery policy templates plus the standard set. A person approves every policy.
• TPRM (GA): vendor tiers, SBOM requests, a vendor risk score and continuous monitoring give you working records for GV.SC-04, GV.SC-06 and GV.SC-07. Incident coordination with suppliers (GV.SC-08) and post-contract provisions (GV.SC-10) stay with you.
• SBOM generation and analysis (GA) is what the scan checks read. Missing supplier names, versions or hashes in your SBOM show up as failing CSF requirements.
• Not computed by Safeguard: CSF Tiers, a maturity score, a Current or Target Profile, or any statement that you "comply with" CSF. NIST runs no certification for the CSF, and a readiness score is Safeguard's view of what it can see.

What changed from CSF 1.1 to CSF 2.0

NIST released CSF 2.0 as Cybersecurity White Paper 29 on 26 February 2024. NIST's announcement calls it the framework's first major update since the original 2014 release. Four changes matter for anyone building a programme on it.

The Govern function

CSF 1.1 had five functions: Identify, Protect, Detect, Respond and Recover. CSF 2.0 adds a sixth, GOVERN (GV), which NIST defines as the organization's cybersecurity risk management strategy, expectations and policy being established, communicated and monitored. Govern has six categories:

Supply chain moved up into Govern

In CSF 1.1, supply chain risk management was one category inside Identify. In CSF 2.0 it is GV.SC, with ten subcategories, GV.SC-01 to GV.SC-10. They run the full supplier life cycle: a programme and strategy (GV.SC-01), roles for suppliers and partners (GV.SC-02), integration with enterprise risk management (GV.SC-03), knowing and prioritising suppliers by criticality (GV.SC-04), requirements in contracts (GV.SC-05), due diligence before a relationship starts (GV.SC-06), understanding and monitoring supplier and product risk over the relationship (GV.SC-07), including suppliers in incident planning, response and recovery (GV.SC-08), monitoring supply chain practices across the product life cycle (GV.SC-09), and provisions for what happens after a contract ends (GV.SC-10).

Organizational Profiles

CSWP 29 section 3.1 defines an Organizational Profile as a description of an organization's current and target posture in terms of the Core's outcomes. A Current Profile records which outcomes you achieve now and how far. A Target Profile records the outcomes you have chosen and prioritised to reach. A Community Profile is a published baseline for a sector or use case that you can adopt as the starting point for your Target Profile. NIST's five steps are: scope the profile, gather information, create it, analyse gaps and build an action plan (a risk register or a Plan of Action and Milestones are both given as examples), then implement and update.

NIST SP 1301, the profiles quick start guide, adds a template spreadsheet: one row per outcome, with Practices, Status and Rating for the Current Profile and Goals and Priority for the Target Profile. You choose the rating scale.

Tiers are optional and describe rigour

Section 3.2 describes four Tiers: Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3) and Adaptive (Tier 4). NIST says an organization can choose to use Tiers to inform its profiles. They characterise how rigorous your governance and management practices are. Appendix B makes the supply chain point directly: at Tier 1, the organization is generally unaware of the cybersecurity risks tied to its suppliers and the products it buys.

Scope and the online resources

NIST's announcement says CSF 2.0 is written for all organizations, not only critical infrastructure. Online Informative References, Implementation Examples, Quick Start Guides and the CSF 2.0 Reference Tool support the Core and are updated more often than the document.

For a plain-language tour of all six functions, see NIST CSF 2.0 core functions explained. For an engineering leader's view of why Govern comes first, see NIST CSF 2.0 for VPs of Engineering.

The problem: a profile with nothing under it

Most CSF programmes start as a spreadsheet filled in from interviews. That is a valid start, and it is what NIST describes. The trouble begins in month three.

• Ratings drift from reality. A row that says "ID.AM-02: software inventory maintained, rating 4" is a claim. If the inventory is a quarterly export that nobody reconciles with what is actually deployed, the claim was true for a week.
• Supply chain outcomes are the hardest to evidence. GV.SC-04 and GV.SC-07 ask you to know your suppliers and understand the risk their products carry. For software, the suppliers include every open source maintainer behind every transitive dependency. Few teams can name them.
• The board wants one number. It is tempting to average the ratings and call it a maturity score or a Tier. CSF does not define either, and an averaged number hides which outcomes are failing.

NIST SP 1305, the supply chain quick start guide, is blunt about what suppliers should provide. Its checklist suggests contracts require suppliers to keep a current component inventory, such as a software or hardware bill of materials, for critical products. If you ask that of suppliers, you need the same discipline for the software you ship yourself.

How Safeguard covers NIST CSF 2.0

Safeguard's Compliance and GRC suite (GA) has these areas in the app: Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center and Connectors. Trust Center is early access; everything else named here is part of the GA suite. Lion, Safeguard's compliance model (GA), does evidence mapping and writes audit-grade narrative.

The framework library page for NIST CSF 2.0 lists it as "NIST CSF 2.0 (Full)", region Americas, scope United States. The docs say it is on in your workspace unless you switch it off under Compliance › Manage. Your Safeguard plan decides which frameworks are available to choose from.

Safeguard's frameworks docs describe four kinds of coverage, and all four apply to CSF 2.0:

1. Scan requirements. A set of CSF requirements that every scan of a product checks against what the scan found, including the product's SBOM. For CSF 2.0 these are all decided by a scan.
2. Catalogue controls. Extra CSF controls from Safeguard's control catalogue appear on the framework's Controls tab. You evidence them with automated tests, uploaded evidence, policies or an attestation.
3. Automated tests. Tests from connected systems map directly to CSF 2.0 subcategories. CSF 2.0 is one of the few frameworks in the library with direct test mappings, alongside SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and the CIS benchmarks. Through the crosswalk, evidence can also reach equivalent controls in related frameworks such as NIST SP 800-53.
4. Policy templates. Templates written for CSF 2.0, plus the standard template set adapted to it.

Which CSF 2.0 subcategories does a Safeguard scan check?

Each scan of a product checks the CSF 2.0 scan requirements against the scan results and the SBOM. The table uses NIST's subcategory text from CSWP 29 and the check as Safeguard's CSF 2.0 docs page describes it.

Two notes on that last row. First, PR.DS-INT is Safeguard's own requirement label, not a NIST identifier. CSF 2.0 states integrity inside broader outcomes: PR.DS-01 and PR.DS-02 cover the confidentiality, integrity and availability of data at rest and in transit, and ID.RA-09 says the authenticity and integrity of hardware and software are assessed before acquisition and use. Map the hash check to whichever of those your profile uses, and say which in your evidence note. Second, hashes in an SBOM support integrity checking; they do not prove that a build was not tampered with. For that, attestation and signing (GA) in Safeguard records SLSA provenance and Sigstore signatures, which the attestation and provenance post covers.

How a scan decides these requirements

The scan checks are facts about your software inventory. They come from SBOM generation and analysis (GA) and from SCA with deep transitive dependency scanning (GA). In practice:

• A component with no supplier field fails the GV.SC-04 check for that product. Open source packages often have a supplier or originator only when the ecosystem metadata provides one.
• A component with no version fails the ID.RA-01 check, because you cannot match an unversioned component to vulnerability data.
• A component with no package identifier fails GV.SC-07, because the risk cannot be looked up.
• A component with no hash fails the integrity check.

So the CSF readiness number can drop after a scan even when no control changed: a new release pulled in a vendored library with no version string, and the scan reported what it saw. The SBOM generation and analysis post explains how the same fields line up with the NTIA minimum elements.

What the scan checks do not decide

A passing scan check means the SBOM has the data the outcome presupposes. It does not mean the outcome is achieved. GV.SC-04 asks you to prioritise suppliers by criticality; a supplier name in an SBOM is a prerequisite for that, not the prioritisation itself. ID.RA-01 asks that vulnerabilities are identified, validated and recorded; versioned components make identification possible, and the vulnerability management side of Safeguard (GA) does the identifying, with EPSS and CISA KEV enrichment. Validation and recording of decisions, such as accepting or fixing, is still your process.

Which CSF 2.0 controls do you evidence yourself?

The framework's Controls tab lists the scan requirements plus extra controls from Safeguard's control catalogue for CSF 2.0. The docs say to evidence them with automated tests, uploaded evidence, policies or an attestation. The catalogue covers outcomes across all six functions. The ones a programme manager usually asks about first, with NIST's text:

A note on identifiers and wording

Use NIST's identifiers and text, from CSWP 29 or the CSF 2.0 Reference Tool, when you record evidence and when you talk to an auditor. Two practical reasons:

• Some identifiers changed between versions. CSF 2.0 does not reuse every CSF 1.1 identifier, so its numbering has gaps. For example, Incident Response Reporting and Communication (RS.CO) in CSF 2.0 has only RS.CO-02 (stakeholders are notified of incidents) and RS.CO-03 (information is shared with designated stakeholders). There is no RS.CO-01 in CSF 2.0. Older mappings and some tool catalogues still carry 1.1 identifiers.
• Short control names are paraphrases. A catalogue's one-line control name is a convenience. When it reads differently from NIST's sentence, NIST's sentence is what an assessor will read. Check each catalogue control's ID and wording against CSWP 29 before you attach evidence to it, and note the NIST text in the evidence description.

How do automated tests from connected systems map to CSF 2.0?

Automated tests are where most of the Protect, Detect and Respond evidence comes from. Safeguard's CSF 2.0 connectors page lists, for each CSF subcategory, how many tests map to it and which connectors answer them.

What the tests are

• Tests that read a connected system. Most tests read a cloud account, identity provider, code host, ticketing system, endpoint manager or monitoring tool through its connector.
• Tests that read Safeguard's own records. Some tests read records already in Safeguard, such as approved policies, so they need no connector.
• Attestation for systems without an API. For some systems there is no API for what a test checks. The docs say to connect them to record the connection, then attest the result; an accepted attestation counts toward the control.

The key rule from the docs: a passing result is evidence toward a control, not proof that the control is met on its own. An access control outcome such as PR.AA-05 is a policy, a process and many settings. One passing test covers one setting.

Which subcategories get test coverage

The CSF 2.0 connectors page lists the subcategories that tests map to. Grouped by the kind of system you connect, the pattern looks like this:

Coverage varies by connector inside each row. The framework's Connectors tab shows exactly which connectors answer CSF 2.0 tests, which you have connected, and whether each connection is healthy.

On the CSF 2.0 connectors page, no automated test maps to any Recover (RC) subcategory. In GV.SC, tests map only to GV.SC-04, GV.SC-05 and GV.SC-07. Govern outcomes such as GV.OC-01, GV.RM-01 and GV.RR-01 have no automated test at all, because no API can show that leadership is accountable. Those are the outcomes CSF expects people to own.

Rules that change how you read test results

From the CSF 2.0 connectors page and the approvals docs:

• Tests run on a schedule, or now. Use Run now on Compliance › Tests to run one straight away.
• New tests start in a preview period. A passing test counts toward its controls only once its preview period has ended.
• Tests are switched on per workspace by the Safeguard team. If the Tests area is empty after you connect a system, ask for tests to be enabled rather than assuming the connector failed.
• Test results from their own runs start accepted. Evidence a test records from its own run is accepted on that basis; uploaded evidence waits for a reviewer.
• Exclusions need an approver. On a test's detail page, Exclude asks to exclude one resource, such as a break-glass account, with a Reason, an Approver and an Expires on date. Nothing is excluded until the approver approves it.

Which connectors are live

The CSF 2.0 docs page lists many connectors, but Safeguard's offering says roughly 50 evidence connectors are live today, the rest on request. Before you plan CSF evidence around a connector, check the Connectors tab in your workspace. If a connector you need is missing, ask for it from Compliance › Connectors with Request integration. The continuous compliance post explains connector requests and the crosswalk in more depth.

Step by step: set up CSF 2.0 in Safeguard

This walkthrough follows the docs for frameworks, connectors, policies and approvals. Where the docs do not show a screen, the step describes the outcome instead.

1. Confirm NIST CSF 2.0 is switched on. Open Compliance › Manage, then the Frameworks tab. Search for NIST CSF 2.0. The docs say it is on by default unless someone switched it off; if it is off, switch it on and select Save. It then appears on Compliance › Frameworks, Controls and Overview. If you cannot find it, your plan may not include it; your Safeguard administrator manages that list.

2. Scan the products in scope. The scan requirements are decided per product, from each scan's SBOM and results. Bring the repositories, container images and SBOM files that make up the scope of your profile into Safeguard. From the CLI, the scans look like this:

   safeguard scan --dir .
   safeguard scan --image <name>
   safeguard scan --sbom <file>
   

   Group projects into Products that match how you scope the profile, for example one product per business service. A CSF profile scoped to "the payments platform" should map to a product of that name, not to the whole tenant.

3. Connect the systems that produce evidence. Open NIST CSF 2.0 on Compliance › Frameworks and go to its Connectors tab. It lists the connectors that answer this framework's tests, which you have connected, and whether each is healthy. Connect your identity provider, cloud accounts and code host first; together they feed the largest share of PR.AA, PR.DS, PR.PS and DE.CM tests.

4. Run the tests and wait out the preview period. On Compliance › Tests, use Run now to see first results. Read failures before you fix anything: a failing test on a test or sandbox account may deserve an exclusion with a reason, an approver and an expiry date, rather than a configuration change.

5. Read the Controls tab in two parts. The scan requirements show met or not met per product. The catalogue controls show which have passing tests, accepted evidence or nothing yet. Beside the readiness score, Safeguard shows how many requirements a scan evaluated and how many need evidence or an attestation. A requirement waiting for evidence counts as not passing. A requirement someone scopes out with a written justification leaves the score, so read every justification.

6. Start the governance policy from the CSF template. On the framework's Policies tab, select New policy and choose Start from template. Three templates are written for CSF 2.0:

   • Organizational Cybersecurity Strategy and Governance Policy
   • Cybersecurity Risk Assessment Policy
   • Cybersecurity Recovery and Resilience Planning Policy

   Start with the governance policy. Edit it to state your mission, risk appetite and who is accountable, then choose Submit for review. A compliance reviewer approves it. On approval, the effective date defaults to the approval day and the next review to a year later. Editing an approved policy creates a new version for review while the approved one stays in force. An approved policy is evidence for GV.PO-01 and supports GV.OC-01, GV.RM-01 and GV.RR-02.

7. Upload evidence for the outcomes no test can see. On Compliance › Evidence, attach board minutes, the supplier RACI, recovery exercise reports and similar records to their controls. Evidence starts as submitted, and a reviewer chooses Accept or Reject. Give evidence an end date where it expires, such as an annual exercise; accepted evidence then shows as expiring inside its reminder window and expired after that date.

8. Record your Current Profile view. Safeguard does not produce a CSF Organizational Profile document. Use NIST's profile template from SP 1301 and fill the Current Profile columns from what Safeguard shows: for each outcome, put the controls and evidence references in Practices, the Safeguard status (scan met, test passing, evidence accepted, or no evidence) in Status, and your own judgement in Rating. Date the export. That turns the spreadsheet from opinion into a record you can check.

9. Write the Target Profile and record gaps as risks. The Target Profile is a business decision: which outcomes you will reach, by when, and why. For each gap between Current and Target, add an entry on Compliance › Risks with an owner. The docs set clear acceptance rules: the risk owner can accept a low or medium residual risk with a reason; a high or critical one needs an approver with an admin role and a review date within a year, and shows Needs re-approval if the residual risk later rises. NIST's own profile steps name a risk register as one form of action plan.

10. Repeat on a cadence. Rescans, scheduled tests and evidence expiry keep the status moving. Re-export the Current Profile view monthly or quarterly and keep the old ones; the trend is what a board and an assessor want.

A note on assistants. Safeguard's approvals docs say its AI assistant and MCP clients such as Claude or ChatGPT can read your programme and prepare changes, but never accept, approve, launch or acknowledge anything. Writes wait for you to confirm them in the client, and decisions stay with a person in the app. That is the right split for CSF evidence.

How does TPRM support GV.SC-06 to GV.SC-10?

TPRM, Safeguard's Third-Party Risk Manager (GA), is the product for supplier software risk. Safeguard's offering describes four modules:

• Vendor Management: a vendor directory, contracts and SLAs, risk tiers, and a self-service vendor portal.
• SBOM Requests: single and bulk requests with templates and status tracking from Sent through Viewed, In Progress and Submitted to Validated or Rejected, with automated follow-ups.
• Risk Assessment: a vendor risk score from 0 to 100 across vulnerability, compliance, component and operational risk, using EPSS and CISA KEV. Higher is better on this score, which runs the opposite way to component risk scores elsewhere in Safeguard.
• Monitoring: continuous alerts for a new critical vulnerability, a KEV addition, a risk change or an SBOM expiry.

The TPRM docs suggest four risk tiers with an SBOM expectation for each: Critical (core business operations, SBOM required with quarterly updates), High (significant data access, SBOM required with annual updates), Medium (limited system access, SBOM recommended) and Low (minimal risk, SBOM optional). The getting started order is: add vendors, categorise by risk tier, request SBOMs from high-risk vendors, review and validate submissions, then enable continuous monitoring.

Here is how that maps to each GV.SC outcome, honestly:

The Vendors area of the compliance suite holds the same vendor register for compliance purposes. The supplier software risk post walks through vendor onboarding and SBOM requests step by step, so this post does not repeat it.

How do you report CSF progress to a board?

CSF section 5.1 describes the framework as a way to improve communication between executives, managers and practitioners. That is the job a board report does. Safeguard gives you inputs for it; it does not give you a CSF grade.

What Safeguard computes is a readiness score for each framework: the share of in-scope requirements that pass. The docs say plainly that it is Safeguard's assessment of what it can see, not an audit opinion or a certification. It does not compute a CSF Tier, a maturity level or a profile rating.

A board report that holds up has four parts:

1. One line per function, not one number. For Govern, Identify, Protect, Detect, Respond and Recover, show the outcomes in your Target Profile, how many have evidence today, and the trend since last quarter.
2. Separate machine evidence from human evidence. "Protect: identity outcomes tested continuously across connected systems, passing" is a different kind of statement from "Recover: plan approved, last exercise in March". Keep them visibly different.
3. Show gaps with owners and dates. Pull these from the risk register, including any accepted risks and their review dates.
4. State your Tier as your judgement. If you use Tiers, say who assessed it and against which part of Appendix B. Do not derive it from the readiness score.

The compliance reporting guide covers the dashboards and exports you can use for the numbers.

Which CSF outcomes sit outside the platform?

Some CSF 2.0 outcomes describe people, decisions and events that no scan or API sees. Evidence these yourself, with uploads and attestations.

• Leadership and resourcing. GV.RR-01 (leadership is responsible and accountable) and GV.RR-03 (adequate resources are allocated) are decisions by people. Board minutes and budgets are the evidence.
• Risk appetite. GV.RM-02 (risk appetite and tolerance statements) is written and owned by leadership. A policy template can hold it, but cannot choose it.
• Incident communications. RS.CO-02 and RS.CO-03, and RC.CO-03 and RC.CO-04 (recovery progress and public updates), are human communications under time pressure. A test can show that an alerting route exists; it cannot show that the right people were told.
• Recovery execution. The whole Recover function (RC.RP-01 to RC.RP-06) is about executing and closing out recovery. Evidence is exercise reports and post-incident records.
• Workforce awareness. PR.AT-01 and PR.AT-02 depend on how you train people. Records can support them; the training is yours to run.
• Physical environment. DE.CM-02 (the physical environment is monitored) is outside a software supply chain platform.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not compute a CSF Tier or maturity score. The readiness score is the share of in-scope requirements that pass. Tiers describe the rigour of your governance and management, which is a judgement NIST leaves to you.
• It does not build your Organizational Profile. There is no Current or Target Profile object in the docs. You export status and evidence and write the profile in NIST's template or your own format.
• It does not certify or attest CSF alignment. NIST does not run a certification programme for the CSF. A readiness score is not an audit opinion, and choosing a framework in Safeguard does not certify anything.
• Scan checks are software-inventory facts. They tell you the SBOM has supplier names, versions, identifiers and hashes. They do not tell you that GV.SC-04 or ID.RA-01 is achieved as an organizational outcome.
• Connector coverage is partial. Roughly 50 evidence connectors are live today, the rest on request, and tests are switched on per workspace by the Safeguard team. Systems you have not connected or scanned are invisible to the score.
• Recover, incident communications and supplier offboarding have no automated tests. Expect to evidence RC, RS.CO, GV.SC-08 and GV.SC-10 with documents and attestations.
• Assistants cannot approve. Neither Safeguard's assistant nor an MCP client can accept evidence, approve a policy or accept a risk.

Common mistakes

• Reporting the readiness score as "CSF compliance". There is no such thing as CSF compliance in NIST's terms. Report outcomes, evidence and gaps.
• Treating a passing scan requirement as an achieved outcome. A supplier field in every SBOM row does not mean you prioritised suppliers. Pair the scan check with the TPRM tiers and your criteria.
• Scoping out requirements without a strong justification. A scoped-out requirement leaves the score and lifts the number. If the justification would not convince an assessor, leave it in.
• Using CSF 1.1 identifiers. RS.CO-01, ID.AM-06 and similar 1.1 identifiers do not exist in CSF 2.0. Map evidence to the 2.0 Core.
• Ignoring the preview period. New tests do not count toward controls until their preview ends. A sudden jump in passing tests a few weeks after setup is often this, not a real change.
• Writing the Target Profile from the tool. Targets come from mission, risk appetite and stakeholder needs (GV.OC, GV.RM). The tool shows where you are, not where you should go.
• Forgetting suppliers are in scope at Tier 1. CSF Appendix B treats supplier risk awareness as part of every Tier. A programme that skips GV.SC rates lower however good its Protect evidence is.

FAQ

Does Safeguard support NIST CSF 2.0?

Yes. NIST CSF 2.0 is in the framework library of Safeguard's Compliance and GRC suite (GA). It has scan requirements decided on every product scan, catalogue controls you evidence, automated tests from connected systems mapped directly to its subcategories, and CSF-specific policy templates.

Can Safeguard make us NIST CSF 2.0 compliant or certified?

No. NIST does not certify organizations against the CSF, and Safeguard does not either. Safeguard helps you collect and keep evidence for CSF outcomes and shows a readiness score. How you describe your alignment is your decision, and any independent assessment comes from a third party.

Which CSF 2.0 subcategories does a Safeguard scan check?

ID.AM-02 (software inventory), GV.SC-04 (suppliers known), GV.SC-07 (supplier and product risk, including an SBOM in a standard format), ID.RA-01 (vulnerability identification) and a software integrity check that Safeguard labels PR.DS-INT. The checks read the scan's SBOM for inventory, supplier names, identifiers, versions and hashes.

Does Safeguard calculate CSF Tiers?

No. Safeguard computes a readiness score per framework, which is the share of in-scope requirements that pass. CSF Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe the rigour of your practices and are your assessment.

How do automated tests map to NIST CSF 2.0?

Tests that read connected systems, such as cloud accounts, identity providers and code hosts, map directly to CSF 2.0 subcategories, mostly in PR.AA, PR.DS, PR.PS, PR.IR, DE.CM, ID.RA and RS.MA. A passing test is evidence toward a control, not proof on its own, and new tests count only after a preview period.

Is there a NIST CSF 2.0 policy template in Safeguard?

Yes. Three templates are written for CSF 2.0: an Organizational Cybersecurity Strategy and Governance Policy, a Cybersecurity Risk Assessment Policy, and a Cybersecurity Recovery and Resilience Planning Policy. The standard template set, adapted to CSF 2.0, is also available from the framework's Policies tab.

How does Safeguard help with GV.SC supply chain risk management?

Scan checks cover supplier data and SBOMs for your own software (GV.SC-04, GV.SC-07). TPRM (GA) adds vendor tiers, SBOM requests, a vendor risk score and continuous monitoring for supplier software (GV.SC-04, GV.SC-06, GV.SC-07). Incident planning with suppliers and post-contract provisions stay with you.

Can Claude or ChatGPT update our CSF evidence through Safeguard?

An assistant connected to Safeguard can read your programme and prepare changes that you confirm in the client. Per Safeguard's approvals docs, it can never accept evidence, approve a policy, launch a campaign or acknowledge anything. A person makes those decisions in the app.

From a failing CSF requirement to a fix

ID.RA-01 and GV.SC-07 are easier to evidence when the vulnerabilities your scans find actually get fixed, and PR.PS-02 asks that software is maintained, replaced and removed commensurate with risk. The block below is the remediation side of that story, and it applies to the open source dependencies and images inside the products your CSF profile covers.

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 connects Claude to Safeguard with OAuth and shows how you choose which tools Claude can use. In Claude, add Safeguard from the connector directory rather than setting up a custom server. For a CSF programme manager, the same connection lets an assistant read Safeguard data while you draft a profile update or a board note; it can prepare text, but approvals stay with a person in the app.

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

The second demo is a real session in the Safeguard desktop app (early access, beta). The CLI session shows in the desktop app's conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. When an ID.RA-01 vulnerability on a CSF in-scope product needs a dependency upgrade, this is the approve each step flow that gets the fix in, after which a rescan updates the scan requirement.

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

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

Quick check

Sources

• NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 (PDF)
• NIST CSRC, CSWP 29 publication page
• NIST news release, NIST Releases Version 2.0 of Landmark Cybersecurity Framework
• NIST SP 1301, Quick-Start Guide for Creating and Using Organizational Profiles (PDF)
• NIST SP 1305, Quick-Start Guide for Cybersecurity Supply Chain Risk Management (PDF)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• NIST Cybersecurity Framework home
• NIST CSF Informative References
• NIST CSF Quick Start Guides
• NIST CSF 2.0 Reference Tool
• Safeguard docs, NIST CSF 2.0 (Full)
• Safeguard docs, NIST CSF 2.0 and connectors
• Safeguard docs, Compliance frameworks
• Safeguard docs, Approvals
• Safeguard docs, Third Party Risk Manager
• Safeguard docs, Compliance

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