Developers using Eclipse for Java, and increasingly for polyglot enterprise projects, already lean on one screen more than almost any other: the Problems view. It is where compiler errors, warnings, and static analysis markers from tools like FindBugs or Checkstyle have surfaced for two decades. Snyk's Eclipse plugin, published on the Eclipse Marketplace as "Snyk Security - Code and Open Source Vulnerabilities," deliberately targets that same real estate. In practice, that makes it both an open source scanning tool and a static analysis plugin in one package, since it runs open source scanning against a project's manifest files right alongside first-party code analysis. Instead of asking developers to open a separate dashboard or run a CLI scan and parse JSON output, the plugin folds open source dependency findings and static code analysis results directly into the workflow developers already use to fix bugs. This piece walks through how that integration actually works mechanically — how the plugin talks to Snyk's backend, how it maps findings onto Eclipse's marker system, and what triggers a scan — based on Snyk's published plugin documentation, without speculating on unpublished internals.
What does the Snyk Eclipse plugin actually scan?
The plugin covers two distinct categories of findings: open source dependency vulnerabilities (Snyk Open Source, i.e., software composition analysis) and static application security testing of first-party code (Snyk Code). For dependency scanning, the plugin inspects manifest and lockfiles for the ecosystems the project uses — for Java projects this typically means Maven's pom.xml or Gradle build files, resolved against Snyk's vulnerability database to identify known CVEs and other disclosed issues in direct and transitive dependencies. For code scanning, the plugin analyzes source files written in supported languages for security-relevant patterns such as injection flaws, hardcoded secrets, and insecure API usage, without requiring the code to be compiled or executed. Both scan types run through Snyk's cloud-hosted analysis engines rather than a fully local scanner, meaning the plugin sends relevant file or dependency-tree data to Snyk's service and receives structured results back.
How does the plugin get findings into the Problems view?
It works by registering scan results as native Eclipse markers rather than building a separate custom findings panel from scratch. Eclipse's platform has long exposed an extension mechanism for tools to attach markers — the same underlying concept the Java compiler uses to flag a syntax error or an unused import — to specific resources, lines, and severity levels, which the Problems view then aggregates automatically alongside every other tool's output. Snyk's plugin follows this established IDE convention: a dependency flagged as vulnerable, or a line of code matching an insecure pattern, gets attached to the corresponding file and line number with a severity tier, so it appears in the same sortable, filterable list where a developer already checks for build errors before committing. This is a meaningful design choice because it means developers don't have to context-switch to a dedicated security tool to see that something needs attention — the signal shows up where "things that need fixing" already live.
How does the open source scanning workflow differ from code scanning?
Open source scanning is manifest-driven, while code scanning is source-driven, and the plugin surfaces both through the same interface with different underlying data. When the plugin evaluates open source dependencies, it is effectively asking "does anything in my resolved dependency tree have a known disclosed vulnerability," which means the fix suggestions it offers are typically version upgrade recommendations — for example, flagging that a project pinned to an older Jackson-databind or Log4j release should move to a patched version. Snyk's database tracks CVEs as well as vulnerabilities identified through its own research and disclosed independently of the CVE program, so counts can differ from raw NVD figures for the same library. Code scanning, by contrast, evaluates the logic of first-party source files directly and reports issues like potential SQL injection or path traversal with the specific code path implicated, since there is no "upgrade a version" fix available — remediation guidance instead points to the vulnerable pattern and often a suggested code-level fix.
What triggers a scan, and how fresh are the results?
Scans run both on-demand and automatically in response to editing activity, according to Snyk's plugin documentation, rather than only on a fixed schedule. A developer can trigger a full project scan manually from the plugin's toolbar or view, and the plugin also re-evaluates open files as they are saved or as dependency manifests change, so a newly added dependency in pom.xml can surface a flagged vulnerability without the developer needing to remember to re-run anything. Because the open source and code analysis both depend on a live connection to Snyk's backend, results reflect Snyk's vulnerability database at the time of the scan rather than a snapshot bundled with the plugin at install time — meaning a dependency that was clean last week can show up flagged today purely because Snyk's database was updated with a newly disclosed issue, with no change to the project's own code.
Does using the plugin require a Snyk account, and what does that mean for a project?
Yes — the plugin authenticates against a Snyk account (via Snyk's standard login flow, typically backed by an API token or OAuth-style browser authentication), because the actual vulnerability matching happens against Snyk's hosted service rather than a fully offline database bundled with the IDE plugin. Practically, this means the plugin's usefulness and scan limits are tied to whatever Snyk plan the developer or organization is on, and that dependency-tree or code snippet data is transmitted to Snyk's cloud infrastructure as part of each scan. For teams evaluating IDE-embedded security tooling, this is an important operational detail distinct from the UX question of "does it show up in the Problems view" — it determines what data leaves the developer's machine and what account-level configuration (project policies, ignore rules, organization settings) applies to the results a given developer sees inside Eclipse.
What are the practical limits of Problems-view-based integration?
The main limitation is that the Problems view is a per-project, per-workspace list that reflects the state of open or recently scanned files, not a durable organization-wide inventory of every dependency vulnerability across every repository a team owns. It's built for the moment a developer is actively working in a file, which is exactly where it adds value — catching a vulnerable dependency before a pull request is opened — but it isn't designed to answer questions like "which of our forty services currently ship a critical severity open source vulnerability" or "how many of these findings were introduced this quarter." Severity and marker display also depend on Eclipse's own settings for how markers of different severities are sorted and filtered, so two developers with different Problems view configurations can end up with a noticeably different sense of how many issues are outstanding, even when the underlying Snyk scan data is identical.
How Safeguard Helps
IDE plugins like Snyk's Eclipse integration solve a real problem — getting a signal from an open source scanning tool in front of a developer at the moment they're writing code — but that signal is only as useful as what happens after it appears. Safeguard is built to pick up where the Problems view leaves off: instead of vulnerability and dependency findings living inside individual developers' workspaces, Safeguard aggregates software composition and dependency risk across every repository, service, and build in an organization's software supply chain into a single inventory. That means the same class of finding a developer might see flagged locally — a vulnerable transitive dependency, a risky package version — is also tracked centrally, correlated against what's actually deployed, and prioritized by real exploitability and business context rather than left to whichever engineer happened to have their IDE plugin scan a file that day. For teams that want the developer-facing convenience of in-editor signals paired with an organization-wide view of software supply chain risk, that combination — local visibility plus centralized, continuously updated inventory — is where Safeguard's approach to open source and dependency risk management is designed to add the most value.