Skip to main content
  1. Posts/

Scanning Docker Image for Vulnerabilities with Aqua MicroScanner

··436 words·3 mins·
DevOps Containers Docker Security

Containers are slowly becoming the standardized units of deployment. As containers become more popular, they also become the focus targets for attacking the system via vulnerabilities present in the packages within the image. There are quite a few container vulnerability scanning solutions (example: Clair, Twistlock, now Prisma Cloud, Aqua – however most of them are either commercial or require an elaborate setup, which makes it difficult for individual developers to involve them as part of the container build process.

I found recently that Aqua has introduced a free-to-use tool called Aqua MicroScanner for scanning container images for package vulnerabilities. What makes this even more attractive and easy-to-use is that it doesn’t need any elaborate or predefined server setups – and all that is needed to use this is:

  • Get a token from Aqua
  • Add the scanner and run it as part of the container build process

If the image contains any packages with vulnerabilities, Aqua will present a summary of the vulnerabilities, the average CVE score as well as a list of the found vulnerabilities.

To get started with Aqua MicroScanner, register for a token

$ docker run --rm -it aquasec/microscanner --register <email address>

With the token available, add it as part of your build process. For example, if we were to check and scan an image based on nginx, the Dockerfile would look like below

FROM nginx:1-alpine 
RUN apk add --no-cache ca-certificates && update-ca-certificates 
ADD https://get.aquasec.com/microscanner . 
RUN chmod +x microscanner 
RUN ./microscanner <token> 

When we build the container with

$ docker build .

The scanner will be executed and will scan the Docker image. The vulnerability found will be displayed as below

"vulnerabilities": [ 
{ 
"name": "CVE-2016-3189", 
"description": "Use-after-free vulnerability in bzip2recover in bzip2 1.0.6 allows remote attackers to cause 
a denial of service (crash) via a crafted bzip2 file, related to block ends set to before the start of the block.", 
"nvd_score": 4.3, 
"nvd_score_version": "CVSS v2", 
"nvd_vectors": "AV:N/AC:M/Au:N/C:N/I:N/A:P", 
"nvd_severity": "medium", 
"nvd_url": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3189", 
"vendor_score": 4.3, 
"vendor_score_version": "CVSS v2", 
"vendor_vectors": "AV:N/AC:M/Au:N/C:N/I:N/A:P", 
"vendor_severity": "medium", 
"publish_date": "2016-06-30", 
"modification_date": "2017-08-21" 
} 
] 

The summary would be like so:

"vulnerability_summary": { 
"total": 2, 
"medium": 2, 
"score_average": 4.3, 
"max_score": 4.3 
} 

Aqua will stop the build if it finds any vulnerabilities of severity “High” – however, we can pass  --continue-on-failure flag to ignore the High severity issues and continue the build.

I think this tool is really good, especially for small developers – with just few lines of Dockerfile instructions, the developer is able add vulnerability scanning of the images – and combined with CI like that of Gitlab CI/CD Pipelines, it’s a good way of building vulnerability-free container images.

Sathyajith Bhat
Author
Sathyajith Bhat
Author, AWS Container Hero and DevOps Specialist.

Related

Accessing Chef Databag Items from within attributes
··135 words·1 min
DevOps Chef
In Chef parlance, databags are global variables saved in JSON format and are stored and accessible on the Chef server. Given that these are indexed and can be searched up along with the fact that they can be encrypted make them ideal candidates to store secrets such as credentials/ssh keys. Chef provides an easy way to search and fetch databag and databag items from within a recipe: For ex to fetch a databag called admins, it’s as easy as:
Of nginx’s mid cut off responses and proxy buffers
··470 words·3 mins
DevOps Nginx
Among the services I look after, the biggest and high-profile - is the user facing website. The website is your bog-standard typical frontend(powered by Express/Angular) which fetches data via an API which is powered by the backend(built on Rails). Typical flow is that Express receives the request from the browser, makes a request to the backend which is then served using Rails API via nginx which acts as the reverse proxy.
Statutory warning: Decimals in your logrotate config can be bad for your server’s disk space
··308 words·2 mins
DevOps Chef Logrotate Ruby
Last night as I was about to head to sleep, Sensu started emailing me about disk space warnings on one of the backend servers. That’s strange, I thought. I had set up logrotate with appropriate limits to ensure the log file size is reasonable and rotation happens on a daily basis. Curious, I ssh’d into the server to investigate. Running a df -h indicated as expected the disk space in use was over 70% (which is the trigger for sensu to send a notification) and the log files had grown way over expected size.