Risk acceptance that expires: mitigations in Safeguard

When a finding cannot be fixed now, record it as a mitigation on the project in Safeguard. You choose a type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), write the justification, name the approver, attach evidence, set the scope and, for a risk acceptance, an expiry date. Safeguard reminds you before it lapses and logs every change.

An auditor will ask whether the decision was made by someone allowed to make it, whether it rested on something real, whether it ended when it should have, and whether you can prove that a year later. This post walks through how the Mitigations tab answers those questions, field by field.

It is deliberately narrow. Gate exceptions, VEX documents and the compliance risk register each have their own posts, linked below. This one is about the per-finding record: the decision that a specific vulnerability in a specific project will not be fixed today, why, for how long, and who said so.

Key takeaways

• A mitigation is a record on one project's finding, not a switch. It lives on the project's Mitigations tab, is created from the Vulnerabilities tab, and carries a type, a justification, an approver, optional evidence, a scope and, for risk acceptances, an optional expiry date.
• Four types, four different claims. Risk Acceptance says "it applies and we are carrying it". False Positive says "the scanner is wrong". Workaround Applied says "it applies, and something else holds it back". Not Applicable says "it exists here but cannot matter here".
• Expiry is optional in the form, so make it mandatory in your process. Safeguard offers 30, 90, 180 and 365 day presets or a custom date, and notifies you 14 days before, 7 days before and on the day.
• Expired means the finding counts again. Active mitigations keep a vulnerability out of gate failures. Expired ones do not.
• The history is the audit trail. Created, modified, approved, expired and revoked events are logged with who, when and why, and each mitigation's History tab shows them.
• Reports close the loop. Reports › Mitigations exports active and expired mitigations, a breakdown by type, an approver summary and an expiration timeline as PDF, CSV or Excel.

Why "we will fix it later" fails an audit

Every security program carries findings it has not fixed. A fix may not exist yet. The upgrade may break a payment flow that two teams depend on. The vulnerable function may sit in a code path your service never calls. None of that is a problem in itself. Risk management frameworks expect it.

NIST's guide to enterprise patch management, SP 800-40 Revision 4, names four risk responses for vulnerable software. You can accept the risk, for example by relying on existing controls or judging the impact low enough. You can mitigate it, by patching, disabling a vulnerable feature or isolating the asset with firewalls and segmentation. You can transfer it, or avoid it by removing the software. The guide also notes that by default an organization already accepts the risk of the software it runs. The question is never whether you accept risk, only whether you do it on purpose.

NIST SP 800-53 Revision 5 says the same in control language. RA-7 (Risk Response) asks you to respond to findings from assessments, monitoring and audits in line with organizational risk tolerance. CA-5 (Plan of Action and Milestones) asks for a documented plan for weaknesses not yet corrected, kept up to date. SI-2 (Flaw Remediation) asks for security relevant updates within an organization defined period after release. The Secure Software Development Framework, NIST SP 800-218, puts it in one line as practice RV.2.2: plan and implement risk responses for vulnerabilities.

What fails audits is not the open finding. It is the open finding with no record, or with a record that cannot answer four questions:

• Who decided this, and were they allowed to decide it?
• What was the decision based on: an analysis, a compensating control, a ticket, a vendor statement?
• When does the decision end, and what happened when it did?
• Has anything changed since, such as a fix shipping or the vulnerability landing on a known exploited list?

A spreadsheet can hold those answers on the day it is written, but it cannot remind anyone when a decision runs out. That is the gap the Mitigations tab closes.

Mitigations, gate exceptions, VEX and the risk register

Safeguard has four places where a team records that it is not fixing something right now. Picking the wrong one is the most common reason a record does not hold up later.

The gate exception is about release flow: a developer requests it, approvers are notified, someone decides, and the trail is recorded. It answers "can this build ship?" We covered its design in Designing gate exceptions in Safeguard.

The mitigation answers a broader question: "what is our position on this finding in this project?" While active it also affects gates, but it is a statement about the finding, and it stays in force across every build until it expires, is revoked, or is superseded by a fix.

