One findings queue: dedupe, rank and route security findings

You get one queue by making every scanner write into the same findings model, collapsing duplicates across scanners, ranking what is left by exploitation evidence and reachability, and routing each finding to a named owner. In Safeguard that is Unified Findings, AutoTriage, the prioritization engine and team ownership, with unknown-reachability findings never suppressed.

This post is for the head of AppSec or platform owner consolidating several scanners, and the security engineering manager who triages every morning. It covers how each piece works according to Safeguard's documentation, what the noise reduction does and does not hide, how findings reach gates, Jira and pull requests, and a staged pilot rollout.

Key takeaways

• One model, not five inboxes. Every first-party engine reports into one unified findings model, discriminated by a finding_type field and browsed from one Findings tab per project with a Scanner filter. SCA keeps its own Vulnerabilities tab so the same data is not shown twice.
• Engines switch on one at a time. Each engine has its own per-engine setting, enforced on the server, so you can roll out SAST without DAST, or DAST without Red Team, and stage the rollout by tenant.
• AutoTriage collapses duplicates. When more than one engine reports the same underlying issue, AutoTriage merges them into one correlated finding, down-ranks or merges low-signal findings, and reports how much volume it removed so the effect can be audited.
• A clear floor. Findings the analyzer cannot decide on are treated as potentially reachable, never suppressed. Unreachable CVE findings drop to the backlog rather than disappearing, and duplicates are merged into one record.
• Ranking uses evidence, not just severity. CISA KEV (has it been exploited), FIRST EPSS (how likely is exploitation in the next 30 days), reachability (does our code call it), runtime confirmation (does it actually load) and business context feed one 0 to 100 priority score, with weights you can tune per tenant.
• Ownership is structural. Organization, team, project and asset carry ownership. Roles scope who sees and triages what. Assignment, bulk actions, Jira sync and gates move findings to the people who fix them.
• Roll out in stages. Start with two scanners, compare the deduplicated view against the raw ones, add engines, then turn on gates.

Why does every scanner end up with its own inbox?

Most security programs did not plan to run five scanners. They added them one at a time: dependency scanning for the SBOM requirement, static analysis for first-party code, dynamic testing for the running application, container scanning when workloads moved to Kubernetes, and infrastructure as code checks when the platform team adopted Terraform. Each tool arrived with its own console, severity scale, idea of what a "finding" is, and export.

The result is predictable. A vulnerable library version shows up in the dependency scan of the repository, again in the container scan of the image built from it, and a third time when static analysis flags the code that calls the vulnerable function. Each copy has a different identifier and often a different severity. The engineer fixes the problem once and closes the other two tickets by hand, or does not, and the backlog grows.

The deeper cost is not duplication. It is that nobody can answer the questions a security lead is actually asked:

1. Which of these findings are the same problem?
2. Which of them are being exploited right now, and which are likely to be?
3. Does our code even reach the vulnerable part?
4. Who owns the service, and have they seen it?
5. If we gate a release on this, will the gate fire on noise and get bypassed?

A consolidated queue has to answer all five without quietly dropping the findings that matter. Any tool that "reduces noise" decides what you will not see, so the question to ask any vendor, Safeguard included, is what the reduction is allowed to hide and how you can check it.

How does Safeguard store findings from different scanners in one place?

Safeguard's documentation describes a single findings model for all of its engines. Rather than each engine carrying a siloed inbox, every engine writes into one model, and a finding_type field says which engine produced a given row. That one decision is what makes cross-engine filtering, correlation and deduplication possible: the rows already share a shape and share correlation keys.

The types most relevant to a team consolidating application security tools are these:

The model has more types than this table shows; this post sticks to the engines that ship today. Every finding is also scoped to a tenant and organization from end to end, so a parent organization can see rolled-up findings from its child organizations without business units seeing each other's data.

The Findings tab and the Scanner filter

