Automated Compliance Tests in Safeguard: What They Check, How to Exclude

Safeguard's automated compliance tests, part of the Compliance and GRC suite (GA), read a setting in a system you have connected, such as a cloud account, identity provider or code host, on a schedule, and record the result as evidence toward every control the test maps to. Tests map directly to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and the CIS benchmarks, and reach related frameworks through the crosswalk. When one resource legitimately fails, such as a break-glass account, you request an exclusion with a reason, a named approver and an expiry date, and nothing is excluded until that person approves it.

Key takeaways

• Compliance and GRC suite (GA). The Tests and Monitoring areas run automated tests against connected systems. A passing test is evidence toward a control, not proof on its own that the control is met.
• Evidence connectors (GA, part of the suite). Connect by OAuth or API token for tests. A connection through a vendor's MCP server serves Griffin AI Search (in-app agentic search, GA), not tests. Only part of the connector catalogue is live today; the rest are built on request.
• Tests carry the mapping. A connector feeds tests, each test checks one thing, and each maps to controls in every framework it applies to.
• New tests start in preview, typically 14 days, when results show but change no control, score or task.
• A test's own result starts accepted. Uploaded evidence waits for a reviewer.
• Exclusions are requests, not mute buttons. Reason, Approver, Expires on, and five states: Pending approval, Approved, Rejected, Revoked, Expired.
• Tests and scan requirements are two evidence sources that meet on the same Controls tab.
• Assistants read and draft, never approve. Safeguard's MCP server (GA), added from Claude's connector directory, cannot approve an exclusion or accept evidence.

The problem: screenshot evidence is stale the day you take it

Most programmes still prove technical controls with screenshots. Someone opens an admin console, captures a setting and files it under the control. The picture shows that MFA was enforced for the users on one page, at one moment, in one account.

That fails in three ways. It goes stale. A new administrator is added the next morning without MFA, and the screenshot still says the control works; a SOC 2 Type 2 auditor wants the control to have operated across the period. It samples badly. Page one of the user list is not page three, and the second cloud account the platform team opened for a new region is not in the picture at all. It hides exceptions. The emergency access account outside single sign-on is cropped out or explained in an email nobody can find at audit time, with no record of who accepted it, why or until when.

The fix is a test that reads the setting from the system itself, on a schedule, for every resource, and keeps the history. Exceptions then become explicit, approved, time-limited records. That is what the standards ask for.

What SOC 2, ISO 27001 and NIST say about continuous monitoring

None of the major frameworks requires a particular tool. All of them expect you to know, continuously, whether your controls still work, and to act when they do not.

AICPA Trust Services Criteria: CC4.1 and CC7.1

In the 2017 Trust Services Criteria (revised points of focus, 2022) that SOC 2 uses, CC4.1 maps to COSO principle 16: the entity selects, develops and performs ongoing and/or separate evaluations to confirm internal control components are present and functioning. A test built into daily operations is an ongoing evaluation. CC4.2 then expects deficiencies to be communicated in time for corrective action, which a failing test that opens a task shows directly.

CC7.1 covers detecting configuration changes that introduce vulnerabilities, and newly discovered vulnerabilities. Drift is exactly what a scheduled test catches. The auditor still tests that the monitoring works and that failures were handled; what changes is that the evidence covers the period, not a moment.

ISO/IEC 27001:2022 clause 9.1

Clause 9.1 of ISO/IEC 27001:2022 covers monitoring, measurement, analysis and evaluation. In general terms, it expects you to decide what you monitor and how, to evaluate the results, and to keep evidence of them. A test catalogue gives that decision a form an auditor can read: the test, the connector and setting it reads, the schedule, the owner and the history. Check the exact wording against your copy of the standard.

NIST SP 800-137 and SP 800-53 CA-7

NIST SP 800-137 defines information security continuous monitoring as maintaining ongoing awareness of information security, vulnerabilities and threats to support risk decisions. It makes two points that matter here. Monitoring cannot be achieved through manual processes alone or automated processes alone; automation suits technical controls, while management and operational controls must still be assessed even when that cannot be automated. And monitoring works best when output is "specific, measurable, actionable, relevant, and timely". A result that names the resource, the failing setting and the fix meets that bar.

