How to Get Developers to Fix Security Findings Without a Ticket Queue

Developers fix security findings when the finding arrives as a small, reviewable change in the place they already work, addressed to the team that owns the code, with the evidence and the test results attached. They ignore findings that arrive as a ticket asking them to research a CVE, find the manifest, pick a safe version and prove nothing breaks. So the job is to route each finding to an owner automatically and, where a fixed version exists, hand that owner a pull request instead of a question.

Below: why ticket queues fail, what the standards say, how to route ownership, and how Safeguard does this job today, with a maturity label on every capability and the limits to plan around.

Key takeaways

• Tickets are records, not work. The SSDF expects each vulnerability recorded. The failure is when the ticket is all the developer gets, so the research lands on them.
• Ownership comes before automation. Route each dependency finding to the team that owns the manifest or lockfile, with a named fallback owner.
• A fix request a developer can act on in minutes names the file, the dependency path, the fixed version, the breaking change risk, the exploit signals and the reachability verdict, and ideally includes the diff and the test results.
• Use a pull request when a fixed version exists and the change is mechanical. Use a ticket when no fix exists, when the fix is a design change, or when the right answer is a mitigation or a documented risk acceptance.
• Control the flow. Batch one pull request per repository, fix reachable and known exploited issues first, start with the safest upgrade strategy, and pilot on one repository.
• Measure flow, not volume. Track open to merged time, pull request acceptance rate, reopened findings and findings per release.
• Safeguard maturity labels used in this post: autonomous remediation and Griffin fix pull requests (single, bulk and page level) are GA, and ship switched off with every category set to Manual. Reachability analysis and prioritisation is GA (some language support is marked Preview in the docs). SCA and vulnerability management with EPSS and KEV is GA. Policies, gates and guardrails are GA. IDE extensions and the CLI are GA. Ticketing integrations such as Jira carry no separate label in Safeguard's offering files, so treat them as early access until you confirm the depth you need. Fork and patch is early access. SAST is early access.

Why security tickets sit untouched

A scanner export becomes hundreds of tickets, filed by severity onto project boards. Three sprints later most are untouched, and some were closed as "won't fix" by someone who could not work out what the ticket wanted. That is not indifference. It has four structural causes.

No real owner

A ticket assigned to a project board is assigned to nobody. The person who triages the board sees a security ticket with a CVE identifier, no link to a file they recognise, and a severity they did not set. If the component is a transitive dependency of a shared library, the team that receives the ticket may not even control the version. The ticket bounces between teams until it ages out.

No context

A typical scanner export gives you a package name, a version, a CVE identifier and a CVSS score. It rarely tells the developer which manifest brought the package in, whether their code calls the vulnerable function, whether the issue is being exploited, or what version fixes it without breaking the build. Each missing fact is a question the developer has to answer before they can start.

The research burden lands on the wrong person

This is the core problem. A ticket that says "upgrade X to fix CVE Y" hands the developer a research project: read the advisory, find the fixed version, check the changelog for breaking changes, work out whether a transitive conflict blocks the upgrade, update the lockfile, run the tests, and explain the change to a reviewer. For a developer who has never seen the advisory, that can take hours. For the security engineer who already read it, much of that work was already done once and then thrown away when the ticket was written.

Competing priorities, with no cost to waiting

Feature work has a product manager and a deadline. A security ticket has a severity label, so it loses every sprint planning meeting until an incident makes the cost of waiting visible.

The common thread: the ticket asks the developer to do work that could have been done before it was written. Move the research, the version choice and the first test run upstream, so the developer's job shrinks to review and merge.

What CISA's Secure by Design principles and the SSDF say about who carries the burden

The standards are useful here because they shift the argument from "security wants developers to do more" to "the organisation should make the secure path the easy one." They do not say who presses merge. They do say who should carry the burden.

CISA Secure by Design

The joint guidance from CISA, the NSA, the FBI and international partners, first released in April 2023 and updated in October 2023, sets out three principles for software manufacturers. The first is to take ownership of customer security outcomes. The guidance says plainly that the burden of security should not fall solely on the customer, and it criticises manufacturers that fix one vulnerability at a time instead of removing the root cause across the codebase.