A project has one Findings tab. At the top is a compact Scanner dropdown. "All scanners" is the default and shows every finding type together. Choosing a single scanner narrows the table, the summary statistics and the underlying queries to that engine's finding_type. It is the same tab, just scoped.

Two practical details from the docs are worth knowing on day one:

• Deep links. The project Info page has a Scanner Coverage section with one card per scanner, each showing a live finding count. Clicking a card opens the Findings tab with that scanner preselected through a ?scanner= query parameter. The short value in that parameter does not always match the finding_type: AI Security uses ai-security, and Package Firewall uses package-firewall. A value that does not match a known scanner falls back to "All scanners" without an error, so if you build links by hand for a runbook or a dashboard, copy the value the dropdown uses.
• Two surfaces on one tab. Below the findings table sits the Application Security panel, a card with one sub-tab per first-party engine. The dropdown is gated by permission. The panel is gated by per-engine settings. More on that next.

Per-engine settings: switch engines on one at a time

Each engine has its own setting, named scanner:<key> (for example scanner:sast, scanner:dast, scanner:redteam, scanner:aisec, scanner:runtime). The documentation stresses two properties:

• Server-side enforcement. A disabled engine is genuinely off. It stops running and stops returning data; it is not just hidden in the interface.
• Independent control. You can enable SAST and DAST without Red Team, or run AI-SPM without Runtime. Each engine is its own switch.

One subtlety: in the current interface the flags control the Application Security panel's sub-tabs, not the main Scanner dropdown or the Scanner Coverage cards. Turn scanner:dast off and the DAST sub-tab leaves the panel, but DAST can still appear in the dropdown. That is documented behavior, not a flag that failed to apply.

For a rollout, the flags let you bring one engine into the shared queue, check how its findings behave, and only then add the next. AutoTriage has its own flag too, so deduplication can be switched on after you have looked at the raw data.

Correlation keys: one issue seen from several angles

Because every engine writes the same model, findings share correlation keys. In the documentation's example, a DAST-confirmed issue in the running application can be linked to the SAST source-code sink that produced it, and to the cloud-native correlation showing the workload is running, reachable and exposed. The confirmed, reachable, exploitable issue is then prioritized as one thing across engines, instead of three tickets with three different severities.

Deduplication needs those shared keys, ranking needs every engine's signals in one place, and ownership needs one record to assign, not three.

What does AutoTriage do to the queue?

AutoTriage is Safeguard's cross-scanner deduplication and noise reduction step. It runs over the unified findings model, so it can correlate findings from static and dynamic testing, red team, AI security, runtime and dependency (SCA) engines. The documentation describes three behaviors:

1. Cross-scanner deduplication. When more than one engine reports the same underlying issue, for example SAST and SCA pointing at the same component, AutoTriage collapses them into a single correlated finding.
2. Noise reduction. Low-signal and redundant findings are down-ranked or merged.
3. A reduction metric. AutoTriage reports a reduction percentage, meaning how much finding volume it removed, so the reduction is measurable and auditable rather than opaque.

AutoTriage is controlled by its own setting, enforced on the server.

The floor under the queue, and why it is the deciding question

The AutoTriage page describes cross-scanner deduplication and noise reduction with a measured reduction metric. Two other docs pages complete the floor under the queue:

• The runtime protection page says reachability re-ranks CVE and SCA findings using runtime evidence.
• The reachability page says that when the reachability analyzer cannot decide, for example because of reflection, dynamic dispatch or native code, the finding is classified as unknown and treated conservatively as potentially reachable, not hidden.

That gives a security lead a precise answer to "what does the noise reduction hide". Duplicates are merged into one record. Low-signal findings are down-ranked or merged. Unreachable CVE findings drop to the backlog band of the priority score, and the docs note they can be auto-suppressed in some views. Undecidable reachability is never treated as safe.

What "down-ranked" means for your process