A VEX statement is the outward version of some mitigations, covered in its own section below. The compliance risk register works one level up: one accepted vulnerability may roll into a broader entry such as "the billing platform cannot be upgraded until next year's rewrite". Its rules are described in the compliance risk register post.

The four mitigation types, and the claim each one makes

Safeguard's Mitigations docs define four types. Each asserts something different, and that assertion is what an auditor or a customer will test.

Risk Acceptance

The vulnerability applies, you understand it, and you choose to carry it for a period. The docs list the usual reasons: it is not exploitable in your context, remediation costs more than the risk, the fix would break critical functionality, or you are accepting it temporarily while you plan remediation. That last reason is the most common, and "temporary while we plan" with no end date is a permanent acceptance written politely.

Risk Acceptance is also the only type the form allows an expiration date on. A false positive does not become true with time, so that makes sense, but it means time bound review of the other types has to come from your process.

False Positive

The scanner is wrong. The docs give four cases: the vulnerability was incorrectly identified, the component is not actually present, the version detection was incorrect, or a different component has the same name.

This is a factual claim, so it needs facts: the lockfile line with the real version, package coordinates that differ from the advisory's, build output showing the component is not shipped. Name collisions across ecosystems are a real source of false matches, and the evidence for one is short and decisive. Report misdetections too, so they get fixed at the source.

Workaround Applied

The vulnerability applies and the component is vulnerable, but something else stops exploitation. The docs list configuration changes, network controls, compensating controls and partial remediation. This is what SP 800-40 calls mitigating with additional controls rather than eliminating the vulnerability.

The evidence should show the control exists and is in force: the configuration line that disables the feature, the firewall rule, the change ticket. Configuration drifts and network rules get widened during incidents, so a workaround needs a review date in your process even though the form offers expiry only on Risk Acceptance.

Not Applicable

The component and the vulnerability are both real, but the vulnerability cannot matter in this project. The docs give four cases: the vulnerable code path is not used, the feature is disabled, the component is only in development, or the platform does not apply.

"The vulnerable code path is not used" is a claim that can be checked, and reachability analysis is the evidence. A path not reached today can be reached after next week's feature work, which is why Not Applicable records also deserve a scheduled review.

Choosing between them

If two types seem to fit, pick the one that claims less. Workaround Applied asks less of your evidence than Not Applicable, and Risk Acceptance asks less than either. An overstated claim is worse than an honest acceptance, because when it turns out to be wrong the record looks like it was hiding something.

The mitigation form, field by field

The form has six fields. Type, Justification, Approved By and Scope are required. Expiration Date (offered only for Risk Acceptance) and Evidence are optional.

Justification (required)

This is the field auditors read first and teams write worst. "Not exploitable" is a conclusion, not a justification. Safeguard's best practices for mitigations ask for detailed justifications, references to external analysis, ticket or issue numbers, and documented compensating controls. A template that covers all of that:

Finding: <vulnerability id> in <component>@<version> (<direct|transitive> via <parent>)
Reason not fixed: <specific blocker, e.g. no fixed release; 5.x upgrade breaks SAML login, see TICKET-123>
Exposure: <where the component runs, internet facing or internal, data it touches>
Risk reducers: <controls in force, with identifiers>
Exit: <event or date that ends this record>
Reviewed against: CVSS <score>, EPSS <score on date>, KEV <listed|not listed on date>

The last line is worth the extra seconds. Exploitation data changes. A finding with a low exploitation probability when you accepted it may be added to CISA's Known Exploited Vulnerabilities catalog next month. Recording the values you relied on, with the date, lets a reviewer see whether the ground moved.

Approved By (required)

The field records who approved the mitigation, and the audit trail logs the approval with the approver and a timestamp. The docs' best practices say to require approval for risk acceptances.

