What Is CVE Monitoring vs. Blocking?

Overview

Contrast CVE Shield tells you whether a known CVE in your libraries is reachable, actively in use, or under attack. This guide explains the difference between monitoring (seeing what's happening) and blocking (stopping an attack before it reaches the vulnerable code).

Prerequisites

1. A CVE Shield account with an agent installed.

2. A Java application you can connect.

3. No special access is needed to view monitoring data. Configuring blocking mode requires an Organization Administrator role (or the manage access control entities permission) plus a plan that includes blocking.

What monitoring shows you

Once CVE Shield is active for a library, it reports one of the following statuses for every CVE it tracks, regardless of whether blocking is available or turned on:

(Insert screenshot: CVE status shown in Issues or Explorer)

You'll see these statuses wherever CVE Shield data is surfaced: Insights, Explorer, Issues, and Observations. Monitoring is always on once a shield is applied. It's the Protecting and Blocked statuses that depend on blocking being both available and configured.

What blocking adds, and what it requires

Blocking stops a request before it reaches the vulnerable code, rather than just reporting that the code was reached. Two separate conditions have to be true for blocking to actually happen:

1. The CVE itself supports blocking. Some CVEs can't be sandboxed, so their shield is Visibility Only. No configuration will make them blockable.

2. Blocking is licensed and turned on for your organization. Blocking requires a paid CVE Shield tier.

The table below shows how the underlying shield state (what's configured) maps to the result you'll actually see on a CVE:

Configuring the mode (Policies > CVE Shield)

Organizations with access to configuration can set a default policy as Off, Monitor, or Block independently for Development, QA, and Production.

An Override option lets you exempt a specific CVE from the organization-level default and apply a different policy just to that CVE, in any environment.

(Insert screenshot: CVE Shield policy configuration, showing per-environment mode and override)

If your organization already uses ADR's CVE shields

Separately from CVE Shield, organizations using Contrast Assess/ADR today may already have CVE shields under Policies. This is existing functionality, not the new product described above. It offers four modes instead of three:

• Off: Disables the CVE shield entirely.

• Monitor: Identifies and reports attacks, but doesn't stop them.

• Monitor at perimeter: Tries to identify and report a possible attack before the application processes it. Not available for every CVE shield.

• Block: Identifies, reports, and blocks the attack; the request never reaches the vulnerable code path.

If both ADR's CVE shields and the new CVE Shield product target the same method, ADR set to Block takes precedence and acts first.

We don't recommend enabling blocking in production without testing first; validate a specific CVE safely using the Override feature in a Staging or QA environment.

Expected Outcome

You can explain the difference between monitoring and blocking, identify which of the six statuses a CVE is currently showing, and know that blocking depends on both CVE-level support and your organization's configuration, not just which plan you're on.

Related Resources

• Try Contrast for free

• Contrast Documentation: CVE shields, Set modes for CVE shields for organizations for existing ADR/Policies functionality

Escalation Path

• Free: Post your question in the Gather Community Forum.