DevSecOps Series VI - Container Security Scan

May 18, 2025 // echel0n

Hello guys! This is the last blog in the DevSecOps Series! In this post, I will give some details about what Container Security Scan is and why it is important, and then I will show you an example of a local deployment of Trivy with the Jenkins pipeline step. Hope you enjoy it!

Table of Contents

Used Tools, Tested Hardware/Software and Warnings
Container Security Scan
The Action - Installation of Trivy

0 Used Tools, Tested Hardware/Software and Warnings

Some configurations here and in the repository I referenced may be insecure, and it is recommended that you act with awareness. Since this is a lab environment, we will not be making many security configurations of the tools.

These are the tools we will be setting up. (Check previous blogs if something is missing!)

Trivy as a Container Security Scan Solution

Provided configurations are tested in this hardware and software;

CPU: AMD Ryzen 9 5900X (24) @ 5.619GHz 
Memory: 23904MiB 
Swap: 4GB 
OS: ArchLinux 6.13.8-zen1-1-zen
Terminal: 5.2.37 
Docker version 27.3.1, build ce1223035a 
k3s version v1.31.3+k3s1 (6e6af988)
go version go1.22.8

This setup is using a lot of resources. Be careful after deploying the tools, as they can quickly exhaust your resources. Do not forget to save your critical data while the instances are running. I am pretty new to Kubernetes so I am open to fine-tuning suggestions, please feel free to get in touch, it would be great to learn more!

1 Container Security Scan

1.1 What is it?

Container Security Scan is a scanning method focused on identifying issues in a container. This scan scope is all the components in the container image, which includes; packaged base os system, libraries of the application, pre-installed software in the base image, and some of the solutions can have checks against HIPAA, PCI/DSS and NIST compliance to let you know what is wrong with the configuration of Dockerfile or containerization itself.

This scan mostly relies on CVE databases or other known vulnerability sources and not much else. The solutions will let you know also which components are outdated too. Similar to SCA, if you configure it harder, you will be able to gather and create your SBOM inventory. You will gain x-ray-like visibility into your deployed containers and their network, depending on which Container Scan solution you use.

There is no standardization about what "Container Scan" scope is. It is again a pay-to-win concept that every vendor labels their solution as "Container Security" with their own flavour. To this day, I used 3 different Container Scan solutions: Twistlock from Palo Alto, Smartcheck from Trend Micro and Trivy from Aqua Security. Smartcheck and Trivy offer similar capabilities but Twistlock is waaaaaaaaaaaay more advanced solution than most of the tools available. Let's say, Prisma Cloud (Twistlock is included) is a suite or tool-box for entire cloud security and its concerns. It includes a RASP, native firewall, secret scanning, compliance checks, open-source policy checks and a vulnerability management console. It is being installed top on OpenShift or Kubernetes directly and you will be able to do all cloud security operations from there. It is apples versus pears, I know, but what I really mean that when someone mentions container scan or container security, they may be referring to different part of the container security, so do not be confused about it!

For this time, the container security is just the container itself, just before deployment. The scope is what you have bundled with the application, that is it.

1.2 How?

Basically, the filesystem reveals most of the information. It checks every pre-installed application package, os version and application's files. From application files, it can tell which libraries are in-use. Similar to SCA, you can also see a library report too.

1.3 Basic mind-set of Review of Container Scan Findings

The same rules apply as in SCA. You and the inventory define the context. Most of the time, you are the one making the decisions, so it is up to you to determine whether something is relevant or not. For example; The Container Scan software might report vulnerability in components like bash, apt and git etc. According to your threat analysis, they may not be a threat at all.

1.4 Some Caveats

1.4.1 Alert Fatigue

You will be dealing with a lot of alerts! I mean a lot! If your application inventory is large enough, you will be exhausted to look at every CVE and check if they are valid in the context of application. These alerts can become so overwhelming that you will be tempted to upgrade every component to the latest version whether it is necessary or not.

1.5 The Benefits

1.5.1 The earlier a vulnerability is fixed in the SDLC, the cheaper it gets.

