The Trivy scan that we just witnessed is powered by
a GitHub Actions workflow file.
Now GitHub Actions expects workflow files to be within the workflows directory.
The workflow name can be anything you choose.
Let's go through the workflow.
As a brief recap, before modifying the code within a GitHub repository,
a peer review must occur.
This peer review occurs within a pull request.
When a pull request occurs,
this workflow will use Trivy to scan for vulnerabilities.
If you want more context on GitHub Actions and this workflow file,
I highly recommend checking out the link on the screen.
This is also in the course notes.
And we also see some assumptions.
We've already gone over these.
First, we see that we run the workflow when new changes are proposed.
We also see that the workflow runs within an isolated execution environment,
in other words Ubuntu 2004.
The first step is we allow access to the Trivy tutorial Git repo.
Then, we install Trivy using the installation script that we've already seen.
Then, we go ahead and execute the docker‑scan script.
We'll check out that script next.
So this script checks if a Docker image has vulnerabilities via Trivy.
This script expects the following convention.
In particular,
the repo name corresponds to the repo name within the Docker Registry.
And also,
this convention is shared with a docker‑registry‑orchestrator script
that we're going to see later on in this course.
This script uploads Docker images to the Docker image registry,
and that's why we need to have this repo‑named convention.
The second assumption, script should be triggered on pull requests,
and the third assumption,
Docker image changes in Git must be approved by a trusted entity,
should make sense based on what we've already covered.
Let's scroll down to the main logic.
Here, we iterate through the Docker configurations.
The path convention was outlined in assumption number 1.
We make sure that we only iterate through directories.
Then, we get the absolute path for the Docker configurations.
This will power the Docker build context.
Next, we see the local Docker image build.
Now here's something that's really important.
We ensure that Trivy does not scan a cached image.
This was a warning that we saw previously in this course.
And just to be extra paranoid, we make sure that Trivy purges its internal cache.
We only want to scan the current Docker image, not an older one.
Next, we see the Trivy scan being executed.
We are leveraging the severities that we already
defined and also the ignore‑unfixed.
Into the future, we will make our blocking behavior more granular.
And also, if a vulnerability is found, Trivy will emit an exit code of 2.
You'll see how this is useful really soon.
In the first if block, if Trivy has an exit code of 0,
that means that the scan was successful and that Trivy
did not have any unexpected errors.
And then we simply continue to the next set of Docker
configurations that need to be scanned.
Remember,
all of this code is within a for loop that iterates through all of the
Docker configurations that are defined within the repo.
In the second if block, if there is an exit code of 2,
we know that this Docker image contains a vulnerability.
Then, we simply tell the engineer what needs to be fixed.
And then when we exit with 1,
that tells GitHub Actions to fail the status check and thus
block the pull request from being merged.
Now what happens if there is an unexpected error?
This else block will then be activated.
Once again,
we exit with a status code of 1 so we don't allow any
vulnerabilities to be potentially introduced.
So now we're almost at the end of this demo,
so let's do a little recap on what we've just seen.
We reviewed a proactive Trivy integration.
We used GitHub Actions to integrate Trivy into the code review process.
And then we saw the consumer view.
We saw Trivy within the pull request within the GitHub UI,
and we also checked out Trivy's enforcement settings,
such as the branch protection rules.
Then we also checked out the technical viewpoint.
This included the GitHub Actions workflow file and
also the Docker build and Trivy scan.