Down-ranking is not deletion, but it has the same effect if your process only looks at the top of the list. Two habits keep it honest. Record the reduction metric per project during the pilot, and if it moves sharply after an engine or configuration change, find out why. And once a sprint, sample a handful of down-ranked and merged findings by hand; if any belonged near the top, adjust the weights or the policy and write down why.

Do not expect a reduction figure to transfer between organizations. The effect depends on how many engines overlap on your code, how your repositories are structured and how much of your dependency tree your application calls. Measure it on your own projects during evaluation.

How are findings ranked: which signals, and what does each answer?

Deduplication tells you which findings are the same. Ranking tells you which to fix first. Safeguard's prioritization documentation combines four groups of signals into one ranked backlog: reachability, exploitability (EPSS and KEV), runtime context and business context. Each answers a different question, and it helps to keep them separate in your head before you see them blended into a score.

KEV: a record of history

CISA describes the KEV catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and says organizations should use it as an input to their vulnerability management prioritization framework. A vulnerability enters the catalog when it meets three criteria: it has a CVE ID, there is reliable evidence of active exploitation, and there is a clear remediation action such as a vendor update.

CISA separates "exploitable" from "exploited". A public proof of concept, scanning or security research does not count; KEV needs evidence that an actor attempted or achieved exploitation in the wild. The catalog is published in CSV and JSON, which is why tools can ingest it continuously. CISA's page now references Binding Operational Directive 26-04, issued on 10 June 2026, which carries the KEV criteria forward from the earlier BOD 22-01 and sets remediation timeframes for federal civilian agencies. CISA strongly recommends every other organization prioritize KEV entries too.

EPSS: a forecast

FIRST's Exploit Prediction Scoring System is a data-driven model that estimates the probability that a published CVE will see exploitation activity in the wild in the next 30 days. It publishes a probability between 0 and 1, plus a percentile, for every scored CVE every day, free through CSV and an API. Safeguard's prioritization page says it ingests the daily EPSS feed.

FIRST's own guidance contains four points that should shape how you configure any ranking that uses EPSS:

• EPSS is not a risk score. It provides the threat likelihood component only. It does not estimate impact, does not know what assets you run and does not account for compensating controls.
• Probability and percentile are different. The probability is absolute; the percentile ranks a CVE against all others. Because most CVEs are never exploited, scores cluster near zero, and a probability that looks small can sit high in the percentile ranking.
• There is no universal threshold. FIRST warns that intuitive cutoffs such as 50% are far too high given the low base rate of exploitation, and recommends choosing a threshold against your remediation capacity using its coverage, effort and efficiency framework.
• When KEV and EPSS disagree, follow KEV. A low EPSS score on a KEV-listed vulnerability is not a contradiction. KEV records exploitation that happened; EPSS forecasts. FIRST's rule of thumb is to treat a KEV-listed vulnerability as actively exploited regardless of its EPSS score.

FIRST also warns against multiplying EPSS by a CVSS score, because one is a calibrated probability and the other is an ordinal ranking, and the product has no interpretable meaning. That is a useful test for any ranking you inherit: if someone built "risk = CVSS times EPSS" into a spreadsheet, replace it.

Reachability: does your code call it?

Safeguard's documentation describes three kinds of reachability analysis:

• Static reachability builds a call graph from your source, lockfile and bytecode and checks whether any path leads to the vulnerable sink.
• Dynamic reachability uses what the runtime collector records about which modules and functions are actually loaded and invoked in production workloads, and marks never-executed vulnerable paths as cold.
• Configuration reachability parses framework configuration, such as Spring bean definitions or Next.js route files, to see whether code is wired in at all.

Each vulnerability is classified as reachable (a real call path exists and is instantiated at runtime), conditionally reachable (a path exists but needs a feature flag, route or configuration that is not currently enabled), unreachable (no call path exists in your compiled code) or unknown (the analyzer could not decide, so it is treated as potentially reachable).

