Guide: Filtering out the noise in Aqua's vulnerability reports.

You've hit the classic problem: turning scanner output into a work queue. Filtering is a business logic problem, not a technical one. You need to encode your organization's actual risk tolerance into that pipeline.

I'd suggest starting with a multi-stage filter in your enrichment process. First, suppress everything from known-good base image layers if they're truly immutable in your deployment chain. Then, apply a CVSS score cutoff, but be careful - I've seen teams start at 7.0 (High) only to realize they still have thousands of items. Aqua's own risk scores can be useful as a secondary filter, but they're just another heuristic. The real trick is adding context about whether the vulnerable component is actually loaded at runtime.

A practical first pass we used looked something like this in a transformation step:
```
WHERE NOT (image_layer LIKE '%distroless%' AND severity = 'Low')
AND cvss_score >= 6.5
AND fix_available = True
```
That at least surfaces things you can actually act on. Ignoring everything without an available fix is another good noise reducer.

But that's just the start. You'll eventually need to correlate with runtime data to see what's actually exposed.

You're right to start with filtering, it's the only way to make the data actionable. I'd suggest looking at the exploit maturity field in Aqua's reports as a key early filter. A low-severity vulnerability with a known exploit is often a higher priority than a high-severity one that's theoretical.

A good first step is to create a policy that suppresses findings from base images you've formally approved, but only if your deployment process truly prevents those layers from being changed downstream. The risk is inheriting a new vulnerability in an image you think is static.

We also found it useful to correlate Aqua data with runtime context from our orchestrator. If a vulnerable package isn't actually loaded, it can drop way down the fix queue. That's a more advanced step, but something to plan for.

I like the point about exploit maturity being a key filter. We're just starting to look at that field, and it's tricky. Aqua sometimes marks things as "high" exploitability but the CISA KEV isn't populated yet. Do you treat those the same as a confirmed KEV entry?

The runtime context idea is a good goal, but it feels like a separate pipeline phase. I'm thinking we need to get the base filtering stable first, then add that enrichment later. Did you find it generated a lot of false negatives when you started correlating?

Good questions. On your first point about exploit maturity, I treat a scanner's "high" label as a strong signal, but not equivalent to a KEV listing. I'd prioritize KEV entries first, then use the "high" exploitability findings as a secondary queue. It's about resource allocation - confirmed exploits get immediate action, while potential ones get scheduled review.

You're right to tackle base filtering first. Adding runtime context does introduce complexity. In our case, the false negatives were minimal, but they almost always came from edge cases where a package was loaded dynamically or under very specific conditions. Starting with a stable filter set is the wise move. You can add that enrichment layer once your team trusts the initial pipeline's output.

You're right to focus on prioritization from the start. I approach this with a layered policy, using Aqua's data as one input into a broader scoring system. We don't rely on a single CVSS cutoff because, as you've seen, it's still noisy.

We start by mapping findings to our actual stack context. A key first filter is the image layer. We maintain a list of approved, patched base images. Any vulnerability found exclusively in those layers is automatically suppressed, but only after we verify our build process doesn't modify them. This cut our initial volume by about 40%. For the rest, we combine CVSS (we start at 7.0+), Aqua's risk score, and most importantly, the "Has fix" flag. A High severity with an available patch jumps the queue.

The example policy we feed into our pipeline logic looks like this:
- Suppress: Vulnerability in approved base image layer AND CVSS < 7.0.
- P3 (Low Priority): CVSS = 7.0 AND "Has fix" = true.
- P1 (Immediate): CVSS >= 7.0 AND "Exploit exists" = true OR listed in CISA KEV.

This gives us a clear, actionable tiered list. The runtime context correlation others mentioned is a valuable next step, but getting this deterministic filtering in place first is crucial.

Oh man, I feel this! Just went through the same with our ClickUp setup. That initial flood is paralyzing.

We started by locking down a list of "golden" base images and suppressing everything from those layers. It cut the noise in half overnight. But like everyone's saying, you gotta be sure your builds don't mess with those layers later.

A weird thing we learned: sometimes the "Has fix" flag in Aqua is more important than the CVSS score. A medium with a patch ready to go often gets fixed before a high that needs more work. Do you check that flag in your first filter pass?

Treating a scanner's "high" exploitability rating the same as a confirmed KEV entry is a fantastic way to burn out your team on false positives. The scanner's rating is a prediction, often based on generic metrics. A KEV entry is a statement of fact: it's being actively used to break into places. That's the difference between a weather forecast for rain and water dripping on your head.

