Feedback before writing: Scan docker images for vulnerabilities

[goldbergyoni]

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

• TL&DR: Docker scan simple definition; Why they cover more attack ground that traditional npm packages scan; Why we need additional safety net (what if attacker injected a CVE to the container itself)
• Otherwise: An attacker could exploit OS-level CVE or even weakness of Node itself
• Simple explanation - Docker scanners scan all layers including the OS, installed binaries and Node itself. They warn if vulnerabilities are found
• Two advantages over scanning 3rd party npm libraries: (1) More exhaustive scan (2) Scan the final artifact, what if an attacker inject a CVE after the image was built
• When to use - in CI/CD but also scan production images and notify monitoring systems
• Features: Most scanners show severity per each finding, whether a newer version has a remedy
• Advance stuff - Since they scan so many layers, the likelihood of CVE is very high and the signal to noise is low. Set high threshold while scanning
• Code example: Not relevant here
• Example: A report for example on real-world Node.js image
  https://www.jenkins.io/images/post-images/2018-06-15-anchore/report.png

Thoughts? improvement? Help me to make it better

[gonrial]

This is definitely a good recommendation, but there are different approaches on how to solve this:

• source code scanning: you can add a tool to check app dependency and verify the source code for CVE checks. For example you can use tools like Snyk or GitHub built-in.
• Scan during image build: Aqua Security Microscanner does CVE scanning as part of the build process, so it's part of the Dockerfile, but doesn't look for app dependencies and doesn't have the full Alpine support if you need it. It only complements the source code scanning.
• Scan images after build or on servers: There are open-source scanner like Anchore, trivy and several services offer them as part of the registry service (AWS ECR, Docker hub, etc).

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.

[goldbergyoni]

@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:

1. 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

2. 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...:)

[kevynb]

Closing as the matching PR is merged #718