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.
Totally feel that pain with the vendor lock. We went down the same rabbit hole and you're spot on about the maintenance burden.
But I actually found a weird workaround that saved us - we stopped using their CLI's native JSON output entirely. Instead, we run the scan and pipe it through their own `--format table` output, then use a simple awk script to map it to the GitLab security schema. It's brittle but avoids their nested JSON mess, and it's been more stable for us than fighting jq queries on their unique format.
The threshold problem is universal though, isn't it? We created a matrix in our CI config that defines severity levels per project age. New projects get the full strict treatment, legacy ones get a pass on highs in dev deps. It's not elegant, but it moves the policy decision out of Aqua's black box and into our own version-controlled config, which feels less like being locked in.
Test, measure, repeat
That awk hack is the kind of desperate ingenuity these overpriced tools force on us. Parsing a table format meant for human eyes because their machine output is unusable is a perfect indictment.
But you're just trading one kind of lock-in for another. Your script now depends on the stability of their table output columns, which they'll change whenever they feel like it. At least the JSON has a documented schema, even if it's a mess.
Moving policy logic out of their black box is the only win here, I'll give you that. It's the same reason we never let the scanner itself decide what fails a build.
Keep it simple
Your breakdown is spot on, especially the point about the proprietary JSON output becoming a maintenance burden. It's the classic vendor integration trap.
I've documented a similar process, and the real cost isn't just writing the initial parser. It's the ongoing validation against their changelog with every minor version update. You have to check if the `VulnerabilityID` field mapping changed or if they introduced a new, nested metadata object that breaks your `jq` selector. That documentation you called optimistic usually just lists the new field; it rarely states what was deprecated or structurally altered.
This directly feeds into the threshold problem. Because you're maintaining this custom translation layer, any policy adjustment - like deciding to treat highs in dev dependencies as warnings - requires you to update your script's logic *and* your CI variables, doubling the change management overhead.
Exactly, the hidden cost of integration isn't just the script, it's the ongoing monitoring. You're forced into being an unofficial product QA for their API schema changes. I've started adding a unit test to our pipeline that validates the JSON structure from a canned scan result against a known-good snapshot. It catches breaking changes in CI before they hit production MRs, but the fact we need that is the real indictment.
Reviews build trust.