In this demo, we're going to review a proactive Trivy integration.
We're also going to use GitHub Actions to integrate
Trivy into the code review process.
We're also going to look at a consumer view.
In other words, when an engineer is submitting code changes,
what does this process look like to him or her?
We're also going to look at this from a technical viewpoint, in other words,
look at the underlying configurations and scripts that
are powering the proactive integration.
In the previous diagram, or in other words,
the reactive workflow diagram,
we witnessed Trivy auditing Docker images within the Docker Registry.
We started with this approach for simplicity,
but now it's time to up our game and move from a
reactive to a proactive approach.
Trivy can audit Docker images in other places too.
For example on my personal machine,
I can build a Docker image and store it locally.
Then I can use Trivy to audit that local image.
By extension, we can use GitHub Actions to perform this task as well.
Behind the scenes,
GitHub Actions can create an Ubuntu server that is
hosted within GitHub's infrastructure.
We can then use that server to audit for changes before
uploading the Docker image to the Docker Registry.
Even better, we can see the results of this Trivy scan within the pull request.
This allows an informed discussion to occur before incorporating the changes.
Remember, GitHub Actions as an isolated environment where we can run custom code,
and it's awesome that we can take advantage of all of
this from a security perspective.
As we previously stated, we'll start with the consumer view.
In other words, when an engineer is submitting some code changes,
what does this process look like?
Let's assume that we are an engineer trying to
propose new changes for a Dockerfile.
In this command,
we go ahead and switch to an updates branch so we can isolate our changes.
This updates branch correlates to the updates branch in the previous diagram.
Let's go into the Dockerfile and make some changes.
First off, we're going to add some additional apt‑get installs,
for example, Apache and wget and build‑essential.
We also are going to install a version of libSSL.
Remember, this can be basically anything that you are installing.
I'm going to go ahead and save the changes.
At this point,
I'm going to go ahead and commit the changes and push them up to GitHub.
So we are in the GitHub UI.
We see the updates branch recently had some changes.
As an engineer,
I want to create a pull request so my teammates can
discuss these changes with me.
Perfect.
It looks like we are trying to merge our changes from the
updates branch into the main branch.
I'm going to create a pull request.
Now we see the GitHub Actions running.
While we wait, let's go ahead and look at some of our differences.
So the first item I actually changed outside of this course
just to make things a little bit more clear.
Perfect,w e see the Dockerfile being updated.
Notice the new versions of libSSL that are being added.
We'll check this out in the Trivy output.
I'm going to go ahead and click on Details.
Interesting, this red here doesn't look good.
Let's expand the Trivy execution step.
At the end of the output, we see This Docker image contains a vulnerability!
Please fix!
Okay, let's see what vulnerabilities were introduced.
There's 148 vulnerabilities in this image.
Interesting, so we see the libSSL library has a bunch of vulnerabilities.
And you see the installed version?
That correlates to the installed version that we
were adding within the Dockerfile.
We also see the fixed version as well.
This would give us, the engineer,
actionable insight into how we can fix this vulnerability.
And once again, we see the Heartbeat extension packets.
This correlates to the Heartbleed vulnerability that we saw in our first demo.
Let's go back into the main pull request view.
Let's go ahead and refresh.
So we see the status checks have failed.
While it's not overly evident right now,
this will actually prevent the changes from being accepted.
Let's look at the configurations that are driving this blocking behavior.
Going to click on Settings.
Then I'm going to click on Branches.
Check this out, Branch protection rules.
Define branch protection rules to disable force pushing,
preventing branches from being deleted and,
most importantly, optionally require status checks before merging.
Here, let's dive into this a little bit deeper.
So the first rule enforces that another member of
the team must approve the changes.
Also we see that we require status checks to pass before merging.
The Scan Docker images workflow that we define actually is a status check.
In other words, this workflow must pass in order for us to merge the changes.
By us activating the security control,
we can block vulnerable Docker images from going into our environment.
Let's go back to the main UI.
So at this point it says merging is blocked.
Merging can be performed automatically with one approving review.
Now this is a little confusing.
If we had another approver on the team that approved this pull request,
it would then still block because the Trivy status check has failed.
Since I'm an administrator on this repository,
I can override these settings, but obviously,
normal users are not going to have these elevated permissions.
Okay, now let's simulate how an engineer would fix this issue.
Okay, let's go back into the Dockerfile.
First off, in the Trivy output we saw that this version of libSSL is vulnerable.
Let's go ahead and comment this out.
And actually behind the scenes,
this Docker image has the correct version of OpenSSL that is not vulnerable.
So as an engineer,
we clearly just made a mistake and just added in a library that wasn't needed.
I'm going to go ahead and save the changes.
Then after this we simply commit our changes and push it
back up to GitHub. So we're back in the GitHub UI. Let's
check out our Dockerfile updates.
Well, whoa, check this out.
We also see a green checkmark. That looks promising.
Okay, great.
So we see that all status checks have passed.
Now, at this point,
the only thing that is blocking us is the additional
approver that we are requiring.
And you might be wondering, well,
why do we need this additional approver if Trivy has given us the thumbs up?
Well, it's kind of complicated. So Trivy has strengths in certain areas,
but it cannot detect all vulnerabilities that can be introduced into a
Docker image, and for that, we'll actually need an additional human
approver to glance over the pull request.
Now, as far as what types of vulnerabilities Trivy cannot detect,
we're going to see an example of this later on in the course.
Now before we go ahead and merge this pull request.
It'd be great to look at this from a technical viewpoint and see what
scripts and configurations are powering this workflow.