Anchore Engine: Container image vulnerability scanning

Read Time:6 Minute, 5 Second

Applications nowadays, are usually deployed inside containers. A container consists of libraries and tools which allow the application to run inside. Since there can be exploitable vulnerabilities, it is not only important to take security into account for your application, but also for the container it runs in. There are various tools available to scan container images for those vulnerabilities. Having little experience with them, but recognizing the importance of having such a tool, I decided to give Anchore Engine a try. Why? Because it appeared popular when looking for tools, it has an open source variant which I can appreciate and it was very easy to get started with. In addition, it provides several integration options which make using it easy, such as a Jenkins plugin and a Kubernetes Admission Controller. In this blog post I’ll describe my first impression/experiences.

Getting started

Anchore Engine provides various ways in which you can install it here. I decided to follow the Docker Compose quickstart instruction here. I also created a Katacoda scenario here so you can try it out for yourself! I will not repeat the entire quickstart since it is straightforward, but provide a quick example:

 #Download and run docker-compose file  
 curl https://docs.anchore.com/current/docs/engine/quickstart/docker-compose.yaml > docker-compose.yaml  
 docker-compose up -d  
    
 #Check status of feeds (first time updating can take a while)  
 docker-compose exec api anchore-cli system feeds list  
    
 #Block until complete  
 docker-compose exec api anchore-cli system wait  
    
 #Start analysis  
 docker-compose exec api anchore-cli image add openjdk:11.0.6-jre-slim  
    
 #get status  
 docker-compose exec api anchore-cli image list  
    
 #Show vulnerabilities  
 docker-compose exec api anchore-cli image vuln openjdk:11.0.6-jre-slim all

This gives you a list of vulnerabilities of the image you indicated you wanted scanned. For example for openjdk:11.0.6-jre-slim:

If you want to scan multiple images, for example to determine the most secure JRE 11.0.6 image, you can do the following in a Bash script:

 strings=(  
 openjdk:11.0.6-jre-buster  
 openjdk:11.0.6-jre  
 openjdk:11.0.6-jre-slim-buster  
 openjdk:11.0.6-jre-slim  
 openjdk:11.0.6-jre-stretch  
 adoptopenjdk:11.0.6_10-jre-openj9-0.18.1  
 adoptopenjdk:11.0.6_10-jre-hotspot  
 adoptopenjdk:11.0.6_10-jre-openj9-0.18.1-bionic  
 adoptopenjdk:11.0.6_10-jre-hotspot-bionic  
 adoptopenjdk/openjdk11:jre-11.0.6_10-ubuntu  
 adoptopenjdk/openjdk11:jre-11.0.6_10  
 adoptopenjdk/openjdk11:jre-11.0.6_10-ubi-minimal  
 adoptopenjdk/openjdk11:jre-11.0.6_10-ubi  
 adoptopenjdk/openjdk11:jre-11.0.6_10-debianslim  
 adoptopenjdk/openjdk11:jre-11.0.6_10-debian  
 adoptopenjdk/openjdk11:jre-11.0.6_10-centos  
 adoptopenjdk/openjdk11:jre-11.0.6_10-alpine  
 mcr.microsoft.com/java/jre:11u6-zulu-alpine  
 mcr.microsoft.com/java/jre:11u6-zulu-centos  
 mcr.microsoft.com/java/jre:11u6-zulu-debian8  
 mcr.microsoft.com/java/jre:11u6-zulu-debian9  
 mcr.microsoft.com/java/jre:11u6-zulu-debian10  
 mcr.microsoft.com/java/jre:11u6-zulu-ubuntu  
 azul/zulu-openjdk-alpine:11.0.6-jre  
 )  
   
 for i in "${strings[@]}"; do  
 docker-compose exec api anchore-cli image add "$i"  
 done

Processing results

