Closed goldbergyoni closed 3 years ago
This is definitely a good recommendation, but there are different approaches on how to solve this:
The benefit of the last one is that you can implement and replace without touching the source code. And that you can use several tools at the same time. The downside is that is not part of the build itself, you need to set a specific task as part of the build/deploy process.
Be aware that there are some tools that allow you to reduce Docker images like distroless. As this tools remove all that is non essential, they will destroy every shred of possible usable information to detect a CVE.
@gonrial You just made this bullet much better, I'm updating the TOC.
My thoughts: A build-time scanner (Microscanner) is an inferior option. Why:
Breaks the standard pipeline - Every quality check should be part a CI, so there is one source and reports for the build status. The standard flow is: Build and then many quality checks. One of them is image scan
Image scan should be the last step - Most checks can be discovered using dedicated tools (snyk, gitleak), an image scan is kind of E2E test we conduct before production to see if the final product leaked something (+ check the OS CVE). If this line of thoughts resonated with you, then the image scan should be kept to the CI last step and not during build
Question - Any features we want to emphasize besides OS-level CVE, code CVE, secrets leak? Are you familiar with some famous OS-level CVE?
Thoughts?
p.s. If you want to right this bullet, be my guest...:)
Closing as the matching PR is merged #718
Context: This is used to share my TOC of a new best practice so I can solicit feedback and ideas before start writing. From my experience, this makes the writing experience much easier and shorter. And fun.
Title: Scan all docker image layers for vulnerabilities
Thoughts? improvement? Help me to make it better