SP 800-53 Rev. 5 turns this into control CA-7, Continuous Monitoring: metrics, frequencies for monitoring and for assessing control effectiveness, ongoing assessments, analysis, response actions and status reporting. SP 800-137A describes how to assess whether a monitoring programme itself works.

HIPAA Security Rule and PCI DSS

45 CFR 164.308(a)(8) requires a periodic technical and nontechnical evaluation, repeated when environmental or operational changes affect the security of electronic protected health information. 164.308(a)(1)(ii)(D) requires regular review of system activity records such as audit logs and access reports. Tests support the technical half; people own the nontechnical half.

PCI DSS v4.0.1 likewise builds ongoing checks into many of its requirements, including logging and monitoring and the detection of failures in security controls; see the current standard in the PCI Security Standards Council's document library for the exact requirements. A test that fails when cloud logging is switched off is that kind of signal.

What this means in practice

Together the standards ask for coverage of every in-scope resource, a frequency you can show, a record of what failed and who fixed it, and exceptions that are justified, approved and reviewed. Tests cover the first three for technical settings. Exclusions, done properly, cover the fourth.

How Safeguard's automated tests work

The Compliance and GRC suite (GA) has these areas in the app: Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center (GA) and Connectors. Automated checks live in Tests and Monitoring.

Connector, test, control

The docs describe a chain with three links:

• A connector links Safeguard to a system you run, with read-only access. It does not attach to a framework.
• A test checks one thing in a connected system, for example that every user signs in through federation, and records a result per resource.
• A control mapping ties the test to the controls it evidences, each with a one-sentence rationale an auditor can check. The app shows it as "Why this test evidences it" on the test's Controls tab.

When a test passes, the result counts toward every control it maps to, in every framework it maps to. Connecting an identity provider once can move SOC 2, ISO/IEC 27001 and NIST CSF 2.0 controls together.

Three sources a test can read

• A connected system, such as a cloud account, identity provider, code host, ticket tracker or device manager. Most tests are this kind.
• Safeguard's own records, such as policies, people, training and devices. These need no connector.
• Attestation, where no API exists. The docs list these under "Evidence by attestation": connect the system to record the connection, then attest the result. An accepted attestation counts toward the control, marked as attested, never as automated.

On the Tests page you can filter by source: "Connected systems" are the tests this post is about; "Scan checks" are software supply chain requirements decided by product scans, covered later.

When tests run

1. Schedule. The docs say tests run on a schedule, about every six hours, and each test runs as often as it is due, daily by default.
2. On demand. Run now on one test, or Run all tests on Compliance › Tests. Collect evidence now on the Connectors page starts an evidence collection immediately.
3. Preview. A new test starts in a preview period, typically 14 days. Its results appear but change no control status, readiness score or task until preview ends.

Also, automated tests for a provider are switched on per workspace by the Safeguard team. A connection can show Verified before its tests run. If Tests stays empty, ask for them to be enabled before assuming the connector is broken.

What a result can be

The app shows each test as Passing, Failing or Could not run, with counts of failing, excluded and total resources. Could not run means an API refused a call or a permission is missing; the app says plainly that this is not a failure, but not a pass either. A resource can also show as not re-checked, meaning its integration could not be read in the latest run, so the last good result is shown with its date. When an auditor asks how fresh a result is, the date answers.

Which frameworks automated tests map to, and how the crosswalk carries them further

A CIS benchmark is a catalogue mapping: results carry recommendation numbers on tests, filters and evidence, but the benchmark is not a framework in your library with its own readiness score. Filter Compliance › Tests by the benchmark to see its results.

The crosswalk

The crosswalk relates controls across SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and NIST SP 800-53. Per the docs, evidence counts toward another framework's control only through an equivalent row that has been reviewed or that your workspace approved, and only while the evidence is accepted and in date. Other related rows are suggestions, never passes. Credit never chains. NIST SP 800-53 has no direct test mappings, so its automated evidence comes through the crosswalk. Reviewers decide rows on Compliance › Crosswalk; the post on mapping one control to many frameworks explains equivalent versus partial mappings.

Linking tests to any other framework

1. Open the framework on Compliance › Frameworks, then the control.
2. Choose Link a test, search for it and click Link. Its result then counts toward that control like a catalogue mapping.
3. To change several at once, use Edit mappings on the framework's tests.