Two rules make the field mean something. The approver should not be the person who raised the record; a developer accepting their own finding is not an approval. And the approver should be someone your written policy gives that authority to, at that severity. One illustrative ladder is an AppSec engineer for low and medium, the head of AppSec for high, and a named risk owner for critical or anything on the KEV catalog; the gate-exception post covers ownership roles in more detail. Federal programs make the same point more strongly: NIST's Risk Management Framework, SP 800-37 Revision 2, says the explicit acceptance of risk is the responsibility of the authorizing official and cannot be delegated.

Safeguard's Compliance › Risks register enforces a ladder of its own for business risk: a low or medium residual risk can be accepted by its owner, while a high or critical one needs an approver with an admin role and a review date within a year. That rule belongs to the register, not the Mitigations tab, but it is a sensible model to copy into your mitigation policy.

Evidence (optional)

Optional in the form, close to mandatory in practice for everything but a short risk acceptance. Link to systems of record rather than pasting screenshots: a ticket, a pull request, a configuration file at a commit. Screenshots age badly and prove little about what was in force on a given date.

Scope (required): this version only, or all versions

"This version only" is the safer choice. If someone moves to another version that is still vulnerable, the finding comes back and gets looked at again, which is usually right because the analysis may change.

"All versions" fits a narrow set of cases: a name collision that will match every version, or a Not Applicable record whose reason is architectural rather than version specific. Use it sparingly and say why in the justification.

Expiration Date (optional, Risk Acceptance only)

Covered in its own section below. The short version: always set one.

Statuses: Active, Expired, Revoked, Superseded

A long Expired list means the review loop is not running. Superseded tells the best story to an auditor: an acceptance raised in March and superseded by a fix in May was temporary in fact as well as in name.

To revoke, open the mitigation, choose Revoke and give a reason. "Revoked: reachability now shows the vulnerable function called from the new export endpoint (PR 4512)" is useful a year later. "No longer valid" is not.

Choosing an expiry that matches the risk

Safeguard's presets are 30 days for a short term acceptance, 90 for a quarterly review cycle, 180 for semi annual and 365 for annual, plus a custom date. They map to review cycles, not to how long you hope to avoid the fix. Choose by asking how quickly the facts behind the decision could change and how bad it would be if they did.

Four public inputs drive the table, and all of them belong in the justification.

CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of active exploitation. A KEV listing is the clearest signal that "accept for now" should be short.

EPSS, from FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It is updated continually, which is exactly why you record the value and the date.

CVSS v4.0, also from FIRST, has four metric groups: Base, Threat, Environmental and Supplemental. The Environmental group, through Modified Base metrics and Security Requirements, is a structured way to say "this is less severe in our deployment". If you use it, the adjusted vector belongs in the evidence.

SSVC, CISA's Stakeholder-Specific Vulnerability Categorization, ends in Track, Track*, Attend or Act. A finding that lands on Attend or Act is a poor candidate for a long acceptance.

Expiry notifications and the review loop

Safeguard notifies you 14 days before a mitigation expires, 7 days before, and on the expiration date. That gives an owner two weeks to re-check the facts and a week of warning if they have not. It only helps if it reaches someone who will act, so confirm who receives those notices and check that the named approver is still on the team. Approvers leave; their records do not.

The docs describe the review in three steps: open the Mitigations tab, filter by Status: Expired, and for each one extend the expiration if it is still valid, revoke it if it no longer applies, or upgrade to the fix if one is available. A review that holds up in an audit runs five checks before choosing:

1. Is a fix available now? If yes, the default is to fix, and an extension needs a new, specific reason.
2. Has exploitation status changed? Compare the KEV catalog and the current EPSS score with the values in the justification.
3. Has exposure changed? An internal service may now face the internet; a disabled feature may now be on.
4. Is the compensating control still in force? Open the rule or configuration the evidence links to.
5. Is the approver still the right person? A changed severity may need a different approver under your ladder.

Then extend with an updated justification that says what you checked: "Extended 90 days. No fixed release yet (upstream issue still open on 2 Nov). EPSS unchanged, not on KEV. WAF rule 7712 confirmed in force." That one line is the difference between an extension and a rubber stamp.

