ActiveState and Trivy reduce CVE noise in open source scanning

At a glance

What this is: Aqua Security describes a Trivy integration with ActiveState advisory data that reduces CVE alert noise by filtering non-exploitable findings and adding remediation options.

Why it matters: Security teams managing developer workflows need to separate true exposure from unnecessary findings so vulnerability scanning stays actionable without overwhelming engineers.

By the numbers:

• Aqua Security says it protects over 500 of the world’s largest enterprises.

Context

CVE noise is a governance problem when scanners produce more findings than teams can triage, validate, and act on. In open source scanning, the practical issue is not only whether a CVE exists, but whether it is exploitable in the way a specific artifact is deployed and consumed.

This article is about vulnerability signal quality in developer-facing scanning workflows. Aqua Security frames the Trivy integration as a way to reduce alert fatigue by adding advisory context and exploitability data, which matters because noisy findings can slow remediation and reduce trust in the scanning programme.

Key questions

Q: How should security teams reduce CVE noise without losing real risk signals?

A: Use exploitability context to separate actionable vulnerabilities from inherited or non-reachable issues, then apply policy-based triage instead of treating every match as urgent. The goal is to preserve visibility while routing remediation effort to the findings that change attack surface. That keeps security credible to developers and reduces unnecessary interruption in delivery pipelines.

Q: Why does CVE noise create security risk instead of just inconvenience?

A: Because repeated low-value alerts train teams to discount the queue. When developers assume most findings are not worth action, they delay or ignore the rare alert that really matters. That turns alert fatigue into a governance failure, since prioritisation quality is what keeps scanning programmes trusted and operationally useful.

Q: What signs show that vulnerability triage is failing in developer pipelines?

A: Watch for rising exception rates, long backlogs, repeated re-opening of the same issues, and frequent manual overrides of scanner output. Those signals usually mean the programme is producing more findings than teams can validate, or that the advisory context is too weak to support confident decisions.

Q: How do you keep open source scanning actionable for developers?

A: Give engineers package-level context, a clear remediation path, and a prioritisation model that treats exploitability as the deciding factor. If the workflow only reports CVE counts, developers will spend time on noise rather than fixing the exposures that actually affect deployed software.

Technical breakdown

Why VEX changes vulnerability signal quality

VEX, or Vulnerability Exploitability eXchange, adds exploitability status to a vulnerability finding so a scanner can distinguish between a disclosed CVE and a CVE that has been assessed as non-exploitable in a given context. That matters in open source scanning because the same package may appear in many environments with different reachability, configuration, and exposure characteristics. When exploitability context is missing, teams often treat every hit as equally urgent, which inflates queues and weakens triage discipline. In practice, VEX does not remove risk. It changes the decision boundary from raw detection to governed validation.

Practical implication: Use exploitability context to route only the findings that need remediation and keep non-exploitable CVEs out of urgent queues.

How advisory feeds improve scanning for containers and language packages

An advisory feed is a curated layer of package security intelligence that enriches scanner output with vendor or maintainer guidance, remediation paths, and context about affected artifacts. For open source scanning, that means the scanner can move beyond package name matching and version comparison toward more operationally useful results for containers and language packages. The important architectural point is that the scanner is still dependent on external trust signals. If the advisory source is incomplete or stale, the signal quality problem simply moves upstream rather than disappearing.

Practical implication: Tie scanner decisions to a governed advisory source and validate how quickly it reflects package changes and remediation guidance.

Where alert fatigue becomes an identity and workflow issue

Alert fatigue is often discussed as a productivity problem, but for developers it becomes a control problem when repeated low-value findings cause people to ignore, defer, or batch alerts without review. In CI and software delivery pipelines, that behaviour can normalise exception handling and weaken the link between vulnerability detection and secure change management. The governance question is whether the organisation can preserve developer throughput while still forcing meaningful review of genuinely exploitable CVEs. If not, the programme risks measuring scan volume instead of security outcomes.

Practical implication: Measure whether scan findings are being triaged by risk, not just counted, and watch for exception patterns that hide real exposure.

