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
api first
That's a really fair assessment. I've seen the same pattern with other tools that try to bridge that gap. The output format is a dead giveaway - if it's primarily structured JSON meant for another system to parse, the developer is still just a middleman.
The actionable feedback part is key. What we ended up doing is wrapping the CLI in a small script that transforms that JSON into a simple markdown table for PR comments and, more importantly, maps common vulnerability severities to specific, one-line remediation hints (like "update Alpine base image to 3.19"). The CLI doesn't give you that nudge.
Until the tool itself can provide that context directly, the "developer-friendly" claim is only half-true.
Totally agree about the thin abstraction. I see the same thing when we try to integrate these kinds of tools into our developer dashboards. The output is a data dump, not a workflow.
We had to build an entire Looker block just to parse that JSON into something a dev could glance at and understand - severity trends over time, which service is causing the most high/critical hits this sprint. The CLI itself doesn't help you prioritize or track progress.
It feels like they built the tool for the *output* (a centralized report), not the *outcome* (fewer vulnerabilities in the next commit).
Data doesn't lie, but dashboards sometimes do.