1

Running Snyk from their web page against a Github repo, finds 7 High Severity issues in the pom.xml file.

I've configured Jenkins to run against the same project with the Snyk plug-in, but just get:

Snyk installation is UP-TO-DATE Testing for known issues...

/var/lib/jenkins/tools/io.snyk.jenkins.tools.SnykInstallation/synk-tool/snyk-linux test --json --severity-threshold=low Result: 0 known issues | No known vulnerabilities Remember project for continuous monitoring... /var/lib/jenkins/tools/io.snyk.jenkins.tools.SnykInstallation/synk-tool/snyk-linux monitor --json --severity-threshold=low Archiving artifacts Build step 'Invoke Snyk Security task' changed build result to SUCCESS

The Synk plug-in uses the token from the snyk.io page and is configured in Jenkins with all default values.

Paul Croarkin
  • 14,496
  • 14
  • 79
  • 118
  • Can you share the project you are trying to monitor? Looking to replicate the issue on my side. Also, if you could edit your post with your config file (excluding sensitive data) that would help. – PStember Aug 12 '19 at 15:41
  • Is the project also showing 0 vulnerabilities once monitored on snyk? – PStember Aug 12 '19 at 15:47
  • @PStember Running the project through the snyk web scan shows 7 high severity vulnerabilities from scanning the pom.xml. I cannot give you access to the project. An example vulnerability (which we will fix) is that the pom.xml references version X of a particular dependency and that upgrading to a newer version will remediate it. We would like this to show in the Jenkins build, but the Snyk task in Jenkins reports "0 known issues | No known vulnerabilities". – Paul Croarkin Aug 12 '19 at 16:18
  • @PStember What do you mean by "config file". Is this a Synk thing? We are using the Jenkins plug-in out-of-the-box. – Paul Croarkin Aug 12 '19 at 16:20
  • In that case, it should be fine. what could also be an option is that you have a policy file in your project. @Paul, I would suggest that if the issue persists, you get on a call with them to solve this and report here the reason afterwards. – PStember Aug 12 '19 at 16:38
  • Could you point to documentation on this policy file? I did not see reference to it on the Jenkins Snyk plug-in page. – Paul Croarkin Aug 12 '19 at 17:38
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/197863/discussion-between-pstember-and-paul-croarkin). – PStember Aug 13 '19 at 09:55
  • This question appears to have stalled for 2.5 years. Is this still an open issue for you, @PaulCroarkin ? – Eric Smalling Apr 14 '21 at 22:57

1 Answers1

2

Another reason could have been the differences between CLI scans and SCM scans in Snyk, due to some variables that are not supported or private dependencies for instance. That would be discovered in CLI but not SCM if you haven't integrated with Artifactory (but in this case the number of vulns in CLI would have been higher than SCM actually)

This is an article that explains it in details https://docs.snyk.io/snyk-cli/test-for-vulnerabilities/differences-in-vulnerability-counts-across-environments

Note that since this question, Snyk has dramatically improved the SCM accuracy for Maven, and there should hardly be a difference between SCM and CLI results.

Jonathan Gruber
  • 408
  • 1
  • 16