Your mappings show as "Added by your team" beside the catalogue's own. The catalogue rationale was written by Safeguard; yours needs your own justification, so write one.

What connectors check: tests by kind of system

The SOC 2 connector page in the docs lists, per Trust Services criterion, the tests that apply and the connectors that answer them. Grouped by kind of system:

Exact tests vary by connector, and your framework's Connectors tab is the authority for what your connections answer. Some criteria, such as CC1.1 and CC5.3, have tests that read Safeguard's own records and no connector at all.

A worked example: one CIS cloud benchmark

A benchmark shows most clearly what a test checks, because each test is named after one recommendation. The docs page for the CIS Amazon Web Services Foundations Benchmark v3.0.0 lists every recommendation Safeguard tests. A selection:

These are configuration facts an API answers with certainty, which is where automated tests are strong. None of them says whether the people with access should have it. That is an access review, covered under what tests cannot see.

Connector categories, auth methods and how to tell what is live

Categories

Safeguard's offering orders the connector catalogue by how directly each system produces evidence: identity and SSO first, then cloud infrastructure, source control, vulnerability scanning, HR systems, endpoint detection, device management, ticketing, observability, cloud storage, and further categories such as vendor risk, identity governance, security awareness and e-signature. On Compliance › Connectors you search by name or filter by category.

Three ways to connect

The offering files call the token method PAT; the docs call it API token. Same route.

The MCP row trips people up. Some vendors' OAuth sign-in connects their MCP server rather than their API. The docs say those connections serve Search but cannot feed tests, and the connector's guide tells you to use the API token method instead. If tests stay empty after an OAuth connection, check this first.

Credentials are encrypted at rest and never shown again. Every guide asks for the narrowest read-only grant, and Safeguard only makes read calls. A self-hosted system must be reachable at a public https address; private, loopback and cloud-metadata addresses are refused.

Card statuses

From a connected card you can Test connection, Reconnect, Re-authorize, Rename, Disconnect (tests stop, history stays) or Remove.

How to tell what is live

The docs catalogue lists far more connectors than are live today. Safeguard's offering is explicit that only part of the catalogue is live and the rest are built on request. Before you plan evidence around a connector:

1. Filter Compliance › Connectors by Automated evidence versus Connection record only. A connection record proves you use a system; it produces no test results.
2. Read the framework's Connectors tab: which connectors answer its tests, which you have connected and whether each is healthy.
3. After connecting, confirm results appear on Compliance › Tests once preview ends.

Admins can switch connectors off for members under Settings › Connector access, so an empty search can mean "not allowed here" rather than "not built".

Request integration

1. Open Compliance › Connectors and choose Request integration.
2. Fill in Integration name (required), Website (optional), Category, such as Identity & SSO, and What would you use it for? (optional, for example "MFA status of every user").
3. Choose Submit request. It is saved with the status requested, under your name and time, and the Safeguard team follows up.

Meanwhile, upload evidence for its controls on Compliance › Evidence. That keeps the control covered but produces no test result.

Step by step: connect a system, run its tests, fix a failure, re-run

This follows the compliance connectors, framework connectors and approvals docs. Where the docs show no screen, the step describes the outcome.

1. Read the framework's Connectors tab first. Open Compliance › Frameworks, choose the framework (for example SOC 2 Type 2) and open Connectors. Start with your identity provider and main cloud account; they feed most access and monitoring criteria.

2. Connect with the narrowest grant. On Compliance › Connectors, click Connect on the system. Choose OAuth where offered, or API token where the form says tests need it. Create the read-only grant the form describes and wait for Verified.

3. Choose what the connector collects. The What this connector collects panel lists each test and evidence check with a switch. If two identity providers could both answer MFA, switch it off on the one that is not your source of truth. Only the person who connected it or an administrator can change these switches.

4. Add every account. Some providers, including the major clouds, can be connected once per account. Use Add another account and give each a label such as "Production EU". Every test runs against each account and each result names its account. A missing second account is the most common coverage gap.

5. Run the tests. On Compliance › Tests, choose Run all tests, or Run now on one test.

6. Read a failing test before changing anything. The detail page has Overview, Resources, History, Exclusions and Controls tabs. Resources shows each resource, its result and since when; Show evidence reveals what the test read. Overview shows How to fix it, where to make the change and a vendor documentation link. History shows whether this is new drift or a long-standing gap.