That principle is written about manufacturers and their customers, but the same logic applies inside a company. Your product teams are the customer of your security programme. If the security programme sends them unresearched tickets, it is placing the burden on its customer. The guidance also recommends providing secure defaults for developers, which it calls "paved roads" or "well-lit paths", so the default route during development is the secure one. A pre-built fix pull request is a paved road for dependency remediation.

The guidance goes further on incentives. Under its third principle, lead from the top, it suggests weaving customer security into hiring, promotion and compensation, including counting security improvements in promotion criteria for developers alongside uptime, performance and features. If fixing a security finding counts for nothing in a performance review, no workflow change will fully fix the queue.

NIST SP 800-218, the Secure Software Development Framework

The SSDF (version 1.1, February 2022) gives you task level language you can cite in an internal policy.

• PO.2.1 asks organisations to create and maintain SDLC roles and responsibilities. One of its implementation examples is to designate a group of individuals or a team as the code owner for each project. That is the ownership routing rule in standards language.
• RV.2.1 asks you to analyse each vulnerability to gather enough information about risk to plan the response. Its first example is to use existing issue tracking software to record each vulnerability, and its second is to calculate risk from exploitability and potential impact. So the SSDF expects a record, and it expects the analysis to happen before remediation is planned.
• RV.2.2 asks you to plan and implement risk responses. Its examples include making a risk based decision on whether to remediate or address the risk another way, applying a temporary mitigation when no permanent fix exists, and noting that a single remediation could address multiple vulnerabilities. That last point is the case for batching.
• RV.3 asks you to find root causes and, under RV.3.3, to review the software for similar vulnerabilities and fix the class proactively rather than waiting for reports.

Read together, the SSDF says: record it, analyse it before you assign it, pick the right response, and fix classes rather than instances. None of that requires a developer to do the analysis.

NIST SP 800-40 Revision 4

NIST's enterprise patch management guide (April 2022) frames patching as preventive maintenance and a cost of doing business, the same way fleet maintenance is for a company that runs vehicles. It lists four risk responses: accept, mitigate, transfer and avoid. It notes that patching or upgrading is the only response that removes the vulnerability without removing functionality, and that immediate patching is sometimes not viable because no patch exists yet, the software is end of life, or testing has to happen first. That list is a useful checklist for when a pull request is the wrong tool.

OWASP SAMM Defect Management

OWASP SAMM v2 has a Defect Management practice in its Implementation function with two streams. Defect Tracking moves from structured tracking, to rating defects consistently across the organisation with SLAs per severity class, to enforcing those SLAs and integrating defect management with other tooling. Metrics and Feedback moves from basic metrics, to standardised metrics used for prioritisation, to continuous improvement.

OpenSSF Concise Guide for Developing More Secure Software

The OpenSSF Best Practices Working Group's guide (dated 14 June 2023 on the page, with later edits) tells developers to monitor known vulnerabilities in direct and indirect dependencies and to quickly update vulnerable dependencies. It also says to keep the test suite thorough enough to ship if it passes, and to keep dependencies reasonably current after a cooldown, which the current text describes as typically about three days for components without known vulnerabilities. Those two lines matter for automated fixes: a fix pull request is only as safe as the tests that run against it, and an upgrade with no security reason does not need to land the day it is released.

Deadlines and exploit signals

The current federal rule is CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," issued 10 June 2026. It revoked and superseded BOD 22-01, the 2021 directive that set fixed two-week deadlines for Known Exploited Vulnerabilities (KEV) catalog entries. BOD 26-04 applies to federal agency systems, not private companies, but it is the clearest public model for exploitation-driven deadlines: each timeline comes from public exposure, KEV status, whether exploitation can be automated, and partial or total control, and it shortens when a CVE joins KEV. Our post on BOD 26-04's four factors has the detail. Many private teams borrow KEV as a "fix this first" list and use the four factors to decide how fast "first" is for each repository.