Do not wait for the calendar when the facts move. If an accepted vulnerability is added to the KEV catalog, or reachability changes for a Not Applicable record, or a development only component turns up in a shipped image, review that record the same day.

Mitigations and gates: what changes in CI

The Mitigations docs state three rules: active mitigations exclude vulnerabilities from gate failures, expired mitigations do not, and policy based mitigations apply automatically.

Gates evaluate policies, and each policy has an Action. Per the Policy outcomes docs, when a policy fails, Block fails the gate, Warn lets the gate pass with a warning naming the policy, and Notify lets it pass and sends a notification to the workspace's configured channels: the in-app bell, connected chat integrations and email by each person's preferences. A policy is evaluated when it is linked to a gate and again after new assessment data arrives for the product.

Put together, the effect of an expiry follows from those rules. While a mitigation is active, the finding is excluded from gate failures. Once it expires, it is not, so a Block policy that matches it can fail the gate at its next evaluation. That turns an unreviewed expiry into a visible event in the pipeline instead of a quiet line in a spreadsheet. A Notify policy alongside it tells you when a policy goes from passing to failing, without repeating the same failure on every evaluation.

In CI, the documented command waits for the scan and for the gate's policies to be evaluated:

safeguard ci scan --wait --fail-on-gate "release-gate"

It exits 0 when the gate is Passed or Warning, and non zero when the gate is Failed, Error or Not evaluated, printing the Block policies that failed. Policy outcomes are turned on per workspace; if your Gates and Policies tables show no Outcome column, ask your Safeguard contact to turn it on.

Plan for the day an acceptance expires and a release is due. If the honest answer is "we still cannot fix it", the path is a reviewed extension made before the expiry date. If it is "this one release must ship and we fix it next sprint", that is a gate exception with its own approval. Keeping the two apart keeps the meaning of each record clean.

Mitigation policies: standing decisions, applied automatically

Under Settings › Mitigation Policies you can create policies that apply mitigations automatically, scoped to the organization or to a project. The docs list four types:

Each is a risk decision made once and applied many times, so treat it with more care than a single record. Keep a written reason and an owner for every policy. Put a review on the calendar at least quarterly, because the docs describe expiry notifications for mitigations, not for policies. Pair any severity threshold with a gate policy that blocks KEV listed vulnerabilities whatever their score. And prove Development Only is true by checking the SBOM of the image you actually ship.

Bulk mitigations, and when not to use them

On the Vulnerabilities tab you can select several findings, choose Bulk Actions › Add Mitigation, fill in common details and Apply to Selected. That is the right tool when one fact explains many findings, such as a test only component (declared as a test dependency and absent from the release image SBOM) carrying a dozen advisories.

It is the wrong tool when the findings only share a severity. Bulk accepting "all the mediums in this project" produces identical justifications that explain nothing about any one finding. If one justification is not true for every selected finding, do not bulk apply.

The audit trail: what is logged and how to show it

Open a mitigation and choose its History tab to see every change.

Auditors testing vulnerability management usually sample: "for a sample of vulnerabilities open past your remediation target during the period, show the approved exception or risk acceptance." For each sampled finding, the History tab answers in order: created on this date by this person with this justification, approved by this person at this time, modified on these dates, then expired, revoked or superseded.

What the trail cannot do is make a weak record strong. If the justification says "accepted" and the evidence field is empty, the trail proves only that someone typed "accepted".

Reports: one file for the review meeting and the auditor

Go to Reports › Mitigations, select a date range and filters, choose PDF, CSV or Excel, and download. The report contains an active mitigations summary, expired mitigations requiring review, a breakdown by type, an approver summary and an expiration timeline.

Give the auditor the CSV or Excel file, so they can compare the approver summary against your authority ladder and draw a sample. The PDF is for the monthly review pack.

Mapping mitigation types to VEX

