Some dependencies found via the CLI may differ from those found via the configuration you've set up through our app.
When you use our CLI tool and run a test (either by
snyk test or
snyk monitor) we look at the dependencies as detected by the build tool in order to see exactly what your project relies on. Private dependencies and the specifics of your build environment are all available to the build tool, and so to Snyk as well.
However, when we run a test against an integration such as GitHub, GitLab or Bitbucket server we only process the project's dependency files (for example, the
We then infer the dependency graph of your project, mimicking the operation of the build tool. We do not have access to private dependencies, specifics of your build environment and so on. Hence the results may be partial compared to our CLI based analysis.
For example, let's say a sub-dependency requires
foo ^0.0.5 and during build
foo 0.0.6 was installed (but had a vulnerability) and then
foo 0.0.7 was released (patching it) after the fact.
According to these rules, an integration would assume that
foo 0.0.7 was installed - but in the local project itself, this is not the case.
Maven, Gradle and SBT
In some languages such as Maven, Gradle, and SBT our integration with Github, Gitlab, Bitbucket, etc. relies on parsing the manifest file to determine dependencies whereas these languages frequently rely on code to build the dependency tree.
Dependency overrides and mapping using code can sometimes cause the CLI to report a more accurate picture of your dependencies than when importing through the SCM.