Are you relying on your container scanning to secure your applications? You might be exposed!
Containers have taken IT by storm. They increase delivery speed and stability. To secure them, you just run a scanner, right? Perhaps…
Metal detectors cannot detect plastic explosives. Similarly, many container scanners (e.g., Quay, Docker Hub, and even Snyk) are unable to detect the most vulnerable libraries inside Docker containers or Kubernetes clusters.
Do you want to know what your container scanner might be missing?
Watch this live streaming event with the heavyweight security expert Julius Musseau, where he highlights the issues and presents solutions. Learn about the typical container scanning short falls.
What you learn (takeaways)
- Where most container scanners fall short (and can seriously hurt you).
- A methodology to evaluate container scanners
- How to simplify application security AND improve container scanning (too good to be true?)
Webinar Highlights
Container Images
I didn’t expect this at all, but all the container scanners (except MergeBase) are barfing a ton of uninteresting CVEs against the “ubuntu:20.04” latest base image. This is an LTS image under active support (still receives security patches) until 2023. Why are the scanners reporting a bunch of vulns against it (including some from 2016)? This doesn’t make any sense!
As an end-user, there’s nothing I can do!
apt update
apt dist-upgrade
Ubuntu reports, “You’re completely up to date; there’s nothing to do!” but the scanners are still reporting vulnerabilities. Why not warn me that the sun will explode in 5 billion years while you’re at it?
Container Scanning – The Actual Results
It turns out most container scanners are police officers where if you say, “oh, sorry, officer, I seem to have misplaced my driver’s license,” they just let you go!
This could be a problem because:
1. Some libraries don’t include metadata files – either on purpose, or by accident, or by historical happenstance (e.g., the metadata format had not been standardized back in 2005 when the Jar was created).
2. Open source logic can be mixed and imported in different ways (open source licenses usually don’t forbid this), and metadata might get altered or omitted during such transformations. Copy/paste, anyone?
3. Finally, what if someone maliciously removes or alters the metadata?
Conclusion
When evaluating scanners, it’s very important to examine them with a pre-seeded known-vulnerable sample (preferably one you create yourself) during your tool selection process (and perhaps during an annual check-up/review).
And one final caveat: I suspect the scanners were all carefully tuned to detect log4j (e.g., special one-off logic). I would be pleasantly surprised if they did as well against less infamous (but similarly vulnerable) samples.
MergeBase actually looks at the class files. And so MergeBase detects the vulnerable version in “Hard Mode” regardless of the metadata present or not present.
Ready to try our SCA tool and avoid problems when scanning your container?
Want to check out our next live event? Click here and find out more about it.
