Sonatype Container Security
Sonatype Container Security is a comprehensive security solution for the entire container build time pipeline; safeguarding your containerized applications by protecting them with unmatched vulnerability detection and automatic policy enforcement during build time.
Integrates within CI/CD pipelines to scan and report CVE vulnerabilities within container images.
Scan early in the development process to prevent vulnerable images from deploying.
Prerequisites for Sonatype Container Security
Sonatype Container Security is a feature available to the Lifecycle and SBOM Manager solutions. It utilizes the Neuvector scanner (a third-party component) embedded into the Sonatype CLI to provide container security analysis.
A license for Sonatype Container Security is required to receive support from the Sonatype Technical Support team.
macOS or Linux.
A running instance of Docker or Podman client.
Set the environment variables as needed.
Container scanning using Windows OS is not supported. The Azure DevOps plugin supports container security build time container: scanning, provided the agent uses macOS or Linux and the other prerequisites are met.
Windows users should refer to Docker Container Analysis.
Scanning with Sonatype Container Security
Sonatype Container Security uses the Docker client to analyze the container as a scan target when using the CLI scanner. Environment variables are configured depending on where the image is located.
When using IQ CLI version 1.183.0 or earlier, use unique mount paths for each scan target when performing container scans in parallel.
Scanning a local image
This will look for an image in your local Docker instance and scan it when found. This is useful for scanning images built locally and before pushing them to a registry.
Scanning a local image using the default configuration does not require setting environment variables. Use the container:<image>:<version>
format as the scan target.
container:alpine:3.4
Example with the Sonatype CLI
java -jar nexus-iq-cli*.jar \ -a admin:admin123 \ -i test-app \ -t build \ -s http://localhost:8070 \ container:alpine:3.4
Refer to the Sonatype CLI documentation for parameter details.
Scanning an application along with the container
Analyze an application and container simultaneously by specifying both as targets in the CLI command. Use a space between the path to the application and the container.
/app_path container:alpine:3.4
Example with application binary and base container
java -jar nexus-iq-cli*.jar \ -a admin:admin123 \ -i test-app \ -t build \ -s http://localhost:8070 \ ./my_application.war container:alpine:3.4
Scanning a remote image
Include the container's url to scan an image stored on a remote server. We recommend you set the registry's username and password environment variables to authenticate on the remote registry. Credentials are required for private images.
export NEXUS_CONTAINER_IMAGE_REGISTRY_USER=anyuser export NEXUS_CONTAINER_IMAGE_REGISTRY_PASSWORD=xxxxxxxxxxxxxx
java -jar nexus-iq-cli*.jar \ -a admin:admin123 \ -i test-app \ -t build \ -s http://localhost:8070 \ container:http://registry.hub.docker.com/library/alpine:3.4
Running a scan from Jenkins
Requirements are a running instance of Jenkins with the Sonatype Platform plugin installed and configured to run policy evaluations in Jenkins.
Consult the Jenkins documentation for examples of setting environment variables.
For this example, the scanPattern
of container:
is used to target the container.
Create a new pipeline project in Jenkins
Enter and update the example script from below into the Pipeline section
Save the pipeline script and run the build in Jenkins
Once complete, follow the link to the results report
pipeline { agent any environment { NEXUS_CONTAINER_IMAGE_REGISTRY_USER = {anyuser} NEXUS_CONTAINER_IMAGE_REGISTRY_PASSWORD = {password} } stages { stage('Policy') { steps { nexusPolicyEvaluation ( advancedProperties: '', enableDebugLogging: false, failBuildOnNetworkError: false, iqApplication: selectedApplication('test-app'), iqScanPatterns: [ [scanPattern: 'container:http://registry.hub.docker.com/library/alpine:3.4'], [scanPattern: '**/my_application.war'] ], iqStage: 'build', jobCredentialsId: '' ) } } } }
Running a scan on Podman
If you don't have Docker, you may use Podman as an alternative container runtime. Podman is a daemonless container engine for developing, managing, and running OCI (Open Containers Initiative) Containers and Container Images.
Using the Runtime‐Override Environment Variable
Set the runtime to Podman:
export NEXUS_CONTAINER_SCANNING_RUNTIME=podman
Run the container scan:
java -jar nexus-iq-cli*.jar \ -i ContainerScan \ -t stage-release \ -s http://localhost:8070 \ -a [username]:[password] \ container:nodered/node-red:2.0.3
In the logs you’ll see:
[INFO] Using runtime: Podman [INFO] Running container scan via: podman run --rm --name VYHNPZ \ -v /Users/sonatype/tmp:/var/neuvector \ -e SCANNER_REPOSITORY=alpine \ -e SCANNER_TAG=latest \ -e SCANNER_LICENSE=registry.hub.docker.com/neuvector/scanner:latest
confirming that Podman, not Docker, is being used.
Verify Podman:
podman ps
You should see your Podman containers running (including NeuVector’s scanner image).
Symlinking Docker to Podman
For environments where you cannot change the runtime via env var, Podman can provide Docker-compatible commands via a symlink:
Verify that the
docker
command isn’t found on your system:% docker zsh: command not found: docker
Confirm that Podman is installed by running the
podman
command without any arguments. This should display usage information and available options.% podman
Alias Docker to Podman or create a symlink that points Docker’s path (
/usr/bin/docker
) to Podman (/usr/bin/podman
). Keep in mind that paths might change depending on your specific environment:% sudo ln -s /usr/bin/podman /usr/bin/docker
Verify the symlink was created correctly:
% ls -al /usr/bin/docker
This should return output showing that
/usr/bin/docker
points to/usr/bin/podman
. Ensure the path and target are as expected.The symbolic link allows you to use the
docker
command, which will execute thepodman
binary.Enable the Podman socket:
% sudo systemctl enable --now podman.socket
This creates a socket at:
/run/podman/podman.sock
Export the environment variable when running the scan:
% export NEXUS_CONTAINER_SOCKET_MAPPING=/run/podman/podman.sock:/run/podman/podman.sock
Log in to the container registry:
% podman login
Enter your username and password. If successful, you'll see the message "Login Succeeded!"
Run your container scan:
% java -jar /Users/[your username]/Applications/nexus-iq-server-1.176.0-01-bundle/nexus-iq-cli.1.76.0-01.jar -i ContainerScan -t stage-release -s http://localhost:8070 -a [username]:[password] container:nodered/node-red:2.0.3
The report will be generated without requiring a running Docker daemon, using Podman instead.
Sonatype Container Security environment variables
These environment variables are to set the authentication to remote servers.
Environment Variable | Example Value |
---|---|
| <registry_username> |
| <registry_password> |
These environment variables may be set to override the default configuration.
Environment Variable | Default Value |
---|---|
Since IQ 1.182.0 Set to | docker |
Since IQ 1.182.0 When performing container scans, Docker-in-Docker (DinD) is required only if you are scanning local images or using the Docker CLI or GitLab plugin (regardless of whether the target image is local or remote). If you’re scanning a remote image directly, Docker-in-Docker isn’t needed since NeuVector pulls image layers straight from the registry and doesn’t rely on the host OS socket. | /var/run/docker.sock:/var/run/docker.sock |
| "" |
| scanner |
| https://registry.hub.docker.com/neuvector |
| <dockerhub username> |
| <dockerhub password> |
Since IQ 1.185.0 If set to | |
Deprecated in IQ 1.184.0 When using the mount path for Sonatype Container, the user requires write permissions to the location specified at the mount path. Write permission to | /tmp |
Only for IQ CLI version 1.183.0 or earlier | false |
FAQs
How does Sonatype evaluate containers?
Sonatype leverages Container Security to directly provide information about your images and registries back in the same report, alongside other application vulnerabilities and evaluation results.
Where can I integrate Sonatype Container Security scanning into my SDLC?
Sonatype Container Security scanning in Lifecycle and SBOM Manager is available in the CLI and the Jenkins, Bamboo CI, and Gitlab CI plugins.
How can I scan with an SELinux image?
If you're using IQ CLI version 1.183.0 or earlier, there is support for the environmental variable NEXUS_CONTAINER_SCANNING_BIND_MOUNT_SHARED
. Setting the property to true will include the ':z'
option in the request allowing the bind mount content to be shared among multiple containers. This is not needed if you're using IQ CLI version 1.184.0 or later.
Details are found in the Docker documentation.
Why are components discovered by Sonatype Container Security showing the component's license name as "Not Provided"?
The Sonatype Container Security scan does not show the license information for all the detected components. These are OS-level components where the identity information is provided by a third-party source that only provides vulnerability information. There is no way to get the license information at this time. This feature has been raised as an enhancement request. Submit your interest on ideas.sonatype.com
Why does the component overview page only show one version?
The component overview page only shows one version because NeuVector's provided component identity information does not include other versions of the component data.