The documentation is candid about where reachability is weak: code that runs through reflection, eval or unsafe dispatch (marked unknown and not suppressed), data-driven vulnerabilities that do not need a call path, and paths that only run under configurations the analyzer cannot enumerate. For those, the docs say to rely on KEV, EPSS, runtime observation and conservative defaults. Analysis depth also varies by language, so check your main languages against the support table in the docs during the pilot.

How much of your backlog turns out to be unreachable depends on your codebase and how it uses its dependencies, so measure it on your own repositories rather than assuming a figure. For a primer on the technique, see what reachability analysis is and whether you need it.

Runtime confirmation: does it actually load?

Runtime confirmation is the strongest reachability evidence because it is observed, not inferred. The runtime protection documentation says that from library-load events, the engine records which packages actually load and which functions execute per workload, and feeds that to AutoTriage. A statically reachable CVE is upgraded to runtime-confirmed and moves up. A package that never loads is demoted and moves down. Again, this re-ranks CVE and SCA findings.

Runtime confirmation depends on library-load events reaching the engine from your workloads, so it only applies where that collection is in place. Confirm with Safeguard which of your platforms it covers before you plan your ranking around it. Where it is not in place, static and configuration reachability still apply, along with KEV and EPSS.

Runtime and business context: where is it, and what is at stake?

Assets carry labels for environment, exposure (internet-facing, internal, air-gapped), data class and criticality, and policy can declare which assets are regulated or on the revenue path. Findings on those assets rank higher.

The priority score

Each finding gets a priority score from 0 to 100, computed from base severity (CVSS), EPSS probability, KEV listing, public exploit availability, reachability class, environment, exposure, data sensitivity and business criticality. The documentation says the exact weights are configurable per tenant under Settings, Prioritization, and that the defaults follow the intuitive order: reachable, KEV-listed findings in production land in the top band (P0); reachable findings with a high EPSS probability in production come next (P1); reachable findings with a high CVSS score in staging come after that (P2); unreachable findings of any severity go to the backlog band.

Treat the defaults as a starting point. Per FIRST, the right EPSS weighting depends on how much your team can remediate each week, so tune it during the pilot and record why.

Worked examples

These are illustrative findings, not customer data, to show how the signals combine.

Example 1: a KEV-listed library flaw in a production service. SCA reports a vulnerable version of a widely used parsing library in the payments-api repository. The same component also appears in the container scan of the image built from that repository. AutoTriage collapses the two reports into one correlated finding. The CVE is on CISA KEV. Static analysis finds a call path from the service's request handler into the vulnerable function, so it is reachable. The asset is labeled production and internet-facing. All the evidence points the same way, and it lands in the top band. This is the finding you want a fix pull request for today.

Example 2: a critical CVSS score that does not matter yet. A build tool used only in a development container carries a CVE with a critical CVSS base score, a low EPSS probability and no KEV listing. Static reachability says your code never calls the vulnerable function. It drops to the backlog band but does not disappear, and a policy can still require it fixed before the next major upgrade.

Example 3: a SAST finding confirmed by DAST. Static analysis flags user input reaching an unparameterized database query in an order-search endpoint, and a DAST scan of the verified staging target confirms it on the matching route. Shared correlation keys link the two, so they are prioritized as one confirmed issue.

Example 4: a finding the analyzer cannot decide. A Java service loads a plugin through reflection, and the plugin depends on a library with a known CVE. The analyzer cannot resolve the call path, so the finding is classified as unknown and treated as potentially reachable. It stays visible with its EPSS and KEV signals, and moves up if it later shows as runtime-confirmed.

Who owns a finding, and how does it reach them?

A ranked queue that nobody owns is still a backlog. Safeguard's documentation puts ownership into the structure of the account rather than leaving it to ticket fields.

Ownership is part of the hierarchy

The RBAC documentation describes the hierarchy as organization, then team, then project, then asset. The organization is the top-level boundary where billing, SSO, the audit log and compliance configuration live. A team is a group of users with shared access. A project is a unit of ownership inside a team, often one per service or repository. Assets, meaning repositories, images, SBOMs, vendors and workloads, are assigned to a project. A user can belong to several teams with a different role in each.