Some customers want a statement their tools can read, saying whether your product is affected by a vulnerability. That is VEX (Vulnerability Exploitability eXchange). CISA's minimum requirements for VEX, published April 2023, define four statuses: Not Affected, Affected, Fixed and Under Investigation. A Not Affected statement should carry a justification, and must carry an impact statement if it does not; an Affected statement carries an action statement. OpenVEX and CycloneDX implement the same idea with their own fields.

Three cautions. A Risk Acceptance is never Not Affected; saying otherwise is a false statement to a customer. OpenVEX's inline_mitigations_already_exist is reserved for built-in protections a user cannot configure or disable, so it almost never fits a workaround you applied yourself. And a workaround usually lives in your environment, such as your network rules, while a customer may run the component somewhere your workaround does not exist. Be precise about which product and deployment a statement covers. How Safeguard ingests and shares VEX is covered in How VEX works in Safeguard and Ingest and share VEX and CSAF in Safeguard.

Three worked examples

Example 1: a high severity flaw with no fix yet

A transitive dependency of your API gateway, an XML parsing library, has a new high severity advisory and no fixed version; the maintainer's issue says a release is planned. Reachability shows the vulnerable function is reached from one internal admin endpoint. It is not on the KEV catalog and its EPSS score is low.

• Type: Risk Acceptance. The path is reached, so Not Applicable would be dishonest.
• Justification: "Finding: high severity advisory in xml-lib 2.4.1 (transitive via api-gateway-core). Reason not fixed: no fixed release; upstream issue open. Exposure: reached from the admin import endpoint only; internal, behind SSO. Risk reducers: admin import limited to the ops group (access policy AP-12). Exit: upgrade within 7 days of a fixed release, tracked in SEC-441. Reviewed against: CVSS 7.5, EPSS low on 1 Nov, not on KEV on 1 Nov."
• Approved By: head of AppSec, per the ladder for high severity.
• Evidence: the upstream issue, SEC-441 and the access policy.
• Scope: this version only, since the next version may carry the fix.
• Expiry: 30 days.

When the fixed release ships and the upgrade lands, the mitigation shows Superseded and the history tells a complete story.

Example 2: a false match across ecosystems

A Python service is flagged for an advisory against a JavaScript package with the same name. Record it as a False Positive ("different component with same name"), put both package coordinates side by side in the justification, attach the lockfile at the commit, and set scope to all versions because the mismatch is about identity. No expiry is offered for this type, so add it to the false positives your team re-samples each quarter.

Step by step: setting up the process

1. Write the policy first. Define the four types, the approval ladder by severity and KEV status, default expiry by finding profile, and the evidence each type needs. Two pages is enough.
2. Set remediation targets the policy refers to, for example critical in 15 days and high in 30. A mitigation is the record for anything that will miss its target.
3. Confirm who receives the notices, so the 14 day, 7 day and same day expiry notices reach the owning team.
4. Create mitigations from the Vulnerabilities tab. Open the project, find the finding, choose Add Mitigation from the ⋮ menu, fill in the form with the justification template and linked evidence, and save.
5. Keep mitigation policies few and owned, under Settings › Mitigation Policies, each with a quarterly review.
6. Make expiry visible in CI with a Block policy on the gate and safeguard ci scan --wait --fail-on-gate in the pipeline.
7. Review monthly: filter the Mitigations tab by Status: Expired and walk the next 30 days of the expiration timeline.
8. Audit yourself quarterly the way an auditor would, then export Reports › Mitigations as CSV or Excel for the real one.

Where Safeguard fits, and where it does not

Safeguard holds the record, the expiry, the reminders, the history, the reports and the effect on gates, next to the facts most justifications rest on: the component and version in each project, the vulnerability match, reachability and exploitation signals.

It does not make the decision for you, and it cannot make a compensating control real. If the network rule a Workaround Applied record cites is removed, the record alone cannot know; your review loop has to check. Your approval ladder and remediation targets come from your policy and risk tolerance. For assistants, apply the rule Safeguard's Approvals docs set for compliance decisions: an assistant or MCP client can draft and submit, and a named person decides. For risks bigger than one finding, the compliance risk register is the better home, and mitigation records can point to it.

Common mistakes