7. Decide: fix or exclude. Most failures are real. A resource that must fail by design needs an exclusion (below). Never exclude to turn a number green.

8. Assign the fix. Once a test leaves preview, its failures count and can open tasks; during preview they open none. Use the test's Owner field to name the team responsible, so follow-up reaches people who can change the setting rather than whoever happened to click Connect.

9. Fix at the source, then re-run. Change the setting at the vendor, then choose Run now and confirm the resource passes. The History tab then shows the failing days followed by the passing run, which is clean CC4.2 evidence: found, communicated, fixed and verified by the same check.

10. Check the control. Open the mapped control from the test's Controls tab. Its status combines passing tests, accepted evidence and scan requirements. The continuous compliance post covers how controls and the readiness score fit together.

What a failing test looks like (illustrative)

An illustration of the fields the app uses, not output from any real account:

Test: People sign in through federation        Status: Failing
Mapped to: CIS AWS Foundations 1.21; SOC 2 CC6.1, CC6.2
Resources: 2 failing of 14 · 0 excluded         Last run: today

Resource                Result     Since
iam-user/ci-deployer    Failing    3 days ago
iam-user/breakglass-01  Failing    first run

How to fix it: remove console passwords from IAM users and grant
access through the identity provider. Vendor documentation: linked.
Owner: Platform team

The first resource is drift: a deploy user picked up a console password three days ago. Fix it. The second is an emergency access account that has failed since the first run because it must work when federation is down. That is what exclusions are for.

Test results as evidence: accepted on their own run, and expiry

On Compliance › Evidence, uploaded evidence starts as submitted and a compliance reviewer chooses Accept or Reject. The approvals docs make one exception: a result recorded by an automated test from its own run starts accepted on that basis.

The reasoning holds. A reviewer accepting a screenshot judges whether it is genuine, current and relevant. A test result was read from the system by a known check, at a recorded time, with its mapping rationale attached. Clicking Accept on every daily run would add work without adding assurance. The reviewer's job moves to test design: whether mappings hold, whether the right accounts are connected, and whether exclusions are justified.

For evidence people upload, the docs set three rules. Accept and Reject are stamped with who, when and why. Changing accepted evidence makes a new version that goes back to submitted. Accepted evidence with an end date becomes expiring inside its reminder window and expired from that date.

So uploaded evidence decays on a calendar while test evidence refreshes on a schedule. A control backed by both, say a backup configuration test plus an annual restore exercise report, shows the test passing daily and the report counting down to expiry.

Exclusions: reason, approver, expiry and five states

An auditor does not ask whether you have exceptions. They ask who approved this one, why, and when it ends. Safeguard's exclusion flow is built around those three questions.

The flow

From the approvals docs and the app:

1. Open the test on Compliance › Tests and find the resource on its Resources tab.
2. Choose Exclude.
3. Give a Reason. The app's own placeholder is a break-glass account kept for emergency access whose use is alerted and reviewed monthly. Write it in full sentences, not a ticket number.
4. Choose an Approver.
5. Set Expires on, matched to how often the exception is reviewed.
6. Choose Request exclusion.

Nothing is excluded until the approver approves it. From approval to the expiry date, the resource counts as not applicable, with your reason shown as the evidence. The reason is the evidence for that resource, so write it for an auditor who has never met you.

The five states

The test's Exclusions tab lists them all: your exception register for technical controls.

Who can approve

The approver must be a compliance reviewer. Per the approvals docs, that is an administrator (Super Admin, Tenant Admin or Org Admin), a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone granted a compliance review, approve, admin or manage permission. Three rules sit above that:

• The Auditor role alone is not a reviewer; an auditor tests decisions and does not make them.
• Safeguard's AI assistant and MCP clients can draft and submit but never accept, approve, launch or acknowledge, whoever is signed in.
• If Safeguard cannot tell who is deciding, it refuses the decision.

That last pair matters if you read results through an assistant. With Safeguard added from Claude's connector directory (a community listing; Team and Enterprise Owners add it first, see adding the connector on Claude Team and Enterprise), and where your plan and admin settings expose compliance tools, Claude can list failing tests and draft an exclusion reason. Only the named approver can approve it, in the app.

