Containers in IQ Server

IQ Server | Reading time: 9 minutes

Is this article helpful?


This article covers everything you need to know about containers in Nexus IQ Server. We’ll go over what containers are, how they’re scanned in IQ Server, and how to evaluate policy against container images. Finally, we’ll give you answers to some frequently asked questions about Nexus IQ Server and container scanning.

More specifically, this article will help our learners with the following:

  • Understand what containers, images, and layers are and how they’re used in modern software development.
  • Explain how Nexus IQ Server scans images and what information will be available from the scans.
  • Run image scans in Nexus 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.

NOTE: This guide shows you how to scan container files in the IQ Server. It does not cover Nexus Container—our Kubernetes-native container security solution. Nexus Container provides container network, process, and file system protection. To learn more about Nexus Container, please see the Nexus Container NeuVector docs.


What are containers?

First, let’s talk about containers. Containers let developers package up their applications with all the dependencies it needs to run like libraries, other binaries, and configuration files. They can then ship out the container as one package, letting the application run quickly and reliably on multiple environments. There are several container tools available, with Docker being one of the most popular.

Next, let’s go over images. Container images are compiled from file system layers built onto a parent or base image. These layers let you reuse various components, so users of your application don’t have to create everything from scratch. Developers create container images with the build command of a container tool, like Docker. They can then update the image any time to add more features or fix bugs. These container images are stored in a registry on a private or public repo, such as Docker Hub.

Finally, let’s talk about layers. Images are built from a series of layers. Each layer serves as an instruction on the image’s Dockerfile. When creating a new container, devs add a new writable top layer called the container layer. The main difference between a container and an image is this top writable layer. All changes made to the container are stored in this writable layer. When the container is deleted, the writable layer is also deleted, but the underlying image remains unchanged.

How does IQ Server scan containers?

NOTE: This guide shows you how to scan container files in the IQ Server. It does not cover Nexus Container—our Kubernetes-native container security solution. Nexus Container provides container network, process, and file system protection. To learn more about Nexus Container, please see the Nexus Container NeuVector docs.

Now that you have some basic knowledge on containers, images, and layers, let’s talk about how Nexus IQ Server works with containers.

Nexus Lifecycle scans the application layer of your containers, and provides precise component intelligence for Java, JavaScript, Nuget, and Python.

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 into 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 of 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 Nexus Lifecycle provides that intelligence throughout the development pipeline.

An example - running a scan from the CLI

The Nexus 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 a setup for a Docker image that is built or pulled down.


In this example, Stefania Chaplin (Sonatype Solutions Engineer) pulls the Webgoat docker image, saves it as a tar file, and then scans the tar in the Nexus IQ Server CLI.


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 Nexus 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, a detailed bill of materials, and will also automatically kick off notifications, if that feature is enabled.

Opening the component information panel (CIP) 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 are 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, please see our Nexus IQ CLI help docs.

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 Nexus policy evaluation step.


In the following video, Justin Young (Sonatype Integrations Product Owner) scans our own NXRM3 image as a Jenkins pipeline build step.

DevSecOps for Containers - Nexus Lifecycle Container Analysis from Sonatype Nexus on Vimeo.


NOTE: You need a running instance of Jenkins with the Nexus 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, but generally 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 webhooks listener. Using this option lets you scan after a build is pushed to Docker Hub or Nexus Repository, 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 IQ Server FAQs

How does Nexus IQ Server 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 Nexus IQ for evaluation.

Does Sonatype inspect any other areas of the container aside from the applications?

Sonatype only provides insight into the application within the container. The IQ Server team’s long term strategy is to provide insight into the other container layers, but no timeline is available for this.

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

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, and the Nexus IQ Server 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?

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

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

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

Additional Resources

Talk to Us

Have more questions or comments? Learn more at, join us in the Sonatype Community, and view our course catalog at

And visit for all things Sonatype.