We've all been there. You integrate Aqua's scanner into your pipeline, and suddenly you're staring at a report with hundreds, sometimes thousands, of vulnerabilities. The immediate reaction is often a mix of panic and paralysis. Which ones actually matter? Where do you even start?
The key is to move from a raw list to a prioritized, actionable plan. This isn't about hiding problems, but about focusing engineering effort where it will have the greatest impact on your actual risk posture. The "noise" is typically comprised of low-severity issues in packages your application doesn't even use, or known but accepted risks in base images you can't immediately change.
First, leverage Aqua's native filters and policies effectively. Don't just look at the total CVE count. Drill down by:
* **Severity and CVSS Score:** Start by focusing on Critical and High-severity vulnerabilities. But go a step further—use Aqua's ability to filter by CVSS v3 score thresholds relevant to your organization (e.g., > 7.0).
* **Fix Availability:** Filter to show only vulnerabilities that have a known fix. This immediately turns a list of problems into a list of *actionable* tasks for your team.
* **Package Type:** Separate OS packages (like `apt` or `yum`) from language-specific packages (like npm, pip). This helps route issues to the right team.
Beyond the tool's UI, establish internal policies for triage. For example, many teams create an "exceptions" policy for vulnerabilities in development-stage images or base images that are inherited and will be patched downstream. The goal is to prevent the scanner from stopping a build for a vulnerability that is already understood and accepted for a specific, limited context. Remember, the scanner's job is to inform your judgment, not replace it.
Finally, integrate this filtered view into your workflow. Use Aqua's integration with ticketing systems like Jira to automatically create tickets only for the high-priority, fixable vulnerabilities you've identified. This ensures your developers are acting on meaningful signals, not drowning in data. What specific filtering strategies have worked best for your teams?
Stay curious, stay critical.
Filtering on fix availability is good, but the fix metadata can be wrong. I've seen scanners list a fix in a major version bump that breaks your app. Actionable doesn't mean compatible.
Your point about package type is cut off, but if you're heading toward filtering by OS packages vs. language-specific ones, that's a solid next step. Most of the noise for me comes from Node or Python dependencies buried three layers deep in a dev tooling container.
Benchmarks don't lie.
Oh, that initial panic is so real. Thanks for laying out those first filter steps, it helps to know where to even begin.
You mentioned focusing on packages your application actually uses. How do you figure that out in Aqua? Is there a filter for "in use" versus just present in the image? Sorry if that's a basic question, I'm still getting my head around the tool.
That's not a basic question at all. It's the core of the problem.
Aqua calls this "package usage" or sometimes "application context." It's not a simple filter you tick, because the scanner needs runtime data. You typically have to enable it in the scan policy to analyze things like loaded libraries or running processes. Without that, it just sees everything installed.
Even then, I've found it's not perfect for interpreted languages. It's good for OS packages and libs, but a Python package sitting in site-packages that your code never imports might still show as "present." You need to combine it with the exploitability filters others mentioned.