The Snyk UI makes it easy to view you application vulnerabilities and licensing issues per project. Start by finding your application on the project tab, expand the project, and select the package manager file associated with your project. In our sample application Goof, select the package.json file.
Snyk displays detailed information about your project. The following are some of the critical pieces of information Snyk knows about your application.
Vulnerabilities - This is the total number of know vulnerabilities for your application.
Dependencies - The total number of dependencies for your application. This include direct and transitive dependencies from the open-source.
Source - Where the project is sourced in the developer toolchain. In our example it is GitHub.
Branch - Which branch the project is viewing. This is specific to projects sourced from SCM.
After reviewing your project details, Snyk users start to review their known issues which includes application vulnerabilities and licensing issues. The issues section is configurable to identify the most important vulnerabilities and licensing issues first. Prioritization is important and user's can select Issue type, Severity, Exploit Maturity, and Status to filter the most critical information first.
As you review each vulnerability you will notice a more about this issue option at the bottom of the vulnerability listing. This provides detailed information about the vulnerability using Snyk's vulnerability database and gives you insight on severity and exploit maturity. Select that option to view a detailed explanation and CVSS scoring information.
In our Goof example, you can read the all the details about the vulnerability including its CVSS score. You might also notice this particular vulnerability (ZipSlip) was discovered by our Snyk Security research team.
For complete details on the CVSS scoring system used by Snyk and CVSS scoring in general, please visit our documentation.
Synk uses the package manager of your application to build the dependency tree and display it in the Snyk UI. The dependency tree helps visualize which component is introducing the vulnerability and helps Snyk to determine the appropriate remediation advice.
In our sample application Goof, we see the how the transitive dependencies introduced a vulnerability into our application by examining the direct dependency firstname.lastname@example.org. The developer directly included this library into the source code via the package.json file and the email@example.com library had a dependency on firstname.lastname@example.org which has another dependency email@example.com. This helps understand how the dependency was introduced to the application and also how Snyk can remediate the issue.