FIRST's Exploit Prediction Scoring System (EPSS) publishes, daily for every CVE, the probability of exploitation in the wild in the next 30 days. It is a probability, not a verdict, but alongside KEV and reachability it helps decide which pull requests a team sees first.

Who should own a dependency finding, and how do you route it automatically

A dependency finding has a natural owner: the team that controls the file that declares the dependency. That sounds obvious, but in practice there are four cases to handle.

Case 1: a direct dependency in one repository

The vulnerable package is listed in the repository's own manifest. The owner is the team that owns that repository. This is the easy case, and it covers a large share of findings in most estates.

Case 2: a transitive dependency

The vulnerable package arrives through another package. The repository team still owns the lockfile, so they usually still own the fix, because most ecosystems let you resolve a transitive upgrade through an override or a refreshed lockfile. The exception is when the direct parent pins an exact vulnerable version. Then the fix is either to upgrade the parent or to wait for the parent's maintainer, and the finding needs a note saying which.

Case 3: a shared internal library or base image

The vulnerable package sits inside an internal library or a container base image that many services consume. If you route the finding to every consuming team, you get twenty tickets for one fix. Route it once, to the platform or library team that owns the shared component, and route a follow up to consumers only when the fixed version of the shared component is published.

Case 4: nobody owns it

Archived repositories, services whose team was reorganised, and one-off scripts end up with no owner. Every routing scheme needs a named fallback, usually the AppSec team or an engineering manager, so that "no owner" becomes a visible queue rather than a silent one.

How to route automatically

You need a mapping from code to team. The common sources, in rough order of reliability:

1. A code owners file in each repository. Many teams already keep one for review routing. It maps paths to teams, which means a finding in a specific manifest can go to the right team even in a monorepo.
2. A service catalogue that maps repositories and services to owning teams.
3. The repository's organisation or group in your source control system.
4. The ticketing project mapping, which maps a scanning scope to a project and a default assignee.

Pick one source of truth, keep it in version control, and audit it quarterly.

For more depth on the mapping itself, see how to auto-assign vulnerability tickets to the right team and build an alert ownership map.

What a fix request needs to contain for a developer to act on it in minutes

Whether it arrives as a ticket, a pull request, an editor warning or a chat message, a fix request a developer can act on quickly answers the questions they would otherwise have to research. Here is the minimum.

Two of those rows do most of the work. The change turns research into review. How to push back turns silent neglect into a recorded risk decision, which is what the SSDF's RV.2.2 and NIST SP 800-40's risk responses expect anyway.

When is a pull request a better unit of work than a ticket, and when is it not

A pull request is better when the fix is mechanical and the risk can be checked by tests. A ticket is better when the fix needs a decision.

The rule underneath the table: a pull request is a good unit of work when the reviewer can make a confident yes or no decision in one sitting. If the decision needs a meeting, it is a ticket.

The opposite failure is turning every finding into a pull request. Pull requests that need a design decision cannot merge, and they rot faster than tickets because they also go stale against the main branch.

How to keep automated fix pull requests from flooding teams

Automated fix pull requests solve the research burden and create a new risk: volume. A team that opens its repository on Monday to find forty pull requests will close most of them unread. These controls keep the flow at a rate teams can absorb.

1. Batch per repository

One pull request per repository that fixes several findings is easier to review than ten pull requests that each touch the same lockfile and conflict with each other. The SSDF's RV.2.2 notes that a single remediation can address multiple vulnerabilities; batching puts that into practice.

2. Fix reachable and exploited findings first

Order the queue by risk, not by severity alone. Reachable findings with a KEV listing or a high EPSS probability go first. Unreachable findings with a low exploit probability can wait for a scheduled maintenance batch, or be recorded and deferred.

3. Start with the safest upgrade strategy

Begin with backward-compatible upgrades only. Widen to minor versions once the team trusts the pull requests, and treat major version upgrades as drafts that need a human plan.

4. Pilot on one repository

