| Bake image scanning into CI/CD pipelines |
 |
| Adopt inline scanning to prevent leaks of secrets |
- Implement inline image scanning, scanning images directly from the CI/CD pipeline without needing a
staging repository - With inline image scanning, only the scan metadata is sent to the scanning tool (preventing a leak if the image contained secrets by mistake)
 |
| Perform image scanning at registries |
- Include image scanning as one of the first steps after pushing to a registry
- It ensures images have been scanned before running
 |
| Leverage Kubernetes admission controllers |
- Leverage Kubernetes to check the images before scheduling them, blocking unscanned or vulnerable images from being deployed onto the cluster
- Scanning tools usually offer a validating webhook that can trigger an image scanning on demand and then return a validation decision
- An admission controller can call this webhook before scheduling an image
 |
| Pin image versions |
- Sometimes, the image you scan is not the same one you deploy in your Kubernetes cluster
- This can happen when you use mutable tags, like
latest or staging
 |
| Scan for OS vulnerabilities |
- Even if you didn’t introduce a new vulnerability in your image, it will be susceptible to those in the base image
- That's why your scanning tool should actively track vulnerability feeds for known vulnerable images and notify you if you're using one of those
 |
| Flag vulnerabilities quickly across Kubernetes deployments |
- What happens with images that are already running? (i.e., imagine that you scan and deploy an image, and right after doing so a new vulnerability is found in it)
- Continuously scanning the images that are running in the cluster
 |
| Reduce attack surface |
- Make use of distroless images
- Scan for vulnerabilities in third-party libraries
- Optimize layer ordering
- Scan for misconfigurations in Dockerfiles
|
