Another great video. On top of that I'd add I am observed variations in container scanner results. Remember that scanners are based on database of vulnerabilities and some of them update more frequent than others, or simple, has a different logic when scanning. Having said that I'd encourage pick the top 3 free scanners out there (Trivy, Grype, Snyk) and double check your scanning results. (you can build a Python script to consolidate the scanning and even build into a pipeline). The reason why these discrepancies are common relies in the fact how scanners logic runs. I've been found earlier that Snyk doesn't work well with stripped binaries on containers (for instance, when the container builder decided to remove some metadata of the container in order to make it reduce the size of the image). @Dreams of Code ... awesome material ... I'd improve this video in the future using Trivy instead Grype since Trivy scans secrets along with the process of containers scanning. =)
Thank you! I'm a huge fan of Trivy and it's my preference as well! I went with syft and grype for this video to mainly for educational focus on the two distinct parts, sboms and scanning. Trivy can also do sboms but i didn't want to go into too much detail about it as I've got a video planned for Trivy in the future 😁. The aggregation is a great idea. It's something we've been considering as it's hard to be comprehensive without it due to the differences.
Thanks a lot, once again! I really love your introductions to different tools! And your animations are amazing, as always! Personally, I find that the short sound effects you added detract a bit from what you are saying and I'm glad you didn't use them as much after the intro. (Just wanted to let you know in case you plan to add them to the rest of the video as well... but then again, perhaps it's just me. :-)
Thank you for the feedback! I'm still trying to get the mixing right and was probably too loud on some of them! I make sure to keep them out of any instructional parts though. I'm glad you liked the video and I'll try to do better!
very usefull and thank you for making this video I am happy to see some of my images that run go apps have zero vulnerabilities according to grype where as others that use bigger, lets say more feature rich base images not so, er, well, some vulnerabilities there then, ahem. So there is a lot to be said for small containers running go, rust, ( insert here other compiled and perhaps statically compiled ) that use base images that are as minimal as possible if you want them to 'stay young and beautiful'.
The bar at the bottom with the number "1" on the far left is the status bar from tmux with the catppuccin theme, he shows the setup in his video on tmux: "Tmux has forever changed the way I write code."
Is this more applicable to container maintainers or to admins deploying a container? You should vet containers you're going to deploy, but having to update dependencies/packages yourself before deploying seems too much. Even though I just started working professionally, I prefere setting up VMs and applications up from scratch. Repos for newer versions etc. in hindsight it might be just as much work
We use container scanning in our CI/CD pipeline and basically block any images that have a fixed issue from being deployed. We have someone who is responsible for security, but adding this as automation allows us to scale with security. So, to answer your q: It depends!
I'd say both. As a maintainer you want to make sure you are keeping up to date with issues of your dependencies, so the image you deliver stays more secure. As an admin you want to make sure you are deploying up to date versions of your container images, and might not want to trust the maintainer to keep things secure. You can then raise issues to the maintainer, if there's something critical to fix, or look at alternative images/projects altogether to satisfy your workload.
Very nice video. But to play devils advocate here: "An image has components with vulnerabilities" is not the same as "An image is exploitable". Many of the vulnerabilities, even those categorized as HIGH, are not exploitable in practice. So while the 87% sound very very bad, it does in no way mean that 87% of the images can actually be exploited in the field if they are deployed. (Assuming that the 87% is just counting images that have components with vulnerabilities.) This of course doesn't mean we should just ignore vulnerabilities. The scanners are very useful and should probably be used by pretty much anyone. I'm just saying that things are often not as bad in practice
You're correct. Not all vulnerabilities can be exploited. Deployment models, networking and isolation from the vulnerability mean that not every container is exploitable even if it has a high or critical vulnerability. I also strongly agree that it's not a good practice to ignore them as it can cause the broken window effect. I don't believe I said 87% of images are exploitable though. Only that 87% have high or critical vulns, as per the source.
But these issues weren't about the docker rather the OS or software that being used. Also, using docker, opens up the opportunity to scan the OS, which it wasn't the case back in the day we just trust the server provider's OS without even scanning or ability to modify it as easy as docker Images. thanks for sharing the scanning tools though.
Oh absolutely. Docker has been amazing but the complexity is still the main issue, and there's way more containers than base OS's now than there used to be. Fortunately, container scanning is providing a great solution and I agree, it's great that we can do it now.
Just upgrading to the latest version brings in new features that must add new vulnerabilities. This is like sticking your head in the sand and then claiming you are now far away from the beach.
You're not wrong. But the main difference is that those vulnerabilities are yet to be discovered by both malicious actors and maintainers. Once they're discovered they're likely to be exploited. Generally speaking, most of the people discovering 0-days are government affiliated organizations, which we have very little insight into, or security researchers, who tend to disclose as soon as they discover. Malicious actors rarely discover 0 days themselves and usually take advantage of poor upgrade cycles to exploit already known vulns.
Syft is great for sboms so you'd probably use that by itself. I prefer Trivy over grype personally as it provides better scanning results, in my opinion. You can use Trivy direct, or with the sbom, which allows you to check it against already deployed services periodically.
@@dreamsofcode How to achieve a comparable look, like you did with tmux and nvim. Your videos are very simple and well done, which helped me start playing with the previously mentioned programs.
@@dreamsofcode Elliot old chap, I made a file for different coloured outputs....I find it helps with debugging. Running pdb from the Terminal is okay, although a bit knotty, but colour-coding my output, red, blue, yellow, green e.g.- def printblue(text): print("\033[34m" + str(text) + "\033[0m") - I actually find more effective for seeing what's happening when. Is there a plugin for this?
@@marcuswest8085 I know there's a few color libraries out there for different languages output but I'm not sure of any plugins out there directly otherwise as you have to print the color codes. When it comes to container scanning, Trivy does a much better job for colorizing output
@@dreamsofcode Unscrambling code is quite complex. Do you have a preferred technique? The terminal is (for me) way better than internally. I am edging towards your Patreon...lol
Yup, this is not surprising to me at all. This is what happens when you take the responsibility of updating core OS components, libraries, and other parts of the environment away from the distro maintainers and sysadmins who are quite security conscious, and give that responsibility to the application developers who are not. The developers would rather just use something that they know works instead of updating. Software packaging is an unsolved problem - perhaps an unsolvable problem. Whenever people tell you that containers are the be-all and end-all of software packaging, remember that there is no such thing, only trade-offs.
100%. I do believe adding this responsibility to automation pipelines helps sysadmins and maintainers to scale. But there will always be another cost or problem associated with that solution
Also I believe that the vulnerabilities are caused by the software (libraries, packages, etc) running on the containers so this would apply to basically any machine that runs the same versions of the used packages? Another topic that would have fit is what happens if the app is deployed to a dedicated machine without container, wouldn't the same vulnerabilities still apply as the packages are still present? The topic itself can be interesting but in my opinion it did not go too deep into it, either way the videos are always high quality so I watch anyway, thank you for that
@@frann8487 That's something I could have done better to explain! The main issue with containers vs traditional deployments though is you likely have a greater variety of docker base images. When it's just your app being deployed amongst others on a VM/Machine, then you only have to update the VM/Machine and all of the apps benefit. With containers, you'll need to update every container image explicitly.
See NordPass Business in action now with a 3-month free trial at
nordpass.com/dreamsofcode with code dreamsofcode
C++ neovim pls
@@spinoscythe 😅 it's coming soon I promise
Please make video on how to install arch linux and i3 config so that your viewers can all say we use Arch btw
Fantastic video!! Would be awesome to see a continuation on how to integrate that within a deployment process! Thanks a lot for the content 💪🏼
I'm glad you enjoyed it! Thank you for watching
THE THUMBNAIL IS JUST 🤌✨
Thank you. I drafted a rough copy and had a wonderful artist turn it into something much better. My original version was terrible in comparison 🤣
@@dreamsofcode
@@dreamsofcode would love to see that 😅.
@@kapilpokhrel3841 It's on my discord! If you join and message me I'll send it to you also haha.
Another great video. On top of that I'd add I am observed variations in container scanner results. Remember that scanners are based on database of vulnerabilities and some of them update more frequent than others, or simple, has a different logic when scanning. Having said that I'd encourage pick the top 3 free scanners out there (Trivy, Grype, Snyk) and double check your scanning results. (you can build a Python script to consolidate the scanning and even build into a pipeline).
The reason why these discrepancies are common relies in the fact how scanners logic runs. I've been found earlier that Snyk doesn't work well with stripped binaries on containers (for instance, when the container builder decided to remove some metadata of the container in order to make it reduce the size of the image).
@Dreams of Code ... awesome material ... I'd improve this video in the future using Trivy instead Grype since Trivy scans secrets along with the process of containers scanning. =)
Thank you! I'm a huge fan of Trivy and it's my preference as well!
I went with syft and grype for this video to mainly for educational focus on the two distinct parts, sboms and scanning.
Trivy can also do sboms but i didn't want to go into too much detail about it as I've got a video planned for Trivy in the future 😁.
The aggregation is a great idea. It's something we've been considering as it's hard to be comprehensive without it due to the differences.
Good video, I really liked the topic. I use docker all the time and did not know this was that much of an issue
I didn't know either until I went to Kubecon last year and it was part of the keynote. Since then it's gotta worse (~76% -> 87%)
This is incredibly well made! Graphics, script, everything!
Thank you! I'm proud of this one. The topic wasn't as interesting it seems but I really enjoyed making this one!
I'm glad you enjoyed it 😀
Thanks a lot, once again! I really love your introductions to different tools! And your animations are amazing, as always!
Personally, I find that the short sound effects you added detract a bit from what you are saying and I'm glad you didn't use them as much after the intro. (Just wanted to let you know in case you plan to add them to the rest of the video as well... but then again, perhaps it's just me. :-)
Thank you for the feedback! I'm still trying to get the mixing right and was probably too loud on some of them! I make sure to keep them out of any instructional parts though.
I'm glad you liked the video and I'll try to do better!
Thank you. Would definitely like to see how to integrate with CI/CD
This video should be on the watch list of every DevSecOps engineer, good job!
very usefull and thank you for making this video
I am happy to see some of my images that run go apps have zero vulnerabilities according to grype where as others that use bigger, lets say more feature rich base images not so, er, well, some vulnerabilities there then, ahem.
So there is a lot to be said for small containers running go, rust, ( insert here other compiled and perhaps statically compiled ) that use base images that are as minimal as possible if you want them to 'stay young and beautiful'.
Docker has a static scanner, and then there's Docker Scout too. But it always good to have alternatives
Great video, I recently discover your channel and I've learn a lot from you.. May I ask you, what zsh theme are you using? Greatings from Cuba 💪🏼
Thank you! I use ohmyzsh with powerlevel10k! It's really nice :)
Fantastic video! Thank you! It is very eye opening to scan through my images!
Glad it was helpful!
Fantastic video! Waiting on the video with build automation!
I'm looking forward to doing some CI/CD content soon!
Each time I see one of your videos I try to make my terminal closer to yours. 😂😂
The bar of the bottom of the terminal is an ohmyzsh plugin?
The bar at the bottom with the number "1" on the far left is the status bar from tmux with the catppuccin theme, he shows the setup in his video on tmux: "Tmux has forever changed the way I write code."
It'd be really cool if you could dive deep into how containers work under the hood
Is this more applicable to container maintainers or to admins deploying a container? You should vet containers you're going to deploy, but having to update dependencies/packages yourself before deploying seems too much. Even though I just started working professionally, I prefere setting up VMs and applications up from scratch. Repos for newer versions etc. in hindsight it might be just as much work
We use container scanning in our CI/CD pipeline and basically block any images that have a fixed issue from being deployed. We have someone who is responsible for security, but adding this as automation allows us to scale with security.
So, to answer your q: It depends!
I'd say both.
As a maintainer you want to make sure you are keeping up to date with issues of your dependencies, so the image you deliver stays more secure.
As an admin you want to make sure you are deploying up to date versions of your container images, and might not want to trust the maintainer to keep things secure. You can then raise issues to the maintainer, if there's something critical to fix, or look at alternative images/projects altogether to satisfy your workload.
Very nice video.
But to play devils advocate here: "An image has components with vulnerabilities" is not the same as "An image is exploitable". Many of the vulnerabilities, even those categorized as HIGH, are not exploitable in practice. So while the 87% sound very very bad, it does in no way mean that 87% of the images can actually be exploited in the field if they are deployed. (Assuming that the 87% is just counting images that have components with vulnerabilities.)
This of course doesn't mean we should just ignore vulnerabilities. The scanners are very useful and should probably be used by pretty much anyone. I'm just saying that things are often not as bad in practice
You're correct. Not all vulnerabilities can be exploited. Deployment models, networking and isolation from the vulnerability mean that not every container is exploitable even if it has a high or critical vulnerability. I also strongly agree that it's not a good practice to ignore them as it can cause the broken window effect.
I don't believe I said 87% of images are exploitable though. Only that 87% have high or critical vulns, as per the source.
Man, your videos are so good!
Thank you!
This video proves that my choice of subscribing youtube channels is freaking awesome!
Thank you! I appreciate that.
Would have been cool to include Dive and anything similar to that in this also
Dive is awesome! I'll have to do a video on it. Thank you for the suggestion
Awesome video. Thank you!
Thank you for watching!
But these issues weren't about the docker rather the OS or software that being used. Also, using docker, opens up the opportunity to scan the OS, which it wasn't the case back in the day we just trust the server provider's OS without even scanning or ability to modify it as easy as docker Images.
thanks for sharing the scanning tools though.
Oh absolutely. Docker has been amazing but the complexity is still the main issue, and there's way more containers than base OS's now than there used to be.
Fortunately, container scanning is providing a great solution and I agree, it's great that we can do it now.
Hello @dreamsofcode this is already new feature in Docker under function Docker Scout, am I right?
Thanks for this video. I need to scan my containers 😅
You're welcome! I was shocked what I found in mine!
❤high quality videos as always
Thank you, I'm glad you liked it!
Just upgrading to the latest version brings in new features that must add new vulnerabilities. This is like sticking your head in the sand and then claiming you are now far away from the beach.
You're not wrong. But the main difference is that those vulnerabilities are yet to be discovered by both malicious actors and maintainers. Once they're discovered they're likely to be exploited.
Generally speaking, most of the people discovering 0-days are government affiliated organizations, which we have very little insight into, or security researchers, who tend to disclose as soon as they discover. Malicious actors rarely discover 0 days themselves and usually take advantage of poor upgrade cycles to exploit already known vulns.
@@dreamsofcode Assuming malicious actors havn't read the source code is a mistake.
Is there any pros of using snyft+grype against snyk or trivy, for example?
Syft is great for sboms so you'd probably use that by itself. I prefer Trivy over grype personally as it provides better scanning results, in my opinion. You can use Trivy direct, or with the sbom, which allows you to check it against already deployed services periodically.
which DE are you using ?
what desktop environment do you use ? (I know arch btw, whats the de)
I record using Gnome, but I use sway for my day to day. Mostly my videos are just my Alacritty window which is themed with Catppuccin!
Amazing video
Thank you!
I love you man
Thank you!
C++ Neovim with clangd pls!
It's coming in 8 days!
@@dreamsofcode with clangd and cmake?
@@spinoscythe clangd yes, cmake no. I'll be saving both Make and CMake for other videos.
@@dreamsofcode ok, ty for your efforts
Which Desktop Environment you use on arch ?
I use gnome on arch when recording!
@@dreamsofcode okay thanks man! Nice video
When video about Arch ?
It's coming! Anything you'd like to see specifically?
@@dreamsofcode How to achieve a comparable look, like you did with tmux and nvim. Your videos are very simple and well done, which helped me start playing with the previously mentioned programs.
@@hades_2.042 my terminal is Alacritty and my theme is Catppuccin!
My containers are completely 100% safe
- Me, 2023, running a couple of containers in --privileged mode
Before you ask, it's because it's needed to get hardware acceleration to work
💀💀💀
Hey my eyes are paining😢 when was java configuration is coming😢😢please atleast tell me the date..
😢😢reply😢
It's still in the backlog I'm afraid! It'll probably be end of July early August. Thank you for being patient with me 🙏
@@dreamsofcode that long🥺🥺i thought next video💔💔
@@Ashaiksameer it'll be worth it when it comes! ❤️
Are you thinking of creating a container with your setup in it?
This is a good idea.
@@dreamsofcode Elliot old chap, I made a file for different coloured outputs....I find it helps with debugging. Running pdb from the Terminal is okay, although a bit knotty, but colour-coding my output, red, blue, yellow, green e.g.- def printblue(text):
print("\033[34m" + str(text) + "\033[0m") - I actually find more effective for seeing what's happening when. Is there a plugin for this?
@@marcuswest8085 I know there's a few color libraries out there for different languages output but I'm not sure of any plugins out there directly otherwise as you have to print the color codes. When it comes to container scanning, Trivy does a much better job for colorizing output
@@dreamsofcode Unscrambling code is quite complex. Do you have a preferred technique? The terminal is (for me) way better than internally. I am edging towards your Patreon...lol
Yup, this is not surprising to me at all. This is what happens when you take the responsibility of updating core OS components, libraries, and other parts of the environment away from the distro maintainers and sysadmins who are quite security conscious, and give that responsibility to the application developers who are not. The developers would rather just use something that they know works instead of updating.
Software packaging is an unsolved problem - perhaps an unsolvable problem. Whenever people tell you that containers are the be-all and end-all of software packaging, remember that there is no such thing, only trade-offs.
100%. I do believe adding this responsibility to automation pipelines helps sysadmins and maintainers to scale. But there will always be another cost or problem associated with that solution
I want your wallpaper
It's really nice that one! Here's the link to it: www.freepik.com/premium-photo/colorful-background-with-blue-orange-waves_44749050.htm
@@dreamsofcode my Arch is a few steps behind to yours😁
But i don't know why
Me neither!
I really like the way your videos are made but the topic was not that interesting
I respectfully disagree. I think all the topics are interesting, as they can get you thinking about something that's not occurred to you before
@@regreegg You're right
Thank you for the feedback. Is it the topic of docker that is uninteresting, or is it security / container image scanning?
Also I believe that the vulnerabilities are caused by the software (libraries, packages, etc) running on the containers so this would apply to basically any machine that runs the same versions of the used packages?
Another topic that would have fit is what happens if the app is deployed to a dedicated machine without container, wouldn't the same vulnerabilities still apply as the packages are still present?
The topic itself can be interesting but in my opinion it did not go too deep into it, either way the videos are always high quality so I watch anyway, thank you for that
@@frann8487 That's something I could have done better to explain! The main issue with containers vs traditional deployments though is you likely have a greater variety of docker base images. When it's just your app being deployed amongst others on a VM/Machine, then you only have to update the VM/Machine and all of the apps benefit. With containers, you'll need to update every container image explicitly.
This is the way 🦾