Beginning with the Log4J problem in the past, the focus comes up to security, so how we make sure that the program is secure against the actual known CVE?

Yes in a build System, for this I use trivy a very handy program and easy to integrate, for example in your DevOps pipeline. I use Azure DevOps for my development, but you can apply this to any other DevOps software if you want.

What is Trivy?

Trivy is a comprehensive and easy-to-use open-source vulnerability scanner for container images. So when you want to scan your container images for actual vulnerabilities, this free tool is your first choice.

Integrate it into Azure Devops Build

So now the practical part of this post, first of all, you must install trivy into your pipeline with this task

Then you must build your Image and can tag them and so on. After this, you can run the trivy scan against the generated image with this task

So when you execute this, you will get a scan output like this:

Nice, you see now the scanned results and you will see if your image contains any critical vulnerabilities. Let's modify the parameter a little bit to get two scans executed. The first scan will display only the medium or high classified vulnerabilities but this will not fail the build. But the second scan will scan for the critical vulnerabilities this scan will fail when one of them will occur. For that, the scanner contains a parameter called severity. here is the adjusted code

Now you get two runs for this, the second run will fail if any vulnerability will be found because it will exit then with code 1.

You got a nice first look into trivy, but that's not really helpful. Let's assume you have several container builds and you must look every time in each build to check if there is some vulnerability that exists that affects your system directly.

Export results as the Test result

We test the images for vulnerabilities, so then it must per definition show up in the "Testreults" of each build. But how we can place the results there?

Fortunately, Azure DevOps contains a publish Test results task. This supports different test result types, especially JUnit.

Good to know, the next step for us is to export the nice result table as a JUnit result file (it's an XML file). Luckily Trivy got a parameter to export the data into a JSON format, also a custom format applied by a template.

The report template

To generate a JUnit formatted output, I can set the template as a string in the template parameter.  But that will not really be maintainable, so I use a separate template file for this and reference it via the path (Prefixed with an @).

For example, my Template is designed like this

I saved it in my project root under the folder "templates". This template will create failure results for each found vulnerability.

Integrating the export template into the scanning result

After you created and stored the template you must only reference them into the export command from trivy. In my example, I use the second scan to get insights about critical vulnerabilities. So I adjusted the scan command to this.

The result will be the same as before, but for the second run it will not display the result in the console, it will export the result as a JUnit report and store it in the file junit-report.xml.

Finally, you must only upload the result into the azure DevOps with the public test result task:

This will look into all folders for every JUnit XML file. And upload them into the AzureDevops test results. For example, it may look like this:

Conclusion

Trivy is a nice handy tool, it will allow you to check your images for vulnerabilities. So you can have an early insight into your system security, before any security issue may occur. On the other side, you get a known issue list for every audit, and maybe you can explain then why can accept some vulnerabilities

Did you like this article? Then maybe you can send me some Ko-fi

Also, you can subscribe to my free Newsletter!