How do you ask why a finding is reachable from the Chrome side panel?

Open the Safeguard Chrome extension, sign in on the side panel, and ask Griffin in plain language why a specific finding is reachable. The panel loads the same search page as the web app, so the answer uses your own workspace data, and you stay on the page you were reading.

What is the Chrome extension, exactly?

According to Safeguard's documentation, the extension embeds Safeguard's AI search in a browser side panel. It loads app.safeguard.sh/portal/search and nothing else. You sign in inside that page with your normal web session, and the extension does not store credentials or call Safeguard APIs itself. On Chrome it asks only for the sidePanel permission, and the docs list Chrome 114 or newer as the version to use.

It is listed on the Chrome Web Store as Safeguard. A separate extension, Gold Open Source, does package lookups.

What does reachable mean here?

Reachability asks whether your code actually calls the vulnerable function or triggers the vulnerable path. The documentation describes three methods: static analysis from a call graph, a dynamic runtime collector, and configuration parsing for framework wiring such as Spring beans or Next.js routes.

Each finding falls in one of four classes:

• Reachable. A real call path exists and is instantiated at runtime.
• Conditionally reachable. A path exists but needs a flag, route or configuration that is not currently on.
• Unreachable. No call path exists in your compiled code.
• Unknown. The analyzer could not decide, for example with reflection or native code. These are treated as potentially reachable and are not hidden.

Reachability is one input to a 0 to 100 priority score, alongside CVSS, EPSS, KEV, proof of concept availability, environment, exposure, data sensitivity and business criticality.

How do you ask from the side panel?

1. Install the Safeguard extension from the Chrome Web Store.
2. Pin it if needed, then click the toolbar icon titled Open Safeguard.
3. Sign in on the panel's login page.
4. Type the question into the search box, using the finding's package and CVE.
5. Read the answer, then open the finding in the web app if you want the full call path or want to change a priority setting.

Prompts that fit the documented pattern look like these:

• "Show my P0 findings in production that are reachable."
• "Which of last week's new CVEs are reachable but not yet on KEV?"
• "Explain why this finding was de-prioritized."

The documentation says Griffin can explain why a finding was de-prioritized, which it describes as useful for exception reviews.

When is the side panel the right place?

It is handy when you are already in a browser tab: reading a pull request, an advisory or a ticket, and you want to check if the CVE in front of you matters for your code. For deep work, the Vulnerabilities view in the web app has a Reachability column next to Priority, and a filter such as reachable:true that narrows the list.

How should you read the answer?

• Reachable and in production. Treat it as urgent and open a fix.
• Conditionally reachable. Find the flag or route that turns it on. If it is off by design, record that and set a review date.
• Unreachable. Record why, and keep monitoring. A new code path can change the answer.
• Unknown. Do not close it. Look at the dynamic or configuration evidence, or fix it anyway if the fix is cheap.

Reachability lowers noise. It does not prove safety. Static analysis can miss dispatch through reflection, which is why unknown stays visible.

Try it yourself

Open the exploitability check demo in its own page.

Quick check

Sources

• Safeguard docs: browser extension
• Safeguard docs: reachability analysis
• Safeguard on the Chrome Web Store

Last reviewed: 18 October 2026.