That gives every finding a natural owner: the team that owns the project the affected asset belongs to. The docs also note that asset criticality can be inferred from ownership and business tags, so ownership feeds the ranking as well as the routing.

Roles decide who sees and triages what

The built-in roles map cleanly onto a triage process:

Custom roles are built from a permissions matrix that includes findings:read and findings:triage, with restrictions such as environment and maximum severity. Permissions can also be sliced by asset labels, for example a Security Engineer scoped to team: payments in production and staging, so each embedded security engineer sees only the services they support.

Assignment, status and bulk actions

The ESSCM findings documentation lists the actions available on a finding: resolve, mitigate, suppress, assign and export. The status workflow runs from Open to In Progress to Resolved, with Mitigated and Suppressed as side exits. Assigning a finding notifies the assignee, and you can add a note. Bulk actions let you change status, assign to a user, add findings to a sprint or ticket, export the selection or mitigate in bulk.

On the Vulnerabilities tab, Mark False Positive (with a justification, approved when policy requires) and Accept Risk (with an expiration date) leave an audit trail. Prefer them to plain suppression: an expiring risk acceptance comes back on its own, and a suppression without a reason does not.

Routing into the tools engineers already use

Engineers fix what lands in their own tracker. The findings documentation lists issue tracker integrations for Jira, GitHub Issues, Azure DevOps and ServiceNow.

The Jira integration connects Safeguard to one Jira Cloud project with an Atlassian API token. Safeguard creates issues for the findings you send, updates them, and moves them through your workflow using a status mapping you define (new, in progress, under review, completed). It checks its issues every few minutes, so an engineer's status change in Jira flows back. It never deletes issues, projects or users, and the docs list the exact permissions and token scopes it needs for a least-privilege service account.

Notifications cover the rest. Alert rules can trigger on a new critical finding, a new high finding, a count above a threshold or a gate failure, and gate policies set to Notify send to the in-app bell, connected chat integrations and email according to each person's preferences.

How do findings drive gates and pull requests?

Findings become enforceable when policies evaluate them and gates act on the result. The relationship is documented clearly. Policies are rules that evaluate your SBOMs and generate findings. Gates are checkpoints that enforce policies. Each policy has one Action that decides what a failed policy does to the gate:

The policy outcomes page adds two rules worth knowing: an Error is never counted as a pass, and a gate that has never been evaluated shows Not evaluated, never Passed. Policy outcomes are turned on per workspace by Safeguard, so ask for it if you do not see an Outcome column yet.

Write the policy against the ranked signals, not raw severity

The guardrails documentation describes a YAML policy language whose rules evaluate against a document that combines SBOM, vulnerability, license, signature, provenance and reachability data, with effects of BLOCK, WARN or AUTO_FIX. That means you can gate on the same evidence the queue is ranked by. A policy in the documented shape that blocks reachable, KEV-listed vulnerabilities in production, and only warns on the rest of the criticals, looks like this:

apiVersion: safeguard.sh/v1
kind: Policy
metadata:
  name: block-reachable-kev-in-production
spec:
  targets:
    - kind: Image
      labels:
        env: production
  rules:
    - id: no-reachable-kev
      description: Block production releases with a reachable, KEV-listed CVE.
      condition: |
        any(
          vulnerabilities,
          kev == true
          AND reachability_class in ["reachable", "conditional", "unknown"]
        )
      effect: BLOCK
      exception:
        allowed: true
        approvers: ["appsec-leads@example.com"]
    - id: warn-on-critical
      description: Warn on any other critical CVE so owners see it before release.
      condition: |
        any(vulnerabilities, severity == "critical")
      effect: WARN

Including unknown in the blocking condition follows the documentation's own conservative stance: if the analyzer cannot decide, do not treat the finding as safe. The guardrails page also documents time-boxed exceptions that an approver with the right role can grant per asset, which appear in the audit log and expire automatically.

