ActiveState and Trivy reduce CVE noise in open source scanning

At a glance

What this is: Aqua Security says ActiveState’s advisory feed is now integrated into Trivy to reduce CVE noise and improve risk profiling for open source artifacts.

Why it matters: This matters because IAM, NHI, and platform teams need clearer vulnerability signals to avoid overreacting to non-exploitable findings while still prioritising genuine remediation work.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.

👉 Read Aqua Security's analysis of ActiveState advisory integration for Trivy

Context

CVE noise is a governance problem as much as a tooling problem. When scanners surface large volumes of findings without clear exploitability context, teams waste time chasing issues that do not change risk, and real exposure can get lost in the backlog. For open source artifacts in software supply chains, the question is whether vulnerability telemetry is precise enough to support action.

For identity and platform teams, this matters because the same operational pattern appears across machine identities, secrets, and developer workflows: too many alerts, too little prioritisation, and weak confidence in what actually needs remediation. Aqua Security’s framing is about reducing false urgency while preserving meaningful risk visibility, which is the right question for modern cloud-native programmes.

In practice, the starting point is typical for mature environments that already scan heavily but still struggle to convert findings into decisions. The issue is not absence of detection, but poor decision quality under volume.

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: When should a CVE be suppressed in a scanner workflow?

A: Suppress a CVE only when there is evidence that it is non-exploitable in the specific artifact, environment, or deployment path, and the suppression decision is governed and reviewable. If the finding still changes the attack surface, it should remain active. Suppression without context turns risk management into blind filtering.

Q: What do teams get wrong about vulnerability alert fatigue?

A: They often assume the answer is fewer alerts, when the real issue is better prioritisation. Alert fatigue usually means the programme cannot distinguish exploitable exposure from background noise quickly enough for engineers to trust the output. Fixing that requires tighter signal quality, clearer ownership, and remediation paths matched to the artifact type.

Q: How do cloud-native teams make remediation guidance actually useful?

A: They map remediation advice to the artifact class and delivery stage, so teams know whether to rebuild an image, upgrade a package, or remove an unused dependency. Guidance is only useful if it shortens the path from finding to fix. Otherwise, it becomes another advisory that adds to backlog pressure.

Technical breakdown

How VEX changes vulnerability triage

VEX, or Vulnerability Exploitability eXchange, adds context about whether a published CVE is exploitable in a specific artifact or runtime. That matters because scanners often flag every matching package version, even when the vulnerable code path is not present, not reachable, or already neutralised by the build. By ingesting advisory data with exploitability status, Trivy can separate theoretical exposure from actionable risk. That improves signal quality without changing the underlying vulnerability inventory. The architectural shift is from generic matching to context-aware triage, which is essential when development teams are overwhelmed by volume.

Practical implication: feed exploitability context into vulnerability workflows before escalating every CVE to remediation.

Why non-exploitable CVEs still matter in cloud-native pipelines

A non-exploitable CVE is not the same as a harmless one. It still tells you that vulnerable code exists in the supply chain, but it may not justify immediate production disruption, especially when the affected component is isolated, patched elsewhere, or guarded by compensating controls. The challenge is to preserve evidence without creating alert fatigue. Mature programmes treat exploitability as a routing signal, not as a reason to ignore the finding. This is especially important for language packages and container images, where dependency chains are deep and repeated matches can create false urgency.

Practical implication: separate inventory, prioritisation, and remediation so non-exploitable findings remain visible without consuming response capacity.

Remediation options as a workflow control

Remediation guidance is most useful when it maps to the artifact type and deployment stage. For container images, the right fix may be rebuilding from a patched base image. For language packages, it may be a dependency upgrade, version pinning, or removal of an unused transitive package. The point is to translate scanner output into the next operational step, not just another alert. In cloud-native pipelines, that step needs to fit developer cadence or it will be bypassed. Contextual remediation advice is therefore a workflow control, not a reporting enhancement.

Practical implication: standardise remediation paths by artifact class so teams can act quickly without interpreting every CVE from scratch.

