Aqua Security’s vulnerability scanner, Aqua, can generate a massive amount of findings. Manually triaging these and creating Jira tickets is a bottleneck. This integration automates that process, ensuring vulnerabilities are tracked and addressed.
Here’s Aqua Security in action, automatically creating a Jira ticket for a high-severity vulnerability found in a container image:
# Example Aqua Security Scan Result (simplified)
vulnerability:
id: CVE-2023-12345
severity: HIGH
name: "Example High Severity Vulnerability"
package:
name: "libexample"
version: "1.2.3"
container_image: "my-registry/my-app:latest"
description: "A critical vulnerability in the libexample library allows for remote code execution."
fix_version: "1.2.4"
# Corresponding Jira Ticket Creation Payload (simplified)
jira_ticket:
project: "SEC"
issuetype:
name: "Vulnerability"
summary: "[Aqua] HIGH - CVE-2023-12345 in libexample (my-registry/my-app:latest)"
description: |
**Vulnerability ID:** CVE-2023-12345
**Severity:** HIGH
**Package:** libexample
**Version:** 1.2.3
**Image:** my-registry/my-app:latest
**Description:** A critical vulnerability in the libexample library allows for remote code execution.
**Fix Version:** 1.2.4
**Aqua Scan URL:** https://app.aquasec.com/findings/123456789
labels:
- "aqua"
- "vulnerability"
- "high-severity"
- "cve"
components:
- name: "libexample"
version: "1.2.3"
The primary problem this integration solves is the sheer volume of security findings generated by Aqua Security. Without automation, security teams spend countless hours manually reviewing scan results, determining severity, assigning ownership, and creating tickets in Jira. This leads to delays in remediation, increased risk, and inefficient use of security personnel.
Internally, the Aqua Security platform continuously scans container images, Kubernetes clusters, and other cloud-native workloads for vulnerabilities, misconfigurations, and malware. When a finding is generated, Aqua’s backend processes enrich it with context like CVE details, CVSS scores, and available fix versions. The integration then acts as a bridge: it monitors Aqua for new, high-priority findings (configurable, but typically HIGH and CRITICAL severities) and, using Aqua’s API, formats this data into a structure that Jira’s API understands. This structured data is then sent to Jira to create a new ticket.
The exact levers you control are primarily within Aqua Security’s integration settings and your Jira project configuration. You can define:
- Severity Thresholds: Which severity levels (e.g., LOW, MEDIUM, HIGH, CRITICAL) should trigger Jira ticket creation.
- Ticket Project: The specific Jira project where tickets will be created.
- Issue Type: The type of Jira issue (e.g., "Vulnerability," "Bug," "Task").
- Summary Template: How the Jira ticket’s summary line is constructed, allowing you to include details like severity, CVE ID, package name, and image.
- Description Template: The format of the ticket’s description, enabling you to include all relevant details from Aqua’s finding, including links back to the Aqua console for deeper investigation.
- Labels: Which labels to apply to the Jira tickets for easier filtering and reporting.
- Assignee/Reporter: While not always directly configurable in the integration itself, the Jira project’s default settings or workflow can determine initial assignment.
- Deduplication: Many integrations support mechanisms to avoid creating duplicate tickets for the same vulnerability in the same image, often by checking existing Jira tickets based on a unique identifier (like CVE ID + image hash).
The most surprising aspect of this automation is how effectively it can surface contextually relevant, actionable information directly into development workflows. It’s not just about creating a ticket; it’s about creating a useful ticket. For instance, the integration can be configured to automatically include the fix_version from Aqua directly into the Jira ticket’s "Fix Version/s" field if your Jira project is set up to use that field. This immediately tells developers what version of a package they should be upgrading to, bypassing an entire manual step of looking up that information themselves after seeing a generic vulnerability description.
Once tickets are created, the next logical step is to ensure they are triaged and remediated, which often involves setting up Jira workflows that automatically transition tickets based on their status or assignment, or integrating with CI/CD pipelines to prevent vulnerable images from being deployed.