Now you have to wait a while for all the images to be scanned. If it’s done, you can process the data.

 strings=(  
 openjdk:11.0.6-jre-buster  
 openjdk:11.0.6-jre  
 openjdk:11.0.6-jre-slim-buster  
 openjdk:11.0.6-jre-slim  
 openjdk:11.0.6-jre-stretch  
 adoptopenjdk:11.0.6_10-jre-openj9-0.18.1  
 adoptopenjdk:11.0.6_10-jre-hotspot  
 adoptopenjdk:11.0.6_10-jre-openj9-0.18.1-bionic  
 adoptopenjdk:11.0.6_10-jre-hotspot-bionic  
 adoptopenjdk/openjdk11:jre-11.0.6_10-ubuntu  
 adoptopenjdk/openjdk11:jre-11.0.6_10  
 adoptopenjdk/openjdk11:jre-11.0.6_10-ubi-minimal  
 adoptopenjdk/openjdk11:jre-11.0.6_10-ubi  
 adoptopenjdk/openjdk11:jre-11.0.6_10-debianslim  
 adoptopenjdk/openjdk11:jre-11.0.6_10-debian  
 adoptopenjdk/openjdk11:jre-11.0.6_10-centos  
 adoptopenjdk/openjdk11:jre-11.0.6_10-alpine  
 mcr.microsoft.com/java/jre:11u6-zulu-alpine  
 mcr.microsoft.com/java/jre:11u6-zulu-centos  
 mcr.microsoft.com/java/jre:11u6-zulu-debian8  
 mcr.microsoft.com/java/jre:11u6-zulu-debian9  
 mcr.microsoft.com/java/jre:11u6-zulu-debian10  
 mcr.microsoft.com/java/jre:11u6-zulu-ubuntu  
 azul/zulu-openjdk-alpine:11.0.6-jre  
 )  
   
 echo Unknown,Critical,High,Medium,Low,Negligible,Image  
 for i in "${strings[@]}"; do  
 docker-compose exec api anchore-cli image vuln "$i" all | awk 'NR>1{print $3}' | sort -n | uniq -c >parse.txt  
 UNKNOWN=`cat parse.txt | grep Unknown | awk '{print $1}'`  
 CRITICAL=`cat parse.txt | grep Critical | awk '{print $1}'`  
 LOW=`cat parse.txt | grep Low | awk '{print $1}'`  
 MEDIUM=`cat parse.txt | grep Medium | awk '{print $1}'`  
 HIGH=`cat parse.txt | grep High | awk '{print $1}'`  
 NEG=`cat parse.txt | grep Negligible | awk '{print $1}'`  
 if [ -z "$UNKNOWN" ]; then  
      UNKNOWN=0  
 fi  
 if [ -z "$CRITICAL" ]; then  
     CRITICAL=0  
 fi  
 if [ -z "$LOW" ]; then  
      LOW=0  
 fi  
 if [ -z "$MEDIUM" ]; then  
      MEDIUM=0  
 fi  
 if [ -z "$HIGH" ]; then  
      HIGH=0  
 fi  
 if [ -z "$NEG" ]; then  
      NEG=0  
 fi  
 echo $UNKNOWN,$CRITICAL,$HIGH,$MEDIUM,$LOW,$NEG,"$i"  
 done

This provides a nice comma separated list which you can use in your favorite spreadsheet for some visualization

Next, you can draw some conclusions like

Newer OS versions are more secure
Alpine does better than Debian/Ubuntu. Debian/Ubuntu does better than RHEL/CentOS
Slim versions do slightly better than not so slim versions
No OpenJDK JRE 11.0.6 images scanned have critical vulnerabilities. Very few have high severity issues
In the OpenJDK images, when a new version is released, the underlying libraries and tools are usually also updated, reducing the number of vulnerabilities in newer versions.

Finally

I was surprised (even though I was trying out a quickstart) in how little time I could perform a vulnerability scan of a list of images. The integration options Anchore Engine provides, also seem powerful, although I did not try them out yet. There seems little reason not to cooperate a scan like this in your CI/CD environment. I suggest you give it a try!

This is just an example of a security related challenge. The container platform itself runs on an OS which you should check. Kubernetes and its native components can have vulnerabilities. Of course you should also keep an eye on already deployed images, since new vulnerabilities can be found. I did not scan an image containing an actual application. This might have provided some additional insights. You should perform scans on your source code dependencies (see for example the OWASP dependency check here) and on the code itself (see here). Also outside of your source code it is advisable to do some security related integration tests, such as checking your HTTPS connection (e.g. cipher suites), certificates, HTTP headers, try out some XML based attacks maybe, etc. Many challenges, but for scanning container images Anchore Engine seems nice!

About Post Author

Maarten Smeets

Maarten is a Software Architect at AMIS Conclusion. Over the past years he has worked for numerous customers in the Netherlands in developer, analyst and architect roles on topics like software delivery, performance, security and other integration related challenges. Maarten is passionate about his job and likes to share his knowledge through publications, frequent blogging and presentations.

maarten.smeets@amis.nl

http://javaoraclesoa.blogspot.nl/