Aqua Security’s deep integration into your CI/CD pipeline is less about adding a new security gate and more about making security a native, invisible part of your development process. The most surprising thing is that it doesn’t slow you down; it actually accelerates your releases by catching vulnerabilities before they become expensive production issues.
Let’s see Aqua in action during a typical build. Imagine a developer commits code that includes a new dependency, log4j-core-2.17.1.jar.
# Jenkinsfile snippet
pipeline {
agent any
stages {
stage('Build') {
steps {
script {
// This is where Aqua integrates. It intercepts the build artifact.
// The Aqua scanner runs as a container during the build.
sh 'docker build -t my-app:latest .'
// Aqua scan is automatically triggered after the image is built
// and before it's pushed or deployed.
}
}
}
stage('Security Scan') {
steps {
script {
// This stage explicitly shows the Aqua scan, though it can be
// configured to run automatically after 'Build'.
// The Aqua CLI is used here for demonstration.
// 'aqua scan' checks the built image against configured policies.
sh 'aqua scan --image my-app:latest --output json > aqua_scan_results.json'
// The results are then analyzed. If policy violations are found,
// the pipeline can be failed.
script {
def results = readJSON file: 'aqua_scan_results.json'
if (results.vulnerabilities.total > 0) {
error "Aqua scan found ${results.vulnerabilities.total} vulnerabilities!"
}
}
}
}
}
stage('Push to Registry') {
when {
// Only push if the security scan passed
expression { readFile('aqua_scan_results.json') =~ '"vulnerabilities":.*"total":0' }
}
steps {
script {
sh 'docker push my-app:latest'
}
}
}
}
}
In this Jenkinsfile, Aqua is configured to scan my-app:latest after it’s built. If the scan detects critical vulnerabilities that violate the defined security policy (e.g., CVSS score > 9.0, or a specific CVE like CVE-2021-44228 in Log4j), the Security Scan stage fails, and the Push to Registry stage is skipped. This prevents vulnerable images from ever reaching your artifact repository.
Aqua’s power comes from its ability to understand the entire software supply chain. It doesn’t just scan the final container image; it can also scan:
- Source Code: Detecting secrets, malware, and insecure coding practices before they’re committed.
- Build Artifacts: Scanning JARs, Python wheels, NPM packages, etc., for known vulnerabilities.
- Infrastructure as Code (IaC): Analyzing Terraform, CloudFormation, and Kubernetes manifests for misconfigurations that could lead to security gaps.
- Runtime: Monitoring running containers and hosts for drift, unauthorized access, and new threats.
The core of Aqua’s CI/CD integration is its policy engine. You define what constitutes an acceptable risk. This isn’t just about CVEs; it includes:
- Image Layers: Ensuring only trusted base images are used.
- Permissions: Limiting the privileges containers can run with.
- Malware: Detecting malicious code within artifacts.
- Secrets: Finding hardcoded credentials or API keys.
The Aqua CLI (aqua) is your primary tool for interacting with the scanner in CI/CD. You’ll use commands like aqua scan, aqua config, and aqua login. For orchestrators like Jenkins, GitLab CI, GitHub Actions, or CircleCI, Aqua provides plugins or Docker images that contain the necessary tools.
Consider how Aqua handles drift detection in Kubernetes. When you deploy a pod, Aqua records its expected state based on the image, configuration, and runtime policies. If, at runtime, the pod’s process list deviates from what’s expected (e.g., a new, unauthorized process starts), Aqua can alert you or even terminate the pod. This isn’t a firewall; it’s a behavioral anomaly detector specifically for your containerized workloads, integrated directly into your deployment pipeline’s visibility.
The one thing that trips up many teams is the granularity of policy enforcement. It’s tempting to set a single, broad policy like "fail on any critical vulnerability." However, Aqua excels when you tailor policies to specific application tiers or environments. For instance, a development environment might tolerate higher-risk vulnerabilities that are patched in the production build. You can create policies that allow specific CVEs in development scans but fail them in staging or production scans, using tags and environment variables to differentiate. This allows for iterative security without blocking rapid development cycles.
The next step after integrating Aqua into your CI/CD is to leverage its runtime security features to continuously monitor your deployed applications.