NHI Mgmt Group analysis

CVEs are not the problem if the programme cannot distinguish exploitable from non-exploitable exposure. Vulnerability scanners create noise when they collapse discovery, context, and severity into a single queue. VEX-backed advisory data changes that by making exploitability a governance decision rather than a blanket assumption. The practitioner lesson is to treat triage quality as part of the vulnerability control itself.

Open source scanning fails when package-level visibility is disconnected from deployment context. A CVE in a library does not automatically equal a material risk in every container or pipeline, and that distinction matters more as software supply chains become denser. Advisory feeds help because they add context, but they also raise the bar for data quality and freshness. Teams should judge the workflow by how well it reduces false urgency without missing real remediation paths.

Alert fatigue is a control degradation signal, not merely a user-experience complaint. When developers learn that most findings are non-actionable, they start to discount the queue, and governance quality declines with it. That is why signal precision matters as much as scan coverage. The practitioner conclusion is simple: a vulnerability programme that cannot preserve trust in its own prioritisation logic will eventually lose compliance and remediation effectiveness.

Signal quality has become the decisive variable in developer-facing vulnerability management. The named concept here is advisory-fed CVE suppression: using exploitability context to filter noise without suppressing accountability. That pattern is increasingly relevant wherever open source scanning is embedded directly into delivery pipelines. The governance objective is not fewer findings in the abstract, but fewer misleading findings in the hands of engineers.

Remediation guidance only helps when it is tied to the exact artifact that failed validation. If the advisory layer says a CVE is real, the workflow still needs enough specificity to tell teams which container image or package version to change. Otherwise, the organisation shifts from alert noise to remediation ambiguity. Practitioners should demand artifact-level traceability from scan output to fix path.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: NHI Lifecycle Management Guide

What this signals

Advisory-fed suppression is becoming a practical control pattern for application security teams. The important shift is not from detection to reduction, but from unfiltered vulnerability volume to governed exploitability decisions. That matters in pipelines where engineers will only trust scanning if the queue reflects real exposure rather than inherited package noise.

Open source scanning now depends on whether organisations can operationalise package intelligence fast enough to matter. If advisory context arrives late, developers still absorb the alert burden before triage can reduce it. The practical question is whether the scan result helps a team decide in minutes, not whether it merely identifies a CVE.

For practitioners

• Prioritise exploitability over raw CVE count Tune scanning workflows so non-exploitable findings are separated from actionable issues before they reach developer queues or ticketing systems.
• Validate advisory feed freshness Check how quickly advisory updates reflect newly assessed packages, changed exploitability status, and updated remediation options for containers and language packages.
• Route findings by artifact context Make sure scan output identifies the specific open source artifact, image, or package version so teams can apply the correct fix without manual correlation.
• Track alert fatigue as a security metric Measure how often developers dismiss, defer, or override vulnerability findings, because repeated low-value alerts usually indicate the triage model is failing.

Key takeaways

• CVE noise becomes a governance issue when scanners cannot distinguish exploitable findings from contextually irrelevant ones.
• The article ties Trivy enrichment to advisory data and VEX so teams can suppress non-exploitable alerts and keep valid remediation paths visible.
• Programmes should be judged by signal quality, developer trust, and artifact-level traceability, not by vulnerability count alone.

Key terms

• Vex: VEX, or Vulnerability Exploitability eXchange, is a way to state whether a known vulnerability is exploitable in a specific product, build, or deployment. It helps security teams avoid treating every matching CVE as equally urgent and improves prioritisation in software supply chains.
• Advisory Feed: An advisory feed is a curated source of security intelligence about software packages, vulnerabilities, and remediation options. In scanning workflows, it enriches raw detection results so teams can make risk decisions based on context rather than on CVE identifiers alone.
• Alert Fatigue: Alert fatigue is the condition where a security team receives so many low-value alerts that important events become harder to notice. In monitoring programs, it usually signals poor rule tuning, weak prioritisation, or a mismatch between detection logic and operational reality.
• Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.