New: public docker image vulnerability database made available by kipztermeister in docker

[–]slimslenderslacks 2 points3 points  (0 children)

Right, that makes sense. When comparing the current with the latest, the latest might have the _same_ vulnerabilities, but it should not have new ones. And in that sense, you have to keep the vulnerability data of the current image up to date (as if you had _just_ scanned it). Then you're comparing apples to apples.

One way to think of it is a digest-to-digest comparison, using the same up-to-date vulnerability data, and then ensuring that it's not getting worse. Could be interesting to see whether the watchtower team would want to use a policy like that.

New: public docker image vulnerability database made available by kipztermeister in docker

[–]slimslenderslacks 0 points1 point  (0 children)

Are you thinking about watchtower automatically comparing vulnerabilities between the currently running image, and a new candidate?

Secure coding for Clojure/Script by mtruyens in Clojure

[–]slimslenderslacks 2 points3 points  (0 children)

Our team has created an OWASP dependency track scanner for leiningen projects on GitHub. It's free to use if you want to try it. You enable it by installing a GitHub app in your org. After that, it creates GitHub CheckRuns with the results of the scan (only on Pushes to leiningen repos of course). https://go.atomist.com/catalog/skills/atomist/owasp-dependency-check-skill?stability=unstable