Pick a repository with good tests and a willing team. Run automated fix pull requests there for a few weeks, measure acceptance and breakage, and fix the process before you widen it. The pilot automated fixes on one repo first post covers the pilot plan in detail.

5. Respect a cooldown, a budget and an expiry date

The OpenSSF guide suggests a short cooldown before adopting releases that do not fix a known vulnerability, so a fix tool should not double as a "chase every release" tool. Agree a weekly cap on automated pull requests with each team, highest priority first. Close and regenerate any fix pull request left unreviewed for two weeks, rather than letting it rot against the main branch.

6. Never auto-merge breaking changes

Even when automation is trusted for safe upgrades, a change flagged as a major or critical breaking risk needs a human decision. That rule should be written into settings, not left to habit.

The broader idea is a friction budget: every tool a developer has to look at costs attention. See the developer friction budget for supply chain tooling for a way to set one.

How Safeguard does this job, step by step

Here is the flow as Safeguard's docs describe it today. Every capability carries its maturity label from Safeguard's offering files. Where the docs do not show a screen or command, this section describes the outcome rather than inventing one. Ticketing integrations carry no separate label in the offering files, so treat them as early access until confirmed.

Step 1: Scan where the code lives

Safeguard's SCA and vulnerability management (GA) starts with a scan. Connect your repositories in the web app, or scan from a developer machine with the CLI. The CLI docs show the install and first scan:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# open the interactive terminal
safeguard

Inside the terminal, type /login to authenticate and /scan . to scan the folder you are in. The CLI docs say it builds an SBOM and matches it against vulnerability databases, and that it sends results, not source, to the platform. Findings then appear per project in the web app, under the project's Vulnerabilities and Findings tabs.

Step 2: Let prioritisation decide what developers see first

Safeguard's reachability analysis and prioritisation (GA, with some language support marked Preview in the docs) combines four signals: static, dynamic and configuration reachability; exploitability from EPSS and KEV; runtime context such as environment and internet exposure; and business context you declare by policy. Each finding gets a priority score from 0 to 100, and the docs say the weights are configurable per tenant under Settings, Prioritization.

The docs classify each vulnerability as reachable, conditionally reachable, unreachable or unknown, and they treat unknown conservatively as potentially reachable. Safeguard's docs say reachability filtering typically removes 60 to 80% of findings from the urgent queue. Treat that as Safeguard's stated figure, not a guaranteed result for your estate; your number depends on your languages and how your code uses its dependencies.

A team that receives reachable, exploitable findings first is far more likely to take the next pull request seriously.

Step 3: Route findings to owners

Safeguard's Findings view lets you assign one or more findings to a team member, with an optional note, and the assignee receives a notification. That covers manual routing.

For routing through your ticketing system, the Jira integration docs describe this setup:

1. In Jira Cloud, create an API token (or a personal access token on Jira Server or Data Center).
2. In Safeguard, go to Settings, Integrations, JIRA, click Connect JIRA, enter the Jira URL, email or username and token, then Test Connection and Save.
3. Click Configure Projects and, for each Safeguard organization, choose the target Jira project, the issue type and a default assignee.
4. Set trigger rules for automatic issue creation: new critical vulnerability, new high vulnerability, gate failure or policy violation.
5. Under Status Mapping, map statuses and enable bidirectional sync.

The docs describe sync in both directions. When a Jira issue moves to Done or Resolved, the finding is marked resolved; Won't Fix creates a mitigation recording risk acceptance. When a finding is resolved in Safeguard, the Jira issue transitions to Done. You can also create issues manually from the Findings tab or a vulnerability's detail view, in bulk, or link existing issues by key.

Two honest notes. First, the default assignee is set per organization to project mapping; fine-grained routing by path or code owner happens in your ticketing system's own automation rules, which the Jira docs show examples of. Second, the same Jira docs page carries a banner saying its /v1 REST endpoints are not yet available, so use the in-app flow, not the API examples on that page. The offering files also list Linear, Asana, Notion and Microsoft Planner; confirm the depth of each in a trial.

Step 4: Generate the fix pull request

