When Container Scanning Falls Short

Finite State acquired MergeBase in June 2024. This video was filmed prior to the acquisition. MergeBase capabilities have now been absorbed into the Finite State product to form a powerhouse in application security.

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?)

Analyzing log4j container images

Log4j, Log4j, wherefore art thou Log4j !?
Deny thy Apache foundation and refuse thy name.
That which we call a Java logging framework by any other name would surely log as sweet !

I created 3 “log4j” container images.

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:
   

Easy Mode - container created using “apt install liblog4j”. This brings in log4j via Ubuntu’s own native package manager.

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.

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.MFMETA-INF/maven/org.apache.logging.log4j/log4j-core/pom.xmlMETA-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties

ps.: If you want to play with these container images, they are all public.

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 updateapt 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

Container Scanning | Mergebase

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?

Are you using the best container scanning tools?

When evaluating container 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.

Finite State actually looks at the class files and 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?

{{cta('3d7d3c3a-6160-4f3d-84bf-8791626d072c')}}