Third-party dependency scanning (SCA, Snyk Open Source)

In Eclipse plugin version 2.0.0 and later, Snyk is introducing a deeper integration with the native flows of Eclipse, inline highlights, problems integrations, and information about the issue on hover. The following shows all of these for a security vulnerability found in a third party dependency:

The vulnerable package is highlighted (the red squiggly line) indicating there is a high severity security vulnerability in this package. You have all the information on hover; you can scroll, read, or click the links for even more information. Advice on what action to take and how is presented right where the vulnerability is.
You see the integration with the Problems view, which is useful if you use the Problems view to filter and group issues. Snyk also indicates the line where the issue is, and clicking the issue in the problem view navigates to it.
You can see the gutter icons on the left, as well as the file map highlights (with colors matching the priorities) on the right.

The hover information is limited to JavaEditor and GenericEditor, which is the default editor for plugins like Wild Web Developer.

Right click menu options include:

Ignore issue—Hover over the specific issue that you want to ignore for the next 30 days and then access the context menu.

Snyk test—Run the Snyk test for the entire workspace.

Preferences—Access and update Snyk Vuln Scanner preferences directly from the right click menu.

Snyk View when collapsed

Title: The name of the project.

Dependency: A summary of vulnerabilities and the number of affected paths found for each project.

Snyk View when expanded

Title: The full name of the vulnerability affecting your project, linked to a description and complete details of the vulnerability in the Snyk database, to assist you in resolving the issue.

Dependency: The name of the direct dependency package in your project (the package you explicitly installed) that is affected by the vulnerability, either directly or indirectly.

All details appear on a single row and the Dependency (the name of the package explicitly used in the code) and Package (the name of the package that actually contains the vulnerability) columns both display the name of the same package:

An arrow appears on the row, grouping together all relevant details, similar to the following examples:

Examples in collapsed and expanded mode

The following shows a dependency in collapsed mode, when your project is affected by an indirect vulnerability:

In this example:

Package X uses Package Y, which in turn uses Package Z.

Package Z contains a Cross-Site Scripting (XSS) vulnerability, indirectly affecting your project.

The Dependency (the name of the package explicitly used in the code) is Package X; the Package field displays Package Z (the name of the package that actually contains the vulnerability).

The following shows a dependency in expanded mode, when your project is affected by an indirect vulnerability:

Click the arrow on the row to expand and view the full path from the direct dependency to the vulnerable package.

On the preceding screen the full path would appear as:

[Name of Package X]-->[Name of Package Y]-->[Name of Package Z]

Package: The name of the package in your project that is directly affected by the vulnerability. On the preceding screen:

The Dependency is indicated as Package X—this is the package the developer explicitly uses in the code
the Package field displays Package Z, which is the package that contains the vulnerability.

Fix: The name of the package if any and the version that it can be upgraded to in order to resolve the issue.