‫All right.
‫The next up, code repo scanning.
‫This is not even Docker specific, but there are tools out
‫there and Sneak is
‫one of them. Sneak, will scan your
‫code dependencies inside of repos.
‫If you have open source, if you're developing an open
‫source, they will do a lot of this stuff for free.
‫They will scan your GitHub repo, your Bitbucket
‫repo and look at the dependencies.
‫I get reports every week from them on my open source repos
‫and any vulnerabilities they found.
‫Nowadays, GitHub does a lot of this themselves
‫for free as well. Sneak has
‫been around longer and been doing it longer, so I kind of
‫have both. I have GitHub sending me emails and I have
‫Sneak. You can pay Sneak to scan stuff.
‫They also have more features now where they're doing images
‫as well and other things, not just code repos.
‫But, that's one line is scan your
‫repos early on in the process.
‫Don't wait for you to build images and then have things in
‫CI, you know, in testing where you're
‫scanning. Scan as early as possible.
‫This is kind of one of the core tenets of something
‫called ShiftLeft security.
‫If you imagine a Kanban Board where all
‫your work is on the left and your output is on the right,
‫the ShiftLeft security movement, if you just kind of search
‫around for ShiftLeft security, is all about shifting
‫the responsibility of security earlier and earlier in your
‫development workflow.
‫So, one way to do that is to have these automated scanners
‫scanning your code dependencies inside your git repos
‫before you ever even get to the stage of running stuff
‫on servers, right. I would do that.
‫Not specifically a Docker thing, but I would do that.
‫The next step is image scanning itself, which
‫is very similar to that. But, we get more features here.
‫We aren't just scanning your code dependencies.
‫We can scan the container itself.
‫The image, right. We can scan all the dependencies there
‫that are not just like your npm packages
‫or your, you know, Python
‫packages. You're now scanning YUM packages,
‫and APK, or apt,
‫or these kind of package managers for the OS.
‫That's what I mean by an image scanner, because it can scan
‫those as well as your code dependencies.
‫So, there's a lot of tools here.
‫A very popular set of them have been around a while, but a
‫couple of new ones have shown up that I want to talk to you
‫about.
‫The first one here is Trivy, and I just learned about this
‫this month,actually in October.
‫Trivy is built by Aqua Security, who is the same company
‫who builds MicroScanner.
‫MicroScanner was one of the tools, along with a lot
‫of other ones, Anchor as well, another popular one.
‫These are all open source tools that scan your image for
‫CVE vulnerabilities.
‫The CVE is that database of all the open source donor
‫vulnerabilities that we all hear about in the news.
‫It's from Mitre, a company that manages that database.
‫This is a community thing, right.
‫Anytime someone finds a vulnerability in software, they put
‫it in and it gets a CVE number.
‫It's common vulnerability
‫and exploits, something like that.
‫I can't remember exactly what CVE stands for.
‫I'm sure one of you will tell me in chat.
‫But CVE gets a number, right.
‫We see a number assigned to that known bug in the
‫community. A CVE scanner will scan your images
‫for that vulnerability.
‫Once you get into the implementation of these, there's all
‫sorts of minutia, like does the scanner you have
‫need to run in the Docker image during build time?
‫Or does it scan an image that's already built?
‫Does that scanner support
‫your base distribution? Does it support Red Hat?
‫Does it support Alpine?
‫Any sort of other distribution images that you've
‫chosen to use, will it support those?
‫Does it also support your package manager for your app
‫like npm or pip, or
‫one of the other dozens of package managers out there,
‫right. Does it does it support those as well?
‫MicroScanner didn't do
‫all of that. It did some of it, but like a lot of these
‫other tools in the ecosystem, they didn't do it all.
‫Right now, this one from
‫Aqua Security
‫called Trivy, get all the way to the top of this thing.
‫Trivy is claiming they're the most
‫complete open source free scanner out there.
‫Down here, you'll see what they support.
‫You'll notice that they support all these based images.
‫Then if you actually go down, there's
‫a comparison showing them comparing to all the
‫other tools, or least the popular open source versions of
‫these tools. There's definitely more tools than this.
‫There's lots of choices you have to make here.
‫One choice is where do I want to scan?
‫Do I want my image repository to scan them itself, like
‫Docker Enterprise DTR does?
‫Where you have a registry holding your images
‫and that registry runs scans on the images in
‫the registry itself all in one go.
‫Quay does this as well. Quay is a cloud hosting image
‫repository and it will also scan, right.
‫Each one of these scanners doesn't always scan all
‫image types and all app dependencies.
‫So, it's pretty cool here that they show...basically
‫the X means they don't do it.
‫The 0 or the O there, the circle, means they do do
‫it. Then, I think the
‫double OO here means the best,
‫and the triangle means there's issues,
‫there's concerns there.
‫So, they're kind of claiming that Trivy, which they bought
‫this year, I believe. Trivy does
‫it all. It does OS packages, application dependencies.
‫They claim it's easy to use.
‫They claim it's more accurate. If you start reading into
‫this, you realize that one of the big issues that I keep
‫talking about is that Alpine's base image doesn't
‫work with almost all these scanners.
‫It just doesn't have the vulnerability database connected
‫to it properly so that when you run these scanners, it
‫detects vulnerabilities in Alpine.
‫Trivy claims that they fixed that by a
‫new method that they're implementing, and we'll see if
‫other people implement that as well.
‫They claim to be the most complete.
‫A lot of my Docker Captain friends are all saying they're
‫using it and using it great.
‫One of the other decisions, besides which scanner, is
‫where will you scan?
‫I like to scan during image build.
‫I'd rather scan during the CI automated
‫image build than scan it later after the image is built.
‫That's just me.
‫You might even have different systems that scan at
‫different times, just to be safe, right, just to be
‫certain. You might have systems that scan on the servers
‫that are running in production, depending on
‫your environment. That's not very common.
‫But, if you're in a super secure environment that you want
‫to scan things running live, you can certainly do that with
‫some of these tools.
‫A demo that I often give is about
‫MicroScanner. Essentially, all you have to do in
‫MicroScanner, as well as this other tool,
‫is in MicroScanner, you can add it into your Dockerfile.
‫I believe the Tivey app, you scan
‫after the image is built.
‫If you're super paranoid, you might just use
‫a MicroScanner inside your Docker image.
‫Then you might run something like Tivey after the fact
‫on the images before they're sent up to the registry, you
‫know. You can always download them later, but I like to
‫know that my image is vulnerability free before
‫I send it up.
‫So, that's what you might do there. Now.
‫I want to just tell you a warning.
‫You're probably not going to have any...you're
‫probably not going to have any images, or maybe just a few
‫images, that have zero vulnerabilities across
‫the board. That's just due to the nature of
‫open source. Typically, if you scan any image,
‫typically, if you scan any image out there,
‫it's going to have vulnerabilities.
‫It's your job to work with your security team on
‫what's acceptable, not we can never have vulnerabilities.
‫Because certain vulnerabilities may not even apply to you.
‫Just because they're in your image doesn't mean that
‫they're automatically going to be a problem, right.
‫You're going to have to do some
‫work. I think what I would suggest is implementing these
‫now, but turning off the sort
‫of failure of it and say continue on failure
‫here, which means all I'm going to do is warn you that
‫there's vulnerabilities. I'm not going to stop the build
‫just because there's a vulnerability.
‫This is key, because if you start implementing all these
‫tools automatically, they will fail the process.
‫They'll fail your CI, or they'll fail your builds, if
‫you just turn them on. You want to make sure that you have
‫them in sort of audit only mode where they don't fail
‫on finding a vulnerability.
‫That way you can at least learn what the vulnerabilities
‫are before you start, you know, before you go hardcore,
‫right? Before you go hardcore.