Closed nikola-rados closed 3 years ago
Looks promising!
I would like to see this tested on the climate-explorer-frontend repository, for which Anchore found approximately 629082167.3 issues, none of which I could tell what the solution was, if they even had a solution. It seems like the more configurable "fail" conditions would be extremely helpful there!
I am also curious to see what the display on the website is like, I will pester you for a login.
Judging from this, Snyk is completely external to our codebase? You point Snyk at it from elsewhere and it does its thing? How do we see that? If I'm right (seems I am from what Lee says), then a hyperlink to it in the README would be nice.
@corviday and @rod-glover I have sent you emails for access. The link to it can be found at the bottom of the checks (the details button):
This PR integrates a shiny new DevOps toy, Snyk. It will scan the entire repo looking for vulnerabilities, here are the files it looks at:
As you can see it not only looks at Docker-related items, but others as well. The issues are recorded on the website (you will need to request access the first time you try and look at it) and provide details on how to solve them. One of the main benefits of Snyk is configuring when you are warned of a problem:
The build will only fail if the vulnerability has an available fix. This allows us to get rid of those annoying :x:s on commits that can't be resolved. Furthermore, it can ignore legacy issues if you so choose. In the image above we see that
requirements.txt
in fact has 26 high vulnerabilities but this PRs test passed. This is because we have selected "Only fail when PR is adding dependency with issue" in the settings. We can of course change this, but this gives us the flexibility to have issues visible to us on Snyk while not setting off the alarm bells on Github. The configuration details above are set for all Github projects from PCIC, but there is room for some repo-specific settings. Please feels free to suggest any changes.The
pcic-devops
github account is responsible for the tooling (account details can be found and TPM) meaning it also created the webhook. Any changes to this webhook should be done through the general account.Another point, I may have been wrong about the 200 test limit. It seems that those 200 only apply to private manifests (which I assume are private repos?). So far I have run several sets of tests from the PR and none have counted towards the monthly total:![image](https://user-images.githubusercontent.com/26128992/122305933-7a8a7580-cebc-11eb-8ab0-44484f61923a.png)
I would like to try this tool in a couple of repos for a few weeks and see how it goes. I am fairly confident we will like it but I want to be sure it is as good as advertised. If there are some repos you would like to see this in please let me know.
Final note, I used Rod's
test-migration
branch as a base to get those lovely CI fixes he made.Resolves #216.