The engineer who requests an exclusion should not approve it. The who approves what post covers reviewer roles across the suite.

Why break-glass accounts are the classic case

A break-glass account is an emergency administrator kept outside the normal sign-in path, so you can still get in when single sign-on or the identity provider is down. By design it fails some tests: it is not federated, it may not sit in the identity provider, and it holds broad rights.

Disabling it removes your recovery path. Excluding it with no conditions hides a powerful account. The answer sits between: exclude it from the specific test it must fail, and name the compensating controls in the reason. For the illustrative account above: "Emergency access account used only when federation is unavailable. Hardware MFA on the account. Every use raises an alert reviewed by the security lead within one business day. Credentials in a sealed vault; access reviewed monthly."

Then make sure the compensating controls are themselves tested. In the CIS example, 1.6 checks hardware-backed root MFA and 4.3 checks that root activity raises an alert. If those pass, the exclusion on 1.21 rests on evidence, not just words.

Other reasonable candidates: a vendor integration's service account that cannot use MFA, with a scoped and rotated token; a resource being decommissioned this quarter, with the decommission date as the expiry. Poor candidates: "will fix later", which is a remediation task; a whole class of resources failing for the same reason, which means the rule or scope is wrong; and a year-long expiry on a reason that says "reviewed monthly".

Exclusion, collection switch, scope: three different things

Only the first is an exception to a rule. The second chooses the source of truth. The third says a requirement does not apply, which an auditor tests separately. See exception registers versus risk registers for how exceptions relate to risk records.

How tests relate to software supply chain scan requirements

Safeguard covers a framework through two separate evidence sources. Scan requirements are checked on every product scan against what the scan found, including the product's SBOM, and come from SBOM generation and analysis (GA) and software composition analysis (GA). The docs sort them into decided by a scan, checked by a scan for a prerequisite, and needing evidence a scan cannot see. Automated tests read the systems you run.

They meet on the control. SOC 2 CC7.1 can draw on a cloud test that alerts on configuration changes and on scan requirements showing vulnerable components are tracked. A control that passes on one source and fails on the other tells you something specific: your cloud is monitored but the software you ship is not, or the reverse. The SOC 2 post in this series walks through both sources for one framework.

What tests cannot see

Tests read configuration facts from APIs. Much of a compliance programme is not that.

• Whether access is appropriate. A test confirms a user is an admin with MFA, not whether they should be. That is an access review on Compliance › Access Reviews, where a person decides Keep, Revoke or Modify per account.
• Process quality. A ticketing test can show a change record exists. It cannot show the review behind it was sound.
• HR records. Background checks, signed agreements and training often need uploaded evidence.
• Physical security. Badge access and visitor logs rarely have an API. Upload evidence or rely on your hosting provider's report.
• Governance. No API proves leadership is accountable.
• Unconnected systems. An unconnected cloud account is invisible, not passing.

NIST's guidance says the same: management and operational controls must be assessed even when monitoring them cannot be automated.

Decision table: which tool for which gap

What Safeguard does not do

• It does not connect every system you run. Only part of the connector catalogue is live today; the rest are built on request, and the docs list connectors that may not be live for your plan. Check the Automated evidence filter and the framework's Connectors tab first.
• It does not judge intent. Tests read configuration, not whether access is appropriate or a process was followed in spirit.
• It does not exclude anything on its own. Every exclusion needs a named approver and ends on its expiry date. Assistants can draft but not approve.
• It does not change your systems. Connections are read-only. Fixes happen at the vendor or through your ticketing process.
• It does not run tests on MCP-only connections. Those serve Griffin AI Search (GA).
• It does not count preview results toward controls, the readiness score or tasks.
• It does not replace your auditor. A passing test is evidence toward a control, not proof. The readiness score is Safeguard's assessment of what it can see, not an audit opinion; an accredited auditor issues any report or certificate.
• It does not see what you have not connected.

Common mistakes

Connecting by OAuth and waiting for tests that never come. If the vendor's OAuth connects its MCP server, use the API token method the guide names.

Treating Verified as "tests are running". Verified means the credential works. Tests are switched on per workspace and new ones sit in preview.

Connecting one account of five. Coverage is per account. Add and label every production account.

Reading Could not run as a pass. Fix the grant.

