Okay, let's get started.
Now, we see various commands here, scan an image,
scan the local file system, scan remote repository.
Trivy has a lot of options, but for the purposes of this course,
we're going to hyper focus on the image command.
Let's go ahead and scan an image within Docker Hub.
Let's scroll to the top.
First off, we see Trivy complaining that we're leveraging the latest tag.
Right now it's okay because we are not changing the underlying Docker image.
Into the future, we are going to clear the cache during the docker build process.
We'll see this into the future, don't worry about this now.
As we inspect the vulnerabilities, oh my goodness, 711 vulnerabilities.
Wow!
Okay.
If I was an engineer and I was getting this report,
I would be somewhat overwhelmed.
We need to take an iterative approach and prioritize these vulnerabilities.
To do this, let's explore more command line flags.
Okay, let's hop into the help text for the trivy image command.
Okay, as you can tell, Trivy has a lot of different flags here.
For the purposes of this course,
we're going to focus on the ‑‑severity and ‑‑ignore‑unfixed flags.
I highly recommend you check out this help text on your own and
familiarize yourself with all of the Trivy options.
First off is the ‑‑severity flag.
You might be wondering, where does this severity come from?
And the answer, as always, is it depends.
It depends on the vulnerability feed in which Trivy uses. For a
given vulnerability, severities can be defined within the National
Vulnerability Database, or NVD, and by the vendor themselves. For
example, for Ubuntu packages, Trivy leverages Ubuntu vulnerability
feed. In other words,
Ubuntu is the vendor. As Ubuntu can publish its own severities, Trivy will
favor these ratings over the ratings in the National Vulnerability Database.
And next off is ‑‑ignore‑unfixed. Right now, we just want to prioritize
vulnerabilities that have a fix available.
Okay,
so we see we are filtering on a severity of critical, high, and
medium, and we're leveraging ‑‑ignore‑unfixed.
Let's check this out.
Okay,
I'm going to scroll to the top. Phew! We went from
roughly 700 vulnerabilities to about 167.
It's still a lot, but you know what, it's a little bit
easier to sift through compared to the 700.
Now,
the one in front of us looks pretty critical. In libssl,
we see the installed version 1.0.1e‑2.
All right, we also see the fixed version as well.
Let's scroll down a little bit and see some of the other libssl vulnerabilities.
Uh‑oh,
this looks like the Heartbleed vulnerability that allows
unauthenticated attackers, in certain cases,
to view the memory of a machine. Phew! We need to fix this,
and we'll do this in the next demo. Before we move on to the
next demo, let's do a recap.
We reviewed a reactive Trivy workflow.
We explored Trivy's various command line flags,
including ‑‑severity and ‑‑ignore‑unfixed.
We also leveraged Trivy to scan a Docker image and saw a nasty Heartbleed
vulnerability. Now as far as the workflow cons, in my view,
this was kind of a reactive measure.
In other words,
Trivy was scanning these Docker images after they had been released.
Ideally, we would want to take a more preventative approach.
In other words, there would be a Trivy scan within the release process.
And if the Trivy scan failed,
we would prevent the Docker images from being uploaded to
the Docker registry. In the next section,
we'll explore more preventative or proactive approach.