• Risk acceptances with no expiry. The form allows it. Your policy should not.
• "Not exploitable" as the whole justification. It is a conclusion. Say why, with evidence.
• Self approval. An auditor will compare the approver with the person who raised the record.
• Not Applicable where the honest type is Risk Acceptance. It looks better on a dashboard and worse in an audit once reachability changes.
• Bulk accepting by severity. One justification copied onto thirty findings explains none of them.
• Mitigation policies with no owner. A threshold set two years ago still accepts findings today, and nobody remembers why.
• Extending without re-checking. An extension that changes only the date is a rubber stamp.
• Using a mitigation to ship one release. That is a gate exception.
• Publishing a Risk Acceptance as "not affected" VEX. It is a false statement to customers.
• Never re-sampling false positives. An "all versions" false positive can hide a real finding after the component changes.

FAQ

What is a vulnerability mitigation in Safeguard?

A record on a project's Mitigations tab that documents why a specific vulnerability is not being fixed right now. It has a type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), a justification, an approver, optional evidence, a scope and, for risk acceptances, an optional expiry date.

How do I accept the risk of a vulnerability in Safeguard?

Open the project's Vulnerabilities tab, find the vulnerability, choose Add Mitigation from the ⋮ menu, select Risk Acceptance, write the justification, name the approver, attach evidence, choose the scope, set an expiry date and save.

Does a risk acceptance in Safeguard expire?

Only if you set an expiration date: 30, 90, 180 or 365 days, or a custom date. Safeguard notifies you 14 days before, 7 days before and on the day. When it passes, the status becomes Expired and the mitigation no longer excludes the vulnerability from gate failures.

What happens to a security gate when a mitigation expires?

The finding counts again, so a Block policy that matches it fails the gate when the policy is next evaluated, which happens after new assessment data arrives for the product.

What is the difference between a mitigation and a gate exception?

A mitigation is a standing record of your position on a finding in a project. A gate exception lets a build pass a specific policy despite a finding, after a request and approval.

Can I see who approved a mitigation and when?

Yes. The audit trail logs Created, Modified, Approved, Expired and Revoked events, with approver and timestamp for approvals. Open the mitigation and choose its History tab.

How do I export mitigations for an auditor?

Go to Reports › Mitigations, choose a date range and filters, and download PDF, CSV or Excel. The report covers active and expired mitigations, a breakdown by type, an approver summary and an expiration timeline.

Should I mark a vulnerability Not Applicable or False Positive?

False Positive means the scanner is wrong about the component or version. Not Applicable means the component and vulnerability are real but cannot matter here, for example because the vulnerable code path is not used.

Keep the code behind your exceptions current

Every record on the Mitigations tab is a vulnerability you chose to carry for a while, and the best acceptance is one that ends in an upgrade. The sooner the safe version is found and the pull request opened, the shorter the list you have to review.

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, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. 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. Auto-merge is a separate switch and stays off by default, so your team decides what merges 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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 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

Mitigations are recorded in the web app. These demos show the flows around them: an assistant that reads findings with the tools you allow, a person approving each change, and the fix that ends an acceptance.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Use the same pattern to have an assistant gather the facts for a justification, while a named person approves the mitigation in the app.

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

In this real CLI session you run safeguard to open the interactive terminal and ask it to fix a lodash CVE. 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. That is how a risk acceptance should end: a tested upgrade, after which the mitigation shows Superseded.

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

This is a real Android session: work is sent to a computer running the Safeguard CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. When an expiry notice arrives and the fix is ready, the owner of the record can approve the work from wherever they are.

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

To try it on your own projects, download Safeguard or read the CLI docs.

Quick check

Sources

• Safeguard docs: Mitigations
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Policies and Gates
• Safeguard docs: Approvals
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
• NIST SP 800-218, Secure Software Development Framework
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: CVSS v4.0 Specification
• OpenVEX specification
• CycloneDX 1.6 JSON reference

Last reviewed: 1 November 2026. Product behaviour is described from Safeguard's public docs; check the linked pages for changes.