This is where the ticket stops being research. Griffin fix pull requests are GA and part of autonomous remediation, which ships switched off with every category set to Manual. Safeguard's AI Remediate docs describe Griffin AI working through five stages: analysis of the vulnerability and your codebase, solution generation to pick the safest upgrade path, impact assessment for breaking changes and compatibility, pull request creation, and validation by running automated tests.

There are three ways to start it, all from the docs:

Single vulnerability.

1. Navigate to the vulnerability.
2. Click AI Remediate.
3. Review the proposed changes.
4. Click Create Pull Request.

Bulk.

1. Select the vulnerabilities to fix.
2. Click AI Remediate Selected.
3. Griffin batches compatible fixes.
4. Review all changes.
5. Create pull requests, one per repository.

Page level.

1. On the Vulnerabilities page, click the AI Remediate button at the top.
2. Griffin analyses all fixable vulnerabilities.
3. Review the remediation plan.
4. Approve and create pull requests.

The docs list what Griffin can change: upgrade vulnerable packages to fixed versions, handle transitive dependency conflicts, update lock files, and in some cases make configuration or code changes such as replacing deprecated calls. Supported ecosystems in the docs are JavaScript (npm, yarn, pnpm), Python (pip, poetry, pipenv), Java (Maven, Gradle), Go modules, Rust (Cargo), Ruby (Bundler), .NET (NuGet) and PHP (Composer).

Step 5: Review what the pull request tells you

According to the docs, each generated pull request includes a title with the CVE reference, a description of the vulnerability, a summary of the changes, breaking change warnings, test results when tests are configured, and links to the advisories. That maps closely to the fix request table earlier in this post.

The breaking change rating uses four levels:

The docs' own best practice list is short and sensible: enable tests, start with safe fixes, review major changes, do not auto-merge breaking changes, and track fix success rate.

Step 6: Decide how much runs on its own

Autonomous remediation ships switched off. Every category is set to Manual, and nothing is applied automatically until an administrator turns on the master toggle. The offering files describe eight remediation categories (vulnerabilities and dependencies among them), each set independently to Manual or Auto, with strategies for vulnerability and dependency fixes:

• Safest: backward-compatible fixes only.
• Balanced: minor version updates and patches, minimal breaking changes.
• Aggressive: all available fixes, including major versions.
• Smart: the model picks per item based on context, risk and impact.

The AI Remediate docs also list settings under Settings, AI Remediate: Auto-Create PRs, Require Approval, Test Integration, Breaking Change Policy and Branch Naming. A cautious rollout looks like this: keep everything on Manual, generate pull requests by hand for a pilot repository, turn on Require Approval and Test Integration, and only move the vulnerabilities category toward Auto with the Safest strategy once the team trusts the output. If you are writing fix pull requests into a purchase evaluation, see automatic fix pull requests as a buying requirement.

Step 7: Meet developers in the editor

Not every fix should wait for a pull request from the platform. Safeguard's IDE extensions (GA) put the same findings where the developer is typing. The docs list a VS Code extension, the same package on Open VSX for Cursor, and a separate JetBrains plugin. Install from the command line as the docs show:

code --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension
cursor --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension

Sign in with Safeguard: Login, which uses an OAuth device flow. The extension scans manifests on open and on save, and highlights vulnerable dependencies inline. In VS Code or Cursor, hover a flagged dependency, open the lightbulb menu and choose a fix, or run Safeguard: Fix All Vulnerabilities. In JetBrains IDEs, press Alt+Enter on a flagged dependency, choose Fix with Safeguard AI, pick a strategy and review the diff before applying.

The IDE strategies are Safe, Balanced (the default) and Aggressive, and you can set a default in settings:

{ "safeguard.remediationStrategy": "safe" }

One detail worth knowing: safeguard.autoFixOnSave is off by default, and the docs say to enable it with caution. The developer stays in control of when a change is applied.

Step 8: Fix from the terminal with approval

