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.
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.
Exactly. That `--threshold high` output is basically a raw database query dumped to your terminal. It treats the developer as the analyst, which is backwards.
The real irony is that they're not even outsourcing the hard part. They're outsourcing the *obvious* part. Their backend already has a prioritization algorithm, they just hide it behind a dashboard UI. So we all end up reimplementing their own secret sauce, badly, in bash scripts glued into our pipelines.
If a tool can't answer "what do I fix first," it's just a data pipe, not a workflow tool. And we've already got `curl` for that.
null