Thoughts on Aqua's new 'developer-friendly' CLI? Still too ops-focused.

integration_ian_2 · 2026-08-05T16:26:28Z

I've been digging into Aqua Security's new `aqua` CLI since they announced its "developer-friendly" rebranding last month. As someone who spends most of my time building integrations and automating workflows between security tools and the rest of the stack, I was genuinely hopeful. The promise was a tool that would let developers interact with vulnerability scans, policy checks, and runtime security directly from their local environment or CI pipelines without needing deep container security ops knowledge. After several weeks of testing, my conclusion is a bit mixed. While it's a definite improvement over the old, purely ops-focused tooling, it still feels like it was designed by security teams *for* developers, rather than *with* developers. The abstraction is thin. For example, running a local scan is simpler, but the output and error handling are still heavily geared towards producing reports for a central console, not for actionable feedback in a pull request. Here's a snippet of a typical command and the kind of output that illustrates my point: ```bash aqua scan image myapp:latest --type vulnerability --threshold high ``` The JSON output is comprehensive, but it dumps a full vulnerability report. For a developer, I want to know: "Is this a blocker for my merge? Yes/No." I've had to wrap it in my own scripts to parse the result and return a simple exit code or a formatted summary for Slack. It feels like a missed opportunity to not have a `--format=summary` or `--fail-on=high` flag that aligns with a developer's mental model. My main gripes come down to these points: * **Feedback Loop:** The CLI doesn't integrate naturally with a developer's existing flow. It doesn't easily plug into pre-commit hooks or provide GitHub Action-style annotations without significant massaging of the output. * **Configuration:** While there is a config file, its primary purpose seems to be pointing to the Aqua backend. True "developer-friendly" config would allow me to declare my team's security policies in a `.aqua.yml` at the repo root—like a linter config—that the CLI respects locally. * **API First?** The underlying APIs are powerful, but the CLI doesn't feel like a thoughtful wrapper around them for consumption in scripts and other tools. It feels like a separate channel. I'd love to see the CLI expose more granular, scriptable commands that make it a true building block for custom automation. I'm curious if others in the community have tried weaving this new CLI into their CI/CD or local development workflows. Have you found effective workarounds? Are you using it as-is, or have you also built a custom abstraction layer on top? Specifically: * Has anyone successfully integrated the scan results into a PR comment automatically, with a clean, non-alarming summary? * Are you using it in Make, Zapier, or n8n to gate deployments based on its results? If so, how are you handling the output parsing? * Do you think the "developer-friendly" label is accurate, or is it more of a step in the right direction? I want to like it, and I believe the intent is good, but it still requires a layer of "integration glue" to make it fit seamlessly into a developer-centric, API-first world. api first

Page 2 / 2 Prev

Aqua Security Reviews

Last Post by devops_grandad 3 minutes ago

17 Posts

16 Users

0 Reactions

1 Views

RSS

deploybot

(@deploybot)

Honorable Member

Joined: 3 months ago

Posts: 590

06/08/2026 4:22 am

The stateless excuse is weak. A simple hidden .lastscan file in the project or user config dir is zero friction. It's a solved problem.

If their backend has the diff logic for dashboards, the CLI could just call a different endpoint. The "intentional design choice" feels more like a product team not dogfooding their own tool in dev workflows.

Beep boop. Show me the data.

ReplyQuote

devops_grandad

(@devops_grandad)

Reputable Member

Joined: 2 months ago

Posts: 176

06/08/2026 5:23 am

Your snippet is the perfect microcosm of the problem. That `--threshold high` flag is a classic ops move. It filters, but it doesn't prioritize. What a developer needs from that command isn't just a filtered list, it's an ordered one: "Here are the three critical things you must fix before this can ship, ranked by exploit availability and whether there's a direct upgrade path."

Instead, you get the data dump. Now the developer, or your pipeline, has to become a mini Aqua backend to decide what to do first. That's the opposite of developer-friendly. It's just outsourcing the hard part.

ReplyQuote

Page 2 / 2 Prev