TL;DR Attackers now turn a new vulnerability into a working exploit faster than most teams can rebuild and redeploy an image. That makes the build pipeline the last place to stop a known problem, but a pipeline check on its own ends at the push. The Aquasec plugin for Jenkins scans container images inside Pipeline and Freestyle jobs against Aquasec Image Assurance Policies. The same policies can mark a failed image as noncompliant, so the Aquasec Enforcer can refuse to run it in production even if it reaches a cluster another way.
What does the Aquasec and Jenkins integration do?
Most organizations already scan images somewhere in the pipeline. The weak point is what happens next. A scan that writes a report and lets the build continue produces knowledge, and the image still ships. A scan that blocks the build protects that one pipeline, but an image pulled from another source or pushed by hand never meets the gate.
The Aquasec plugin for Jenkins adds a scan step to the build itself. The Aquasec scanner checks the image for vulnerabilities, malware and sensitive data, then evaluates the results against the Image Assurance Policies defined in the Aquasec Platform. Depending on how the job is configured, a failing image either fails the build or reports the issue while the build continues.
What makes the gate more than a pipeline check is where the policy lives. Image Assurance Policies are defined once in Aquasec and used in two places. In Jenkins they decide whether the build passes. At runtime, the Aquasec Enforcer can mark a failed image as noncompliant and prevent containers from running it. The developer sees the failure in the build log, and production enforces the same decision.
How does the Aquasec and Jenkins integration work?
The Aqua Security Scanner plugin is installed from the central Jenkins plugin repository, or deployed manually from its .hpi file. It is configured under Manage Jenkins, System, in the Aqua Security section. There an administrator sets the Aquasec scanner image, the Aquasec server URL and a scanner token. Both values come from the deployment command of a CI/CD scanner group. Aquasec SaaS accepts token authentication only, so username and password authentication is not an option for SaaS environments.
The plugin works in Pipeline and Freestyle jobs. In a pipeline, the aqua step goes into the pipeline script, and the Jenkins Snippet Generator can build the syntax. With the Docker engine, the plugin scans local images, images hosted in a registry and docker-archive tar files. With Podman, supported from plugin version 3.1.2, it scans local images as a root or non root user.
Each job chooses what happens to a noncompliant image: never fail the build, or perform the actions defined in the Image Assurance Policy. Local images and archives are evaluated against the Default Image Assurance Policy. Registry images are evaluated against every policy whose scope includes them. Optional settings register the image with Aquasec after a successful scan, hide base image vulnerabilities and run a shell command when an image fails.
Results appear in Jenkins as an Aquasec scan report organized like the image view in the Aquasec UI. A View in Aqua Platform button opens the image under Workload Protection, Images & Functions, Images, CI/CD Scans. A separate Aqua Security Serverless Scanner plugin scans function code for vulnerabilities, sensitive data and excessive permissions.
What does this integration mean for Aquasec customers?
One policy decides at build time and at runtime. The controls that fail a Jenkins build are the controls the Aquasec Enforcer checks when a container starts. Teams maintain one set of Image Assurance Policies, and the pipeline and the cluster reach the same answer about the same image.
The gate does not depend on every image passing through Jenkins. A pipeline check only covers what the pipeline builds. When a failed image is marked noncompliant and the runtime policy includes the control that blocks noncompliant images, Aquasec can stop that image from running wherever it is deployed.
Developers get the finding where they already work. Jenkins remains responsible for building and orchestrating the pipeline. Aquasec remains responsible for the scan, the policy and the enforcement in running workloads. The developer reads the result in the build, and the security team sees the same scan in the Aquasec Platform.
Where does this matter most?
- Image security operations. A platform team rolls out a malware or sensitive data policy. Every Jenkins job that scans with Aquasec starts failing builds that violate it, without editing each pipeline.
- Production risk reduction. A critical vulnerability lands in a widely used base image. Builds that include it fail in Jenkins, and the Enforcer can block running containers from that image if it was deployed before the policy changed.
- Collaboration between application and security teams. Developers fix the issue from the report in their build. Security reviews the same CI/CD scan in Aquasec without asking for logs.
- Serverless pipelines. Teams building functions add the serverless plugin to check code for excessive permissions and sensitive data before deployment.
What do you need to get started with Aquasec and Jenkins?
You need an Aquasec user with the Scanner CLI permission, a CI/CD scanner group in Aquasec to supply the server URL and token and the Aquasec scanner image available on the Jenkins node. Podman scanning requires plugin version 3.1.2 or later. To see pipeline scans in the Aquasec UI, enable the Save CI/CD Scans scanning setting. The plugin is distributed through the Jenkins plugin repository.
Customers can follow Aqua’s ServiceNow integration guide on Aqua Docs (login required) to configure the integration, or request a demo to see it in action.
FAQ
Does the Aquasec Jenkins plugin block builds automatically?
Only if you configure it to. Each job either never fails builds or performs the actions defined in the Aquasec Image Assurance Policy, which can include failing the Aquasec step in CI/CD.
Which Image Assurance Policies does Aquasec apply to a Jenkins scan?
Local images and docker-archive files are checked against the Default Image Assurance Policy. Images hosted in a registry are checked against every Aquasec policy whose scope includes them.
Can Aquasec stop an image that failed in Jenkins from running?
Yes, when the policy marks failed images as noncompliant and the container runtime policy includes the control that blocks noncompliant images. In that case the Aquasec Enforcer prevents containers from running the image
Does the Jenkins plugin support Podman?
Yes. Plugin version 3.1.2 and later scan local images with Podman, as a root or non root user. Registry and archive scanning use the Docker engine
Can I scan serverless functions in Jenkins with Aquasec?
Yes. The Aqua Security Serverless Scanner plugin scans function code for vulnerabilities, sensitive data and excessive permissions, and can fail or continue the pipeline when a function is noncompliant.
Aquasec is a leader in runtime security, helping organizations protect cloud native applications and AI workloads where attacks actually happen. Built on a full agent architecture, the Aquasec Platform combines deep runtime visibility with real time enforcement inside running workloads to detect and stop threats as they execute. By focusing on exploitable risk and enabling immediate containment, Aquasec helps security teams reduce exposure and protect production environments without waiting for traditional remediation workflows.
