Docker Container Security: Scanning for Vulnerabilities with Trivy (Correction in Description)

19 thoughts on “Docker Container Security: Scanning for Vulnerabilities with Trivy (Correction in Description)”

• ✅✅ Go to our partner https://trymintmobile.com/dbtech to get premium wireless for as low as $15 a month!

• Well that was massive eye-opener! Firstly, thank you for this, what a great tool to use!

  Outside of that, wow… Now I've only got a few internet facing services and fortunately they're pretty clean but some of my internal stuff, full of various vulnerabilities! Don't get me wrong, I don't mind too much given my dodgy containers are internal only and will never be internet facing, but scary none the less.

• As the correction describes, this test doesn't test the security of either Pi-hole or AdGuard. It is looking at reported vulnerabilities in the underlying OS. Alpine has fewer of them than Debian 11. Plenty of people run Debian 10 and 11 on bare metal at home with no worries.

• Excellent as always … but is there is a way to scan all my containers in one shot ?!

• Will Trivy be able to find security holes in an app written in Go? Isn't Adguard home written in Go? Maybe that is why there is such a big difference between Adguard and Pi-hole, which uses a sea of ​​libraries ???

• This is how we do DevSecOps!!!!!

  Well Done

• Great Job Brother!!!!!!

  Always good to practice good Security!

  Say the update to this video as well, thank you for taking accountability.

  And great job asking for these developers to take accountability for their products

• A correction has been uploaded: https://youtu.be/xSMZ2JbAYaY

• Did not know about this, thanks for bringing it to our attention. I'm going to put it on every server in my rack. Can never be too security conscious.

• Try the test again against pihole/pihole:development-v6 😉

• Note that most of the containers that have hundreds of CVEs are containers that use a full end-user OS as their base image layer. In the two cases you showed, they were based on a full debian OS (not even debian-slim). This is the "FROM" line at the top of the Dockerfile.

  The two that were very clean were based on Alpine images. Alpine has a much lower vulnerability surface area, so naturally it will have fewer CVEs.

  The vast majority of the CVEs were inherited from debian, NOT the running application. That's still not good though.

  The CVEs in the code the developers wrote are usually denoted by "(composer)" in the header of the list. (Just like the base layer is represented by "(debian x.y.z)". If you look at 8:40 in the video, you can see the top three CVEs are Alpine CVEs "(alpine 3.17.5)", and the bottom three are marked as "(composer)" and those are the app's CVEs.

  Alpine isn't perfect as you can clearly see. But it's much more secure than a full scale OS like debian (or ubuntu, etc.).

  Many developers forget that the execution environment (or container) is different from the development environment, and fail to consider the security of the container build itself. (It's twice the work, and you need to test the new container out)

  The reason I personally prefer languages like C, C++, Rust, Go, etc. is that they can be compiled down to a statically-linked binary. It's a single file (typically) and doesn't really REQUIRE anything but a filesystem and the linux kernel to run. (And that takes out all the distribution bloat out of the final container as well) But, that's even a bit more work as you need to make a multi-stage build of the container (You can search YouTube for "docker FROM SCRATCH" to see this process if you're interested.

  Hope this helps a bit 🙂
  —jmp

• Hi, thanks for making us aware of Trivy but I think you've misunderstood the results – The 'fixed' status just shows a fix/patch is available and even shows the version you need. You just need to update to the fixed version to be secure.

• God damn… – . – I'm genuinely shocked about Pi hole vulnerabilities. Now I'm afraid what I will discover on my containers.

• Great video, but i think you only skimmed the results a bit. From the looks of it a few of your build versions are before the "FIXED" build, meaning you are on a none fixed build ..

• Never understood the hype of PiHole. There are many alternatives, Adguard-home being one of those. dnscrypt-proxy supports adblocking dns lists too, without webgui… pfsense pfblocker-ng etc etc etc…

• 1st: Thank You for sharing. As a "container hoarder" I am always interested in new "container projects" for my homelab. 🙂

  This is me thinking loud after just one cup of coffee in the morning:
  – Correct me if I'm wrong but fixed does not mean it is fixed in the scanned image itself but a fix is available for that specific framework/library to fix the image with. (Just to be clear.)
  – I am curious if these issues are (often) related to a framework/library which you can update yourself in a e.g. Proxmox LXC when a non docker version is available

  No I have to figure out to export all my running image versions on all hosts so I can scan those. XD

• Must scan trivy by trivy first

• Excellent as always……🙏

• What are the real issue with a docker that has several issues (as you showed) but runs exclusively within you LAN and has no access to the internet?
  I run pi-hole but not accessing from outside. How dangerous (in this example) is the situation?

Comments are closed.