NHI Mgmt Group analysis

Exploitability context is now the deciding variable in CVE governance. The problem in modern scanning is not that tools find too little, but that they often cannot distinguish risk from residue. When exploitability data is attached to findings, teams can suppress noise without suppressing security judgement. Practitioners should treat VEX-style context as a triage layer, not a substitute for vulnerability management.

Alert fatigue is a control failure when it blurs remediation priority. If engineers see too many low-value findings, they stop treating scanner output as operationally credible. That weakens the entire programme, because the backlog becomes a mix of reachable issues, inherited package debt, and already-contained exposures. The governance objective is to preserve trust in the pipeline by making risk signals more decision-ready.

Context-aware vulnerability handling is becoming part of identity governance for software supply chains. Open source artifacts, build pipelines, and container images now behave like managed assets with their own trust boundaries. That means teams need policy on what gets suppressed, what gets escalated, and who owns the decision. The practitioner conclusion is clear: vulnerability triage must be governed like an entitlement workflow, not treated as static scan output.

Named concept: exploitability-aware CVE governance. This is the shift from counting findings to interpreting whether a finding changes actual attack surface. The concept matters because it reduces wasted remediation while keeping genuine exposure visible. Practitioners should use exploitability context to turn scan volume into defensible prioritisation.

For cloud-native teams, the real question is whether security data can keep pace with delivery speed. The closer vulnerability intelligence gets to the build and deployment flow, the less room there is for manual interpretation. That pushes organisations toward policy-driven routing, suppression discipline, and clearer ownership across DevSecOps and security teams. The conclusion for practitioners is to make triage part of the pipeline design, not an after-hours cleanup task.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to Oasis Security & ESG.
• That pattern reinforces why security teams should separate exploitable exposure from background noise before they overload analysts and developers, a theme also explored in The 52 NHI breaches Report.

What this signals

Exploitability-aware CVE governance is becoming a baseline requirement for cloud-native programmes that want security teams to stay credible with developers. If every scan result is treated as equally urgent, the organisation creates its own alert fatigue and starts paying for low-value work instead of risk reduction.

The next step is to align scanner output with delivery workflow, ownership, and artifact class. That means the build system, the security team, and the application owner all need the same understanding of when a finding is actionable, when it is suppressible, and when it needs immediate remediation.

With 72% of organisations already reporting or suspecting an NHI breach, according to our research, security teams cannot afford noisy controls that hide the real exposure story. The programme signal matters as much as the finding itself.

For practitioners

• Suppress only non-exploitable findings with governance approval Define explicit rules for when VEX or advisory context is sufficient to suppress a CVE, and require review for exceptions so the suppression process stays auditable.
• Route container and package findings by artifact class Separate remediation paths for base images, application dependencies, and transitive packages so each finding lands with the team that can actually fix it.
• Measure scanner credibility against remediation outcomes Track how many findings are later confirmed exploitable, how many are suppressed, and how often teams reverse a suppression decision after new intelligence arrives.
• Embed exploitability checks into CI policies Use build-time policy to block only findings that are both present and actionable, while keeping non-exploitable issues visible for later review.

Key takeaways

• Vulnerability scanners create governance value only when they distinguish exploitable exposure from non-actionable noise.
• Alert fatigue is a prioritisation failure, not just a tooling problem, and it weakens trust in remediation workflows.
• Exploitability context should shape suppression, escalation, and ownership across cloud-native delivery pipelines.

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.
• Cve noise: CVE noise is the volume of vulnerability findings that do not translate into immediate risk or practical action. In cloud-native programmes, high noise usually means teams spend too much time sorting alerts instead of fixing the issues that actually expand attack surface.
• 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.
• Alert fatigue: Alert fatigue is the loss of responsiveness that happens when teams receive too many low-value security notifications. In practice, it erodes trust in scanning, slows remediation, and makes it more likely that genuinely dangerous findings are ignored or delayed.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aqua Security: ActiveState joins Trivy Partner Connect to cut CVE noise and reduce alert fatigue for developers. Read the original.