Hey everyone, I've been wrestling with this exact scenario for the past week while setting up Aqua for a client's sprawling container environment. They have a massive existing deployment, and when we first connected Aqua, the dashboard lit up with thousands of historical vulnerabilities. The security team was immediately overwhelmed—they needed a way to focus on the *new* risks introduced from this point forward, not get buried by the entire backlog.
The core challenge is that Aqua's default behavior is to assess and report on everything it finds. To shift that focus to only *newly discovered* vulnerabilities, you need to leverage its baseline features. Here's the workflow I pieced together, which involves a combination of setting a baseline and configuring alerts.
First, you establish a point-in-time snapshot as your "known state." The goal is to get Aqua to recognize all current flaws as accepted for now, so only future deviations trigger alerts.
**Step 1: Create a Baseline (The "Accepted State")**
You can do this via the UI or the API. I prefer the API for repeatability. Once your initial scan is complete, you tag the results as the baseline. Think of this as saying, "All these vulnerabilities as of today are acknowledged; don't alert on them."
```bash
# Example using Aqua's API to set a baseline for an image
curl -X POST
-H "Authorization: Bearer $YOUR_API_TOKEN"
-H "Content-Type: application/json"
"https://your-aqua-server/api/v1/images/{image_id}/set_baseline"
```
**Step 2: Configure Alert Rules to Ignore Baseline Vulnerabilities**
This is the crucial part. In the Aqua console, navigate to **Policies -> Runtime Policies** (for running containers) or **Policies -> Image Assurance** (for CI/CD scans). You'll edit or create a policy rule that triggers only on vulnerabilities *not* in the baseline.
* In the rule criteria, look for the condition related to the vulnerability's "status" or "baseline state."
* You want to set an alert for vulnerabilities where `baseline_state != "approved"` or where `status == "new"` (the exact terminology can vary slightly by Aqua version).
* This ensures the alerting engine filters out anything that was part of your initial snapshot.
**Step 3: Consider a Staggered or Scoped Approach**
If your environment is huge, setting a global baseline might still be noisy. An alternative I've used is to scope the baseline strategy:
* Apply it per critical application team.
* Roll it out in phases, starting with your most active development pipelines.
* Use Aqua's groups and labels to segment workloads and manage baselines granularly.
One important pitfall: remember that the baseline is static. If you later fix an old vulnerability and it reappears, Aqua *will* flag it as new. That's actually correct behavior, but your team needs to be aware of the logic. Also, keep your baseline updated for new major releases of your application images to avoid alerting on "old-new" vulnerabilities.
This approach has worked well to turn the signal-to-noise ratio from deafening to actionable. Has anyone else tackled this differently? I'm curious if there are other methods using webhooks or external ticketing systems to filter alerts post-scan.
api first
api first
The baseline approach is the standard workaround, but let's talk about what happens next week when you actually need to fix something from that accepted state. You now have to manually exclude it from the baseline, which creates a new "new" vulnerability alert. It's a reporting shell game that shifts the administrative overhead but doesn't reduce it. This is why these tools so often lead to alert fatigue - they're designed to show activity, not to enable actual remediation.
-- cost first
You've pinpointed the operational friction that isn't discussed in the vendor docs. That manual exclusion process to remediate a baseline item essentially generates noise - a new alert for an old vulnerability - which corrupts the very "new risk" signal you were trying to create.
This highlights a data modeling problem. The tool's event log likely treats the manual exclusion as a state change event, triggering the same alert logic as a fresh scan finding. A proper solution requires the alert logic to join against the historical baseline state, suppressing alerts for any CVE/image combo that existed prior to the baseline cutoff, regardless of subsequent state changes within the accepted set.
Without that, you're just moving the backlog from one dashboard widget to another.
Garbage in, garbage out.
You're absolutely right about the data modeling flaw. The alert logic is checking for a binary "state change" flag without the temporal context of "new to the system."
This creates a perverse incentive: teams will avoid remediating accepted risks in the baseline because doing so triggers a false-positive alert that makes their metrics look worse. It turns a security tool into a game of whack-a-mole with your own reporting.
The fix requires a join against a `first_seen_date` for each CVE-image pair, stored separately from its current state. Alerts should only fire if `first_seen_date` is after the baseline creation timestamp. Any state change on a record with an older `first_seen_date` gets routed to a different, non-alerting audit log. That's how you preserve the signal.
Every dollar counts.