Reviewing application vulnerabilities
Snyk displays your application vulnerabilities and licensing issues per project. Start by finding your application in the projects tab, expand it, and select the file associated with your project. In our example application goof, you can select the
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 known vulnerabilities in your application.
- Dependencies: The total number of dependencies for your application. This includes direct and transitive (nested) dependencies.
- Source: Where the project was tested from in the developer toolchain. In our example it is GitHub.
- Branch: Which branch the project is being monitored from. This is specific to projects imported from a SCM.
After the project summary details, you can review individual vulnerabilities and licensing issues. The issues are sorted by priority score and can also be filtered by Issue type, Severity, Exploit Maturity, and Status.
As you review your list of vulnerabilities, you will notice a More about this issue link. This provides detailed information about the vulnerability using Snyk's vulnerability database, giving you a deeper insight into the issue.
Snyk's vulnerability database
In our goof example, you can read all the details about the vulnerability including its CVSS score.
If you'd like to review more details on the CVSS scoring system used by Snyk and CVSS scoring in general, see our article on how a vulnerability's severity is determined.
Viewing the dependency tree
Synk uses the package manager of your application to build the dependency tree and display it in the dependency tab of the project view. The dependency tree helps visualize which components are introducing a vulnerability, and Snyk uses this information 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 explain how the dependency was introduced to the application and also how Snyk can remediate the issue.
acceptslibrary are included multiple times due to transitive dependencies.