Excluding to clear the dashboard. Fix drift; exclude only resources that must fail by design.

Self-approving exclusions. Pick an approver who would say no.

Long expiries on short-cadence reasons. Renewal is when someone checks the reason is still true.

Forgetting compensating controls. A break-glass exclusion is only as good as the tested alerting and MFA around it.

Leaving the Owner field empty on critical tests. Name the team that can actually change the setting.

FAQ

What do Safeguard's automated compliance tests check?

Each test checks one setting in a connected system, such as whether console sign-in without MFA raises an alert or whether users sign in through federation. Results are recorded per resource and mapped to controls with a rationale an auditor can read.

Which frameworks do Safeguard compliance tests map to?

Directly to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0, the CIS Foundations Benchmarks for four major clouds and the CIS Kubernetes Benchmark. Reviewed equivalent crosswalk rows carry them to related frameworks such as NIST SP 800-53, and you can link tests to any other framework yourself.

How often do Safeguard compliance tests run?

The scheduler runs about every six hours, and each test runs as often as it is due, daily by default. Run now and Run all tests on Compliance › Tests start a run immediately.

Why are my test results not changing my readiness score?

Usually the preview period: a new test's results show but change no control, score or task until preview ends, typically 14 days. Also check the result is not Could not run.

How do I exclude a break-glass account from a compliance test?

Open the test on Compliance › Tests, find the account on Resources and choose Exclude. Give a Reason naming the compensating controls, choose an Approver and set Expires on. Nothing is excluded until the approver approves it.

What are the states of a test exclusion in Safeguard?

Pending approval, Approved, Rejected, Revoked and Expired, all listed on the test's Exclusions tab.

Do automated test results need a reviewer to accept them?

No. A result recorded by an automated test from its own run starts accepted. Uploaded evidence starts as submitted and needs a reviewer.

Which Safeguard connectors are live?

Only part of the catalogue is live today; the rest are built on request. Filter Compliance › Connectors by Automated evidence, read the framework's Connectors tab, and use Request integration for anything missing.

Can Claude approve a compliance test exclusion through Safeguard?

No. Safeguard's AI assistant and MCP clients such as Claude can read and draft but never accept, approve, launch or acknowledge. The named approver decides in the app.

From a failing control to a fixed dependency

Most failing tests are fixed in a console. Some controls lead back to code: a CC7.1 scan requirement that fails because a product ships a component with a known exploited vulnerability is a software fix, not a settings change. For those, what matters is how fast the fixed version reaches production, and what to do when no fix exists yet.

Fix it without waiting for upstream

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

1. Autonomous remediation: pull requests, not tickets

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

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

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

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

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

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

See how Safeguard would help

The first demo is a real Safeguard CLI (GA) session: install, run safeguard to open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. When a scan requirement fails because of a vulnerable component, this is how the fix is made and checked before the next scan re-evaluates the control.

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

The second demo shows Claude being connected to the Safeguard MCP server with an OAuth sign-in and choosing which tools Claude can use. In practice, add Safeguard from Claude's connector directory rather than a custom connection. The same boundary applies to compliance tests: the assistant gets only the access your tenant grants, can help read failing tests and draft an exclusion reason, and leaves the approval to a person in the app.

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

To try it, download the apps at safeguard.sh/download and read the documentation at docs.safeguard.sh. For presenting test results to different audiences, see the compliance reporting guide.

Quick check

Sources

• Safeguard docs: Compliance connectors
• Safeguard docs: Frameworks and connectors
• Safeguard docs: SOC 2 and connectors
• Safeguard docs: CIS AWS Foundations Benchmark and connectors
• Safeguard docs: Compliance frameworks
• Safeguard docs: Approvals
• Safeguard docs: Requests and approvals
• Safeguard docs: Integration requests
• Safeguard docs: CLI usage
• AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• NIST SP 800-137: Information Security Continuous Monitoring
• NIST SP 800-137 (PDF)
• NIST SP 800-137A: Assessing ISCM Programs
• NIST SP 800-53 Rev. 5
• NIST SP 800-53 Rev. 5 (PDF)
• NIST Cybersecurity Framework
• NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0
• eCFR: 45 CFR 164.308, Administrative safeguards
• CIS Benchmarks
• PCI Security Standards Council: Document Library

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