Visual Studio developers writing C# or F# rarely leave the IDE to check whether the NuGet packages they just added are safe. Snyk built its Visual Studio extension around that habit: instead of running a separate command-line scan after a build, the extension parses the open solution's project files, resolves the full NuGet dependency graph — including transitive packages a developer never directly referenced — and checks every version against Snyk's vulnerability database in the background. Results surface as an in-editor panel with severity, CVSS score, and a suggested fix version, typically within seconds of opening a solution or saving a project file. This piece walks through the mechanics: how the extension identifies what to scan, where the vulnerability data comes from, what a result actually contains, and how this compares to the separate Snyk Code static analysis engine bundled in the same plugin. It's a look at how the tool works, not a comparison to any other product.
What does the Snyk Visual Studio extension actually scan?
It scans two distinct things: your open-source dependencies and your own source code, using two separate underlying engines exposed through one interface. Snyk Open Source (also called Snyk SCA — software composition analysis) reads the NuGet packages referenced by a .NET project or solution and checks them against known vulnerabilities. Snyk Code, a separate static analysis engine, reads the C# or F# source files themselves and looks for security weaknesses like injection flaws, hardcoded secrets, or insecure deserialization patterns written by the development team. The extension is distributed through the Visual Studio Marketplace and supports Visual Studio 2019 and 2022. Both engines run inside the same panel, but they answer different questions: "are the libraries I depend on vulnerable" versus "does the code I wrote have a security bug."
How does the extension find a .NET project's real dependency tree?
It doesn't stop at reading the .csproj file, because a project file only lists direct package references, not the transitive packages pulled in underneath them. A single <PackageReference Include="Newtonsoft.Json" Version="12.0.1" /> line can pull in dozens of indirect dependencies that never appear in the project file at all, and any of those can carry a known CVE. To get the complete picture, the extension relies on NuGet's own dependency resolution output — the generated obj/project.assets.json file (or a packages.lock.json file when lock-file mode is enabled), which is what dotnet restore produces after resolving every direct and transitive package plus its exact resolved version. Reading this resolved graph, rather than the raw project file, is what lets the extension flag a vulnerability in a package four or five levels deep in the dependency chain that a developer added indirectly and has likely never seen by name. Older packages.config-style projects are also supported, though the resolution mechanics differ slightly from the newer PackageReference format.
Where do the vulnerability matches come from?
They come from the Snyk Vulnerability Database, called Snyk Intel, which the same engine also uses across Snyk's other IDE plugins, CLI, and CI/CD integrations for VS Code, IntelliJ, Eclipse, GitHub, and GitLab. Snyk's security research team curates and enriches this database on top of public sources such as the National Vulnerability Database (NVD) and GitHub Security Advisories, adding details these public feeds often lack — accurate affected version ranges, exploit maturity, and remediation guidance. Every scan checks the resolved NuGet package name and exact version against this database rather than relying solely on a package's declared version range, which matters because a vulnerability disclosure frequently narrows or corrects the affected versions after the initial public advisory. The underlying scanning logic runs through a shared component called the Snyk Language Server (open-sourced by Snyk as snyk-ls), which every IDE plugin — including the Visual Studio extension — talks to over the Language Server Protocol, so the scanning behavior is consistent whether a developer is in Visual Studio, VS Code, or a JetBrains IDE.
What does a vulnerability result look like inside Visual Studio?
Each finding appears in a dedicated Snyk tool window as a tree grouped by project and package, listing the vulnerable package name, the installed version, a severity label (Critical, High, Medium, or Low), and a CVSS score. Clicking into a finding expands details including the vulnerability's CWE classification, a written description of the flaw, the introduction path showing which of your direct dependencies pulled in the vulnerable transitive package, and — where one exists — a specific fixed version to upgrade to. When no fixed version has been published yet, the entry is marked as having no available fix rather than being silently omitted, which is a meaningful distinction for a team trying to prioritize remediation work versus vulnerabilities they simply have to monitor. Developers can mark individual findings to ignore, which Snyk records in a .snyk policy file that can be checked into source control so the suppression is visible to the rest of the team rather than living only on one developer's machine.
When does a scan actually run, and how fast is it?
Scans run automatically when a solution is opened or a project file changes, and can also be triggered manually from the Snyk panel without waiting for an automatic trigger. Because the dependency-tree scan works off the already-resolved project.assets.json output rather than re-resolving NuGet packages from scratch, an incremental re-scan after a single package version bump is typically fast — the extension is checking a static list of resolved packages against a vulnerability database lookup, not performing a fresh build. The Snyk Code static analysis pass, which parses source files for security patterns, runs as a separate background process and updates its own findings independently, so a developer can see dependency results and code-analysis results refresh on different timelines within the same panel. This design — local dependency-tree scanning paired with a queryable central vulnerability database — is the same pattern Snyk uses in its CLI and CI integrations, which is why findings surfaced in Visual Studio are meant to match what a snyk test run against the same solution would report in a pipeline.
How is Snyk Code different from Snyk Open Source in the same extension?
Snyk Code doesn't look at your dependencies at all — it performs static application security testing (SAST) directly on the C# or F# source you wrote, using a symbolic-execution-based engine to trace how data flows through your code and flag patterns like SQL injection, path traversal, or use of weak cryptography. Where Snyk Open Source answers "is this third-party package I'm using vulnerable," Snyk Code answers "did I introduce a vulnerability myself." Both results appear in the same Visual Studio panel and share the same severity taxonomy, but they're generated by architecturally distinct engines: one is a database lookup against resolved package versions, the other is program analysis of your own source. For a .NET solution with a large number of NuGet references, Snyk Open Source findings tend to dominate the initial scan simply because transitive dependency trees in the .NET ecosystem — pulling in packages like Newtonsoft.Json, System.Text.Json, or various ASP.NET Core middleware libraries — are often large, while Snyk Code findings are scoped to whatever custom logic the team has actually written.
How Safeguard Helps
IDE-level scanning like Snyk's Visual Studio extension is valuable precisely because it catches problems while a developer is still looking at the code, but it also has a natural blind spot: it reflects the security posture of whatever solution happens to be open on whatever machine ran the scan, at whatever moment the scan ran. Safeguard is built to answer the questions that sit above any single IDE session — which of the hundreds of repositories across an organization actually depend on a newly disclosed vulnerable NuGet package, which of those are internet-facing, and whether a fix that shipped in one solution actually made it into production everywhere else the same package is used. Rather than replacing developer-facing tools, Safeguard aggregates software composition and build-provenance signals across an organization's full portfolio of .NET and other services, correlates them against the same class of public vulnerability disclosures that feed tools like Snyk's, and gives security and platform teams a single place to see exposure across every solution, not just the one open in an editor at the time of disclosure. For teams that already rely on IDE-level dependency scanning as a first line of defense, Safeguard's role is to confirm that what looks clean at commit time stays traceable and verifiable all the way through build, release, and deployment.