Your instinct to build stable base filters first is the only sane path. Runtime correlation is a massive can of worms. We tried it early and yes, it absolutely generated false negatives, specifically with interpreted languages where dependencies can be pulled at execution time in ways the scanner and orchestrator don't see. Get your team to trust, and more importantly *act on*, the output of a simple filtered pipeline first. Once that's a habit, maybe then consider adding the complex, leaky abstraction of runtime context.

Totally feel that initial overwhelm, it's a rite of passage with any good scanner! The good news is you're thinking about filtering from day one, which is smart.

A practical first step that worked for us was a simple, three-layer filter applied right as the reports hit our system. We focused on what we could actually act on *now*. First, we suppressed anything in our blessed, immutable base images (like a specific, patched alpine version). That cut a ton. Then, we filtered out anything below CVSS 6.0, just to clear the trivial stuff. The final, most important gate was the "fix available" flag. A vulnerability with a ready patch, even at medium severity, jumped to the front of the line because we could actually resolve it immediately. This gave our devs a clear, actionable queue from week one.

It's tempting to build the perfect multi-factor scoring system right away, but starting with these simple, defensible rules builds trust. You can always add complexity later, like exploit maturity or runtime context, once the team is used to consuming the filtered list. What does your team's deployment cycle look like? A faster cycle might let you be more aggressive with that base image filter.

Your point about the "Has fix" flag is crucial. We actually ran into a situation where it became our primary filter, after CVSS alone kept giving us high-severity, theoretical vulnerabilities in end-of-life components with no available patches. It was demoralizing for the team.

We check it in the first pass now, but with a caveat: we had to validate that the "fix" Aqua is reporting aligns with an upgrade path our application can actually take. Sometimes it flags a major version bump as the fix, which might break compatibility for us. So our policy looks for the flag and then checks if the fix version is within the same major release we've pinned to. If it's not, it gets tagged for manual review instead of immediate action.

That way, the "actionable now" queue truly contains things we can resolve without a major refactor.

Validating the fix version against your own versioning policy is a smart next step. We had to add a similar check after our initial "Has fix" filter pushed through several breaking changes.

We ended up building a small lookup table that maps our acceptable upgrade paths per package family, using semver rules. The policy logic now checks if Aqua's reported fix version satisfies a `>= current, < next-major` constraint for that package. If it doesn't, the finding gets routed to a separate "requires dependency review" board instead of the main queue.

It adds a bit of maintenance, but it kept the main pipeline's output truly actionable.

That's a solid approach, and it mirrors the evolution we had to follow. The lookup table for acceptable upgrade paths is key, but we found the maintenance overhead became nontrivial as our estate grew.

We ended up integrating our policy with a dedicated dependency management tool (Dependabot, Renovate) to automate that version constraint logic. Instead of maintaining our own table, the filter now checks if the fix version matches an upgrade the bot has already proposed and deemed safe. This shifts the maintenance burden to the bot's configuration, which is often already managed.

It does add another integration point, but it ensures our "actionable" queue aligns with pre-vetted, automated remediation paths.

Integrating with the existing bot configuration is a clever way to reduce toil. We considered that path but hesitated because it creates a dependency on the bot's own accuracy and update frequency.

Our team found that Dependabot's safety checks don't always align with our specific compatibility matrix, especially for in-house libraries. We had to add a secondary filter to catch those cases, which partially reintroduced the maintenance overhead we were trying to avoid. The integration is powerful, but it assumes your bot's scope covers 100% of your findings.

The initial flood is brutal, but you're on the right track. Starting with "golden" base image suppression is the single biggest noise cut. I'd prioritize that filter before you even look at CVSS.

One caveat from my own mess: don't just rely on Aqua's risk score or CVSS alone for the rest. We found the "Has fix" flag to be the best prioritizer after the base layer filter, because it shows you what you can actually solve right now. Even a medium with a patch gets fixed before a high without one.

Just be ready to validate that "fix" version later, as it can sometimes suggest a major version jump that'll break your build. Good luck with the pipeline.

Right on about validating that fix version. We learned that the hard way when the "has fix" flag pushed us to upgrade a core library to a version that required a Python bump our app wasn't ready for. It created a blocker, not a fix.

Now our rule checks the fix version against our current pinned major. If it's outside, it goes to a manual review lane. It keeps the main queue clean for truly immediate actions.