The CLI (GA) includes an assistant that can fix what the scan finds. In the interactive terminal, a developer can ask it to fix a specific finding. In the session shown in the demo below, the assistant reads the finding and the advisory, asks before any command that changes something, edits the manifest, runs the install and the tests with approval, prints a summary, and pushes nothing. The /permissions command chooses the approval mode. For CI, the docs list safeguard exec as the non-interactive form of the assistant.

This suits developers who prefer to fix locally and open the pull request themselves.

Step 9: Keep the fix from coming back

A finding fixed in March and reintroduced in April by an unrelated merge is the most demoralising kind of rework. Safeguard's policies and gates (GA) stop that. The policy outcomes docs describe three actions for a failed policy on a gate: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification to your configured channels. Approval of a specific failure goes through exceptions.

In CI, the docs show this command, which waits for the scan and the gate's policies and exits non-zero when the gate fails:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

The docs note that policy outcomes are turned on per workspace by Safeguard; if your workspace does not show an Outcome column on the Gates and Policies tables, ask your Safeguard contact. The --fail-on <severity> flag still works and can be combined with the gate flag. SAST findings are not part of --fail-on yet, and SAST itself is early access. For how to keep a record of every gate decision per release, see the sibling post prove every production release passed a security gate.

Step 10: Close the loop

When a pull request merges, the next scan sees the fixed version and the finding resolves; with Jira sync on, the docs say the issue moves to Done. The docs also describe a Jira issue closing triggering a project rescan, so a ticket closed without a merged fix shows up again.

How to measure progress

Count flow, not findings. A falling count of open findings can mean you are fixing things, or that you stopped scanning a repository. These measures are harder to fool.

Set baselines in the first month and compare against yourself. Safeguard's dashboard shows mean time to remediate trends per the offering files, and the findings report export includes resolution status and trends, which gives you the raw material for most of this table. Reopened findings and acceptance rate may need a small join between the findings export and your source control data.

One warning about incentives. If you reward teams for a falling open finding count, they will learn to suppress findings. Reward merged fixes and recorded, reviewed risk decisions instead.

Requirement vs what Safeguard does vs what you still own

What Safeguard does not do

Plan around these limits.

1. It does not merge for you by default, and it should not replace review. Autonomous remediation ships switched off with every category set to Manual. Even when an administrator turns it on, fix pull requests need human review and your own test suite. A green build on a repository with thin tests is not evidence that the change is safe.
2. It does not reorganise work in your ticketing system on its own. The Jira integration creates issues, maps a default assignee per project mapping and syncs status. Reassigning by code path, balancing load across engineers, or moving tickets between sprints is your ticketing system's automation and your managers' job.
3. It does not own your ownership map. Safeguard can route to an assignee you configure. It cannot tell you that a team was reorganised last month. Keep the code to team mapping current yourself.
4. Griffin's ecosystem coverage is listed, not universal. The AI Remediate docs list eight ecosystems. A finding in a language or package manager outside that list, or in a vendored copy of a library, needs a human fix. Reachability also has language limits, and the docs mark some language support as Preview.
5. It cannot fix what has no fix. When upstream has not shipped a fixed version, a pull request has nothing to upgrade to. The fork and patch flow described below is early access; confirm package coverage before relying on it. Otherwise the right response is a mitigation and a ticket.
6. It does not fix vendor products or hosted services. If the vulnerable code runs inside a product you buy rather than build, the fix comes from the vendor. Track it as a vendor risk, not a developer task.
7. SAST findings are outside this flow for now. SAST is early access, and it is not part of --fail-on yet. This post's workflow is about dependency findings.

Common mistakes

Filing one ticket per CVE per repository. Twenty tickets for one shared base image upgrade teach teams to ignore the queue. Route shared components once, to the owner of the shared component.

Turning on full automation on day one. Switching every category to Auto with an aggressive strategy across all repositories is the fastest way to lose developer trust. Start with Manual, one repository and the safest strategy.

Sending unreachable findings at the same priority as reachable ones. Developers notice quickly when half the urgent queue is code they never call. Once they notice, they discount the whole queue.

