Why is this finding reachable? Using VS Code and Safeguard together

A finding is reachable when your code has a path to the vulnerable function. In Safeguard, reachability is a platform feature, while the VS Code extension shows your vulnerabilities and has a chat panel for security questions about selected code. Use the extension to see the finding and ask about it, and the platform to read the reachability class.

We checked the docs before writing. The IDE page does not describe reachability inside the extension, so this post does not claim it. It explains what each piece does and how to use them together.

What does reachable mean?

Safeguard's reachability documentation says the feature determines whether your code actually calls a vulnerable function, so your team patches the issues that matter. It uses three methods.

• Static: build a call graph from source, lockfiles and bytecode and look for a path to the vulnerable code.
• Dynamic: record which modules and functions production workloads actually load and call, and flag never executed paths as cold.
• Configuration: read framework configuration, such as Spring bean definitions or Next.js route files, to see whether code is wired in at all.

Each finding is classed as reachable, conditionally reachable, unreachable or unknown. Unknown is marked conservatively as potentially reachable. The class feeds a 0 to 100 priority score together with CVSS, EPSS and Known Exploited Vulnerabilities status, among other inputs.

The page also lists limits. Reachability is weakest with reflection, eval or unsafe dispatch, with data driven vulnerabilities, and with configuration specific paths. In those cases it recommends leaning on KEV, EPSS and runtime observation.

What does the VS Code extension give you?

Per the IDE support page, the extension for VS Code, and for Cursor through Open VSX, scans dependency manifests in real time across common package managers. It adds a Safeguard activity bar view with Vulnerabilities, SBOM, Compliance and Recommendations panels, inline warnings and CodeLens. It also has inline Package Firewall checks for typosquats, dependency confusion and known malicious packages, and an AI assistant chat panel for security questions and analyzing selected code.

Install it from the Extensions view by searching "Safeguard", or from a terminal.

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

Some features need login. Without it, backend verdicts and notifications are disabled or fall back to local behavior.

A workflow for asking why

1. See the finding. Open the Vulnerabilities panel and select a vulnerable dependency.
2. Find the call site. Search your code for where the package is imported. If nothing imports it directly, the vulnerable library may be transitive, which changes the question.
3. Ask the chat panel. Select the code that uses the package and ask a specific question, such as how that code relates to the vulnerable function named in the CVE. The docs describe the chat as handling security questions and analysis of selected code. Treat answers as a lead to confirm, not a verdict.
4. Check the reachability class on the platform. The platform's Vulnerabilities view has a reachability column and filters, and the Griffin assistant takes natural language questions about reachable priorities and why something was deprioritized.
5. Decide. Reachable and exposed means fix now. Unreachable still deserves a ticket and a periodic recheck, since code changes.

Why not trust the score alone?

Reachability reduces noise but does not replace judgment. Safeguard's documentation estimates that reachability filtering removes 60 to 80 percent of findings from the urgent queue. Take that as the vendor's own figure for the feature, not a promise for your codebase. Your results depend on language, framework and how dynamic your code is.

Try the idea at /demos/exploitability-check.

What to do

1. Install the extension and log in.
2. Review the Vulnerabilities panel for the project you work in most.
3. For each high finding, find the import and the call site.
4. Use the chat panel for a second opinion on selected code, then confirm.
5. Check the reachability class on the platform before you rank the fix.
6. Revisit unreachable findings when you change the related code.

Quick check

Sources

• Safeguard documentation: IDE support, fetched 18 October 2026
• Safeguard documentation: Reachability analysis, fetched 18 October 2026

Last reviewed: 18 October 2026.