Some dependencies found using the CLI may differ from those found using the SCM integrations you've set up using the Snyk UI.
When you run a test with the CLI using snyk test or make a snapshot for ongoing testing using snyk monitor, snyk looks 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 snyk runs a test against an integration such as GitHub, GitLab, or Bitbucket server, Snyk processes only the dependency files for the project, for example, the package.json or Gemfile.lock or other supported manifest file.
Snyk then infers the dependency graph of your project, mimicking the operation of the build tool. Snyk does not have access to private dependencies, that is, the specifics of your build environment and so on. Hence the results may be partial compared to Snyk 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 package managers such as Maven, Gradle, and sbt, the Snyk integrations with GitHub, GitLab, Bitbucket, and so on rely on parsing the manifest file to determine dependencies, whereas these package managers 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 you are importing through the SCM.
Golang
For Go Modules projects imported using Git, dependencies are resolved at the module level rather than the package level, as snyk does not have full access to your project source code. Go Modules projects in the CLI are scanned at the package level rather than on the module level, as snyk has full access to your project source code.
This means you may see more issues reported for projects tested in the SCM, as we report all vulnerabilities for each module not just the package(s) referenced in your source code.
This is beneficial since you might use a vulnerable module but not the vulnerable package.