Letting "won't fix" be silent. A closed ticket with no reason is lost information. Make every non-fix a recorded mitigation or risk acceptance with an approver and a review date, as the SSDF's RV.2.2 and SP 800-40's risk responses expect.

FAQ

How do I get developers to actually fix security findings?

Do the research before the finding reaches them. Route it to the manifest's owner, rank it by reachability and exploit signals, and where a fixed version exists, send a pull request with the change, the breaking change risk and the test results.

Should security findings go in Jira or in pull requests?

Both, for different jobs. The ticket is the record, which the SSDF's RV.2.1 expects. The pull request is the work. When a fixed version exists and the change is mechanical, send the pull request and link it to the record. When no fix exists or the fix is a design change, the ticket carries the plan.

Who owns a vulnerable transitive dependency?

Usually the team that owns the lockfile, since most ecosystems allow an override or lockfile refresh. If the direct parent pins the vulnerable version, upgrade the parent or wait for its maintainer.

How many automated fix pull requests is too many?

There is no universal number. Agree a weekly budget per team, batch one pull request per repository, and watch acceptance rate; if it falls, you are over budget.

Are automated dependency fix pull requests safe to merge?

Only as safe as the review and the tests. Check the breaking change rating, read the changelog note for minor and major upgrades, and do not auto-merge major or critical changes. The OpenSSF guide's advice to keep tests thorough enough to ship if they pass is the precondition.

What does the SSDF say about vulnerability remediation?

Practice RV.2 asks you to analyse each vulnerability's risk, plan and implement risk responses, and notes a single remediation can address several vulnerabilities. PO.2.1 suggests designating a code owner for each project. RV.3 asks you to fix classes of vulnerabilities, not single instances.

Does Safeguard open fix pull requests automatically?

Safeguard's Griffin fix pull requests are GA. Autonomous remediation ships switched off with every category set to Manual, so pull requests are created when someone starts them, singly, in bulk or for a whole page, until an administrator enables automation per category.

Can developers fix findings without leaving their editor?

Yes, for dependency findings in supported ecosystems. Safeguard's IDE extensions (GA) for VS Code, Cursor and JetBrains IDEs flag vulnerable dependencies inline and offer a fix with a Safe, Balanced or Aggressive strategy, which the developer reviews before applying.

Try it on your own repositories

Judge it on one repository with good tests. Install the desktop app or CLI from safeguard.sh/download, and read the setup guides in the Safeguard docs.

When the fix is a version bump, or when there is no fix yet

Everything above assumes a fixed version exists for a developer to review. The block below covers both that case and the harder one, where upstream has no fix, and it is the same remediation path the fix pull requests in this post come from.

Fix it without waiting for upstream

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

1. Autonomous remediation: pull requests, not tickets

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

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

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

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

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

See how Safeguard would help

The first demo is a real CLI session. After installing, the developer runs safeguard to open the interactive terminal and asks it to fix the lodash CVE in the repository. The assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing; the session then shows /permissions, /model and /scan. That is the fix request from this post, delivered as a reviewable change on the developer's own machine.

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

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude can use. For teams whose developers already work through an AI assistant, this is one more place a finding can arrive with its context, without anyone filing a ticket first.

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

Quick check

Sources

• CISA and partners: Secure by Design, Shifting the Balance of Cybersecurity Risk (October 2023 update, PDF)
• CISA: Secure by Design resource page
• CISA: Secure by Design Pledge
• NIST SP 800-218, Secure Software Development Framework v1.1 (PDF)
• NIST CSRC: SP 800-218 publication page
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (PDF)
• NIST CSRC: SP 800-40 Rev. 4 publication page
• OWASP SAMM: Defect Management
• OpenSSF: Concise Guide for Developing More Secure Software
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 22-01 (revoked)
• FIRST: Exploit Prediction Scoring System
• Safeguard docs: AI Remediate
• Safeguard docs: JIRA Integration
• Safeguard docs: Findings
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: IDE Support
• Safeguard docs: Safeguard CLI
• Safeguard docs: CLI slash commands

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