So you want to gate your merges with Aqua's scan results. Good idea in theory, a classic vendor promise, but the integration path is predictably more about locking you into their ecosystem than seamless CI.
First, forget the "one-click" integration they probably showed you in the sales deck. You're looking at a multi-step process that involves:
* **Their SaaS API or an on-prem Trivy wrapper:** You'll need to run `aqua scan` in your pipeline, which is just their fork of Trivy with extra bells and whistles to justify the premium price. This means managing another scanner instance and its config.
* **Parsing their proprietary JSON output:** The scan results need to be transformed into something GitLab can understand. You'll be writing a custom script to convert Aqua's output into GitLab's security report schema. This is where they get you—their format is unique, so your integration script becomes a maintenance burden.
* **Setting pass/fail thresholds:** This is the real minefield. Do you fail the pipeline on *any* Critical? What about Highs in dev dependencies? You'll spend more time tweaking these policies than you think, and Aqua's documentation on this is... optimistic.
The real cost isn't the pipeline step itself. It's the operational overhead of managing the scanner, updating the integration scripts every time they change an API field (which they will), and dealing with the false positives that inevitably slip through. Suddenly, your devs are blocked on MRs because of a vulnerability in a package that isn't even deployed.
And a word of caution: if you're using their full platform, this pipeline data will be fed back into their console. Great for visibility, but also a perfect way for your sales rep to later argue for more licenses because "look at all this scanning activity you're doing."
Has anyone actually gotten this to work reliably without a dedicated FTE to babysit the integration? What were the hidden time-sinks you encountered?
Trust but verify.
You're right about the parsing being the tricky bit. I hit the same wall last quarter.
We ended up using their JSON output with jq in a GitLab job to map critical fields to the GitLab security report format. It's not pretty, but it works. The real headache came with those pass/fail thresholds - we had to adjust them per project because our legacy apps kept blocking merges on outdated dev dependencies.
Maybe their newer CLI versions handle the conversion better, but we're stuck maintaining our script for now.
Ship fast, measure faster.
Thresholds are the real blocker. I've had to set `severity: CRITICAL` only for net-new services because legacy codebases would never pass. It's a policy problem disguised as a config one.
If you're maintaining a conversion script, check if you're using the `--format json` output with their `--template` flag. Sometimes you can get a cleaner transform there, but it's still vendor-lock in.
Their newer CLI just wraps the JSON in more metadata. You still need jq to extract what GitLab wants.