When Container Scanning Falls Short

Container Scanning meme

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 created 3 “log4j” container images. (If you want to play with these container images, click here)
 
1.)  Easy Mode – container created using “apt install liblog4j”.  This brings in log4j via Ubuntu’s own native package manager.
 
2.)  Medium Mode – the container was created by downloading log4j from Maven directly to disk.  (This mode best simulates what developers normally do.)  I even rezipped the jar to cause all the timestamps to refresh (which alters the sha1, of course), but this did not trick any scanners.
 
3.)  Hard Mode – same as #2 except the following 3 files are removed from “log4j-core-2.14.1.jar” before scanning it:
 
“HARD MODE” REMOVED FILES:
META-INF/MANIFEST.MF
META-INF/maven/org.apache.logging.log4j/log4j-core/pom.xml
META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties
 
Initial Unexpected Distracting Problem

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

When Container Scanning Falls Short

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.

 

Julius Musseau

About the Author

Julius Musseau

Julius Musseau, co-founder & CTO. Senior architect and developer with strong academic background and roots in the open source community. Contributor to a number of important open source projects.