Skip to main content

Docker Container Analysis


This section covers a scan of the application layer only. For a full scan of container images, including the OS layer refer toSonatype Container Scanning.

This topic will help you with the following:

  • Explain how Sonatype IQ Server scans images and what information will be available from the scans.

  • Run image scans in Sonatype IQ Server using a CI (Jenkins or Bamboo) plugin, CLI, or Web UI.

  • Analyze the results of a scan and use that info to better understand the health of their containers.


How does IQ Server scan containers?

Sonatype Lifecycle scans theapplication layerof your containers and provides component intelligence for open-source components. For a full scan of the container image, including the OS layer refer toSonatype Container Scanning.

To scan a Docker image, you need to first save it as a tar file, and then run a scan in the CLI, Web UI, or as a build step using the Jenkins or Bamboo plugins. Scanning Docker images lets you apply your organizational policy to the Docker images you are using, providing data on the health of your applications, and actions to make sure everything is secure.

What will I see in the evaluation results?

When scanning a container image, all the policies set up in your instance of IQ Server are applied, giving you a breakdown as it would in any other application. The report will contain information on the application layers, and provide a breakdown in terms of the components in your image, what is breaking policy, and how you can resolve vulnerabilities.

Information provided from the scan report helps you understand the quality of the applications within your containers, and Sonatype Lifecycle provides that intelligence throughout the development pipeline.

An example - running a scan from the CLI

The Sonatype IQ Scanner relies on the availability of a Docker image, and the Docker daemon must be made available at some point to provide that image. This is common in any type of setup for a Docker image that is built or pulled down.


Open your CLI, and enter the following commands:

  1. Pull the Docker image: docker pull webgoat/webgoat-7.1

  2. Save the image as a tar file: docker save webgoat/webgoat-7.1:latest > webgoat-7.1.tar

  3. Run the scan from the Sonatype IQ CLI: java -jar ./nexus-iq-cli-1.59.0-01.jar -i dockerapp -s http://localhost:8070 -a admin:changeme -t build webgoat- 7.1.tar

The example above is using release 59 of the IQ CLI.dockerapp is the name of the application we are running the evaluation against, localhost:8070 is the location of our IQ Server, admin:changeme are our login credentials, and webgoat-7.1.tar is the image we are scanning.

It will then start the scan. As it begins to scan, it will start identifying what contents are available to the container, or what the final container looks like in the image. Container evaluations perform the java scanning that you’re used to, in addition to other formats like javascript (a-name match).

Once the scan is complete, you’ll see a link to the report in your CLI. Copy the link and then paste it into your browser to access the scan results.

The report shows you the components identified, customized policy violations, and a detailed bill of materials, and will also automatically kick-off notifications if that feature is enabled.

Opening the Component Details Page for a component, and then selecting the Occurrences tab, you’ll see the tar file path, with a long hash, and then a layer.tar. Each of these layers is built on top of each other to build the image. The report does not show everything that’s in the image itself but instead shows what’s actually running in Docker (the application layer).

For more information on running scans in the CLI, see our Sonatype IQ CLI

An example - running a scan from Jenkins CI

In this example, we’ll create a pipeline project in Jenkins that pulls down the Webgoat image from Docker Hub and then kicks off a Lifecycle policy evaluation step.



NOTE: You need a running instance of Jenkins with the Sonatype Platform plugin installed and configured to run policy evaluations in Jenkins.

For this example, we’ll run a scan on the Webgoat-7.1 Docker image.

  1. Open Jenkins, and create a new pipeline project. In the Pipeline section, enter the following script:

    node {
        stage('Build/Pull') {
            sh "rm -f ${env.WORKSPACE}/*.tar"
            sh 'docker pull webgoat/webgoat-7.1'
            sh "docker save webgoat/webgoat-7.1 -o ${env.WORKSPACE}/webgoat-7.1.tar"
        stage('IQ Evaluation') {
            nexusPolicyEvaluation (
                failBuildOnNetworkError: false, 
                iqApplication: 'dockerapp',
                iqScanPatterns: [[scanPattern: '*.tar']],
                iqStage: 'release',
                jobCredentialsId: ''


    NOTE: In your instance, specify a node to run on agents that have Docker installed.

    In the first stage, you’ll pull down the Webgoat image from Docker Hub and then save it as webgoat-7.1.tar.

    In the second stage, you’ll scan the tar file. You’ll also specify an application and identify IQ scan patterns to explicitly say you are looking at tar files.

    There are various different approaches to how you can set up complex build pipelines. You will see the build/pull stage and then a separate stage to perform the evaluation.

  2. Save the pipeline script and then kick off your build in Jenkins.

    Looking at the console output, you’ll see the steps of the pipeline build (docker pull, save, and then IQ scan).

  3. Once the job is done, you’ll see a link to the Latest Application Composition Report. Click the link to go to the report.

You’ll see similar report results to what you saw in the CLI scan example — components identified, customized policy violations, a detailed bill of materials, and the evaluation will automatically kick off notifications when enabled.

IQ Webhook Listener

In addition to the CLI and CI plugins, there’s also an option to scan your containers using a webhook listener. Using this option lets you scan after a build is pushed to Docker Hub or Nexus Repository 3, triggering a scan from the repository.

This may be your best option if you don’t have access to your CI build steps, but still want to kick off evaluations when things are pushed to your repos.

For help with this, see our docs on the IQ Webhook Listener.

Containers in Lifecycle FAQs

How does Lifecycle evaluate containers?

Container images are first saved as tar files — which contain a copy of each layer that was generated to build the image. Next, a scan is initiated, and the scanner uses the Docker algorithm to analyze which files are added or deleted from each layer to determine the composition of the container. The application layer contents are then passed to Lifecycle for evaluation.

How does a native Docker evaluation compare to evaluating a traditional target application e.g. war, tar, or ear within Lifecycle?

It is similar to the traditional scan, although it will pick up all files that match the target (jar, war, etc.). If there are additional jars, for example in the Docker image beside the application, they will also be scanned.

Where can I integrate Sonatype’s container scanning into my SDLC?

Container scanning is available in the CLI, Jenkins plugin, Bamboo plugin, Gitlab CI plugin, and the Lifecycle Web UI. These integrations require a Docker image tar archive available using the Docker CLI. The Docker daemon is not required to do the scan but is required to provide the tar archive.

Can I inspect containers hosted in Nexus Repository 3?

A Docker daemon can be used to pull and save an image from Nexus Repository 3. This image can then be scanned using any of the Lifecycle enforcement tools.

Can I inspect containers running in OpenShift? Kubernetes? Rancher?

Docker containers running on these platforms can be pulled, saved, and evaluated. Ideally, Lifecycle would evaluate the image before it is deployed to any of these to determine if it is fit for deployment.