1.5.2 You will be able to push the teams to use "Trusted and Verified Images" with the findings.

2 The Action - Installation of Trivy

I will just demonstrate how a minimal Container Scan looks like.

Since I will be using it (and probably you) on my own computer and my resources are very limited, I will be using Trivy in our pipeline in a way that is not very suitable for a real scenario.

Trivy is available in the official repositories of most Linux distributions. I have installed Trivy with pacman, you should be able to install the application from other repositories as well. Then, run this command to verify the installation:

trivy image nexus.local:4502/repository/dvja-app:latest

Alternatively, you can use "--format json" parameter to produce output that is easier to process programmatically.

The pipeline integration will involve direct scanning and saving outputs for future review. We will be experiencing it in its most primitive form.

// put this stage after Push Docker Image
stage('Image Security Scan') {
	  steps {
	    sshagent(credentials: ['SSH_LOGIN_HOST']) {
	      sh """
		echo "Starting Trivy scan on remote host...";
		ssh -o StrictHostKeyChecking=no root@${KUBERNETES_HOST} '
		  docker login ${NEXUS_REPO} -u admin -p 'wowsuchchar8!' &&
		  trivy image nexus.local:4502/repository/${DOCKER_IMAGE}:${DOCKER_TAG} \
		  --format table > /tmp/trivy-scan.txt &&
		  echo "<html><head><title>Trivy Report</title></head><body>" > /tmp/trivy-output.html &&
		  cat /tmp/trivy-scan.txt >> /tmp/trivy-output.html &&
		  echo "</body></html>" >> /tmp/trivy-output.html && sleep 5;
		'

		echo "Fetching Trivy HTML report from remote host..."
		scp -o StrictHostKeyChecking=no root@${KUBERNETES_HOST}:/tmp/trivy-output.html trivy-output.html
	      """
	    }

	    // Archive the report in Jenkins
	    archiveArtifacts artifacts: 'trivy-output.html', fingerprint: true
}

First, we SSH into the host machine, then log in to Nexus. Then, scan the image with trivy. After the scan, we generate a "trivy-output.html" file to present the results in a more readable format and save it to show in the CI/CD build as an artifact.

After the pipeline run; you can check the result from here.

Now, we have the information about which libraries are in-use and which pre-installed applications have (or could have) a security problem.

3 The End - Conclusion

As we are using just a lightweight Container Scan solution, we have a lot of information about our vulnerable application container. If we can achieve this much visibility even when using this solution, just think about more commerical services where you can get professional support! Even if you do not want to rely on more commercial tools, Trivy's output alone could be used to develop a middleware application that suggests relevant fixes and upgrades.

That's all folks! I have just finished my DevSecOps series. I am truly grateful to everyone who has been following this series for a while! If you followed up all the steps I have created and practiced, congrats to you too! You just had experienced minimal DevSecOps engineering 🎉 I hope you enjoyed the blogs and they have given you a new perspective. Months ago, since all of these were not explained in one place (and for free), I wanted to demonstrate it myself and help you guys to experience it. Actually, when I started, I had in mind to connect these outputs to Jira, but since it took too much time and I thought that basic Jira integration would not work most of the people, I decided not to do it. However, I am sure that if you want to achieve that from this point on, it is definitely a step you can take next! All files are available in the devsecops-series repository.

Again and again, I would like to express my gratitude to you, my readers, who follow my blogs, to the feedback and reactions you have given... thank you all.

Have a nice day you absolute legends!🎉🎉🎉🎉

References and Links

First Part - https://devilinside.me/blogs/devsecops-series-introduction
Second Part - https://devilinside.me/blogs/devsecops-series-simple-pipeline 
Third Part - https://devilinside.me/blogs/devsecops-series-iii-sast
Fourth Part - https://devilinside.me/blogs/devsecops-series-iv-dast
Fifth Part - https://devilinside.me/blogs/devsecops-series-v-sca 
Provided Configurations and Scripts - https://github.com/echel0nn/devsecops-series