Failing a CI job on a gate

Gates are evaluated by the platform on the scans it runs for your connected repositories. The CLI's plain scan command exits 0 whenever the scan ran, whatever it found, because gating is done by policy gates in the platform. With policy outcomes on for your workspace, the documented way to make a CI job wait for the gate is safeguard ci scan with --wait and --fail-on-gate, covered in the walkthrough below. It exits 0 when the gate is Passed or Warning, and non-zero when the gate is Failed, Error or Not evaluated, or when its policies were not evaluated before the timeout. For how the different checkpoints fit together, see policies vs gates vs guardrails in Safeguard and stopping vulnerable dependencies at five checkpoints.

Pull requests: review and fix

Two features bring the queue into the pull request.

PR Guard is Safeguard's AI code review for pull requests. It analyzes the diff and returns a scored summary and comments tied to a file and line, categorized by severity and type, optionally with a suggested fix, shown in Safeguard and, with Post to GitHub, on the pull request itself. It is currently wired to GitHub. The live post on gating a pull request with PR Guard walks through it, and AutoTriage and PR Guard against alert fatigue covers how the two work together.

Autonomous remediation turns ranked findings into fix pull requests. From the Vulnerabilities page, AI Remediate generates remediation plans for review and creates pull requests. The prioritization docs say Griffin, Safeguard's security model, can propose a minimum-risk upgrade, explain why a finding was de-prioritized (useful in exception reviews) and open pull requests for the top priorities on a schedule. Autonomous remediation ships switched off, with each category set to Manual, so your team decides how much runs unattended.

Step by step: build the queue in a pilot

This walkthrough uses one pilot team and two or three services. It assumes repositories are connected to Safeguard through a source code integration, which is how the platform runs scans and evaluates gates.

Step 1: install the CLI and scan locally

The CLI lets a developer see the same dependency findings locally before anything is gated:

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

# Windows (PowerShell)
irm https://cli.safeguard.sh/install.ps1 | iex

# Open the interactive terminal, then type /login and /scan .
safeguard

Scanning from the interactive terminal while signed in uploads the SBOM and findings to the platform, never your source, so the project appears alongside your other projects. For a one-off local scan that writes JSON results to disk:

# A local directory
safeguard scan --dir .

# A container image built from the same service
safeguard scan --image myregistry.example.com/payments-api:1.42.0 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"

# An SBOM you already have (SPDX or CycloneDX)
safeguard scan --sbom sbom.cdx.json

# Results are written as JSON under ./output, one folder per scan
ls output/

Running the directory scan and the image scan for the same service is a simple way to see the overlap AutoTriage is designed to collapse: many of the same components appear in both.

Step 2: turn on two engines for the pilot tenant

Start with dependency scanning and one other engine, usually SAST. Ask your Safeguard administrator to enable scanner:sast for the pilot, and leave the other engines and AutoTriage off for the first scans.

Step 3: record the raw view

For each pilot project, export the Vulnerabilities tab (SCA) and the Findings tab filtered to SAST. That is your baseline before any deduplication or ranking.

Step 4: turn on AutoTriage and compare

Turn on the AutoTriage setting, let the next scans run, and compare the deduplicated Findings view against your baseline exports. You are checking three things:

1. Each merged finding really is one underlying issue.
2. Every unknown-reachability finding is still visible (they are treated as potentially reachable; verify it on your own data).
3. The down-ranked findings you sample by hand deserve to be down-ranked.

Record the reduction metric AutoTriage reports for each project; that is your evaluation number.

Step 5: tune the ranking

Open Settings, Prioritization and review the weights against your pilot findings. Check that KEV-listed findings sit at the top regardless of EPSS, that your EPSS weighting matches how much the team can fix each week, and that production and internet-facing labels are on the right assets. Use the Vulnerabilities tab's Priority and Reachability columns, which default to sorting by priority, to sanity-check the order with the service owners.

You can also ask in plain language. The docs show Griffin answering questions such as which of last week's new CVEs are reachable but not yet on KEV, or summarizing the top priorities for one service. The live post on turning findings into a ranked, batched fix list in Claude shows the same idea from an assistant.

Step 6: set ownership and routing

Create a team for each pilot service owner, put each service's project under the right team, and give the embedded engineers the Security Engineer or Developer role scoped to that team. Then connect Jira:

1. In Atlassian, create an API token for a dedicated account with Browse projects, Create issues, Edit issues and Transition issues on the one target project (or a scoped token with read:jira-user, read:jira-work and write:jira-work).
2. In Safeguard, open Integrations, choose the Notification tab and click Connect on the Jira card.
3. Enter your Atlassian Cloud site URL, the token and the account email, and optionally a default assignee.
4. Choose the project and map Safeguard's states to your Jira statuses.

You can check the token the same way Safeguard does before you paste it in:

curl -s -u 'svc-safeguard@example.com:<api-token>' \
  https://your-site.atlassian.net/rest/api/3/myself

Step 7: add the remaining engines one at a time

Turn on DAST for a verified staging target, then container and IaC scanning, repeating steps 3 and 4 after each so any surprise is traceable to its cause.

Step 8: gate, starting with Warn

Create policies in Warn or Notify first so the gate reports without blocking. Once owners trust the ranking, switch the policies that matter to Block, and make the CI job wait for the gate:

# Waits for the scan and for the gate's policies to be evaluated on the new data.
# Exits 0 on Passed or Warning; non-zero on Failed, Error or Not evaluated.
safeguard ci scan --wait --fail-on-gate "production-release"

Set up the CI token as described in Safeguard's CI/CD integration documentation. Keep the gate's exceptions time-boxed and owned by a named approver.

A staged rollout plan

For the operating model a single queue makes possible, see running AppSec at one security engineer per hundred developers. For how products, projects, SBOMs and findings relate, see how Safeguard data is structured and how to count vulnerabilities correctly.

What it will not do, and where the edges are

An honest evaluation lists the limits too. These all come from Safeguard's own documentation:

• No CLI query for the unified view yet. The Unified Findings page says there is no CLI command for filtering the consolidated findings. Use the web app, an assistant connected through the MCP server, or exports.
• Do not build on the documented REST paths yet. Several docs pages show /v1 REST endpoints with a banner saying they are not yet available.
• Some filters show empty tables. A few scanner filter options exist in the model for engines that have not shipped. An empty table there is expected.
• PR Guard is GitHub-wired. Other providers show a notice and review actions are disabled.
• Jira Cloud only. Jira Data Center is not supported yet, and Atlassian tokens expire, which stops sync until you replace them.
• Policy outcomes are per workspace. Gate outcomes and the CI --fail-on-gate behavior need policy outcomes turned on for your workspace.
• Reachability and runtime confirmation have limits. The blind spots above leave some noise, and runtime confirmation applies only where library-load events reach the engine.

Common mistakes

Turning on every engine at once. You lose the ability to tell which engine produced a surprise. Add one at a time and compare raw against deduplicated each time.

Trusting a reduction number you did not measure. Any noise reduction figure from a vendor, a peer or a blog post describes someone else's code. Record AutoTriage's reduction metric on your own projects and sample the bottom of the queue.

Ranking by CVSS alone. FIRST's guidance is direct that CVSS and EPSS measure different things and that multiplying them is meaningless. Use exploitation evidence and reachability alongside severity.

Letting EPSS outvote KEV. A KEV listing is evidence that exploitation happened. Keep KEV-listed findings at the top even when EPSS is low.

Suppressing instead of accepting risk. A suppression without a reason and an expiry is invisible debt. Use Mark False Positive with a justification, or Accept Risk with an expiration date.

Gating on Block from day one. A gate that fires on noise gets bypassed. Start in Warn or Notify, fix the ranking, then switch the conditions that matter to Block.

Routing to a shared inbox. A finding without a named owner is not triaged. Put projects under teams, scope roles and set a default assignee in Jira.

Forgetting that SCA lives on its own tab. Dependency vulnerabilities are on the Vulnerabilities tab, not in the Findings scanner filter. Reviewing only the Findings tab misses them.

FAQ

How do I deduplicate findings from SAST, SCA and DAST in one place?

Put them in one findings model so they share correlation keys, then let a cross-scanner deduplication step merge reports of the same underlying issue. In Safeguard, every engine writes to the unified findings model and AutoTriage collapses duplicates into one correlated finding, for example SAST and SCA pointing at the same component.

Does AutoTriage hide real vulnerabilities?

It merges duplicates and down-ranks or merges low-signal findings, and it reports how much volume it removed so you can audit the effect. Unreachable CVE findings drop to the backlog band and may be hidden in some views, so sample them during the pilot.

How much noise does reachability analysis remove?

It depends on your codebase. How much of a dependency tree an application actually calls varies widely between services and languages. Measure it on your own repositories during evaluation rather than relying on any published average.

What is the difference between CISA KEV and EPSS?

KEV is a record of vulnerabilities with reliable evidence of exploitation in the wild. EPSS is FIRST's daily forecast of the probability of exploitation activity in the next 30 days. FIRST's guidance is that when a vulnerability is on KEV, you treat it as actively exploited regardless of its EPSS score.

Can I change how Safeguard weights KEV, EPSS and reachability?

Yes. The documentation says the priority score weights are configurable per tenant under Settings, Prioritization. The defaults put reachable, KEV-listed, production findings at the top and unreachable findings in the backlog band.

Can I roll out one scanner at a time?

Yes. Each engine has its own server-enforced setting, and AutoTriage has its own setting. You can enable SAST without DAST, add engines later, and switch deduplication on after you have reviewed the raw data.

How do findings get to the right team?

Ownership follows the hierarchy: organization, team, project, asset. Put each service's project under the owning team, scope roles to that team or to asset labels, assign findings (the assignee is notified) and sync them to Jira with a status mapping.

Can a CI pipeline fail on Safeguard findings?

Gates are evaluated in the platform. The plain scan command does not fail on findings. With policy outcomes on for your workspace, safeguard ci scan --wait --fail-on-gate makes the job wait for the gate and exit non-zero when it fails, errors or was not evaluated.

Why the fix still matters after the queue is clean

A ranked queue tells you what to fix first, but it does not fix anything. The findings at its top are usually open source dependencies and base images with a known vulnerable version, so the work that follows is upgrading a package, rebuilding an image or waiting on a maintainer.

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

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, 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

These demos show the surfaces where a ranked queue turns into work: an assistant reading findings, a developer fixing the top one, and a scan run on your own machine.

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once findings are in one queue, this is how a security engineer asks an assistant what to fix first across projects without opening each scanner's console.

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

The second demo is a real Safeguard CLI session. A developer asks the assistant to fix a lodash CVE; it reads the finding and advisory, asks before any command that changes something, updates the dependency, runs the install and tests with approval, prints a summary and pushes nothing. It is what happens to a top-band finding after it has been assigned to its owner.

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

The third demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. In a pilot, it lets a team produce the baseline scans for the raw-versus-deduplicated comparison without granting repository access first.

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

To try Safeguard yourself, download the apps or start with the CLI documentation.

Quick check

Sources

• Safeguard docs: Unified Findings
• Safeguard docs: AutoTriage
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: ESSCM Findings
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: Runtime Protection (CWPP and CNAPP)
• Safeguard docs: Guardrails and Enforcement
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: PR Guard
• Safeguard docs: RBAC, Teams and Organizations
• Safeguard docs: Jira integration
• Safeguard docs: Safeguard CLI
• Safeguard docs: CLI usage guide
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: EPSS Frequently Asked Questions
• FIRST: Using EPSS

Last reviewed: 26 October 2026.