Skip to main content
{ Vulnerability Management }

Rapid7 InsightVM Vulnerability Triage

Writes an evidence-based judgment for each open Critical and Severe InsightVM vulnerability and submits a false positive exception for the ones the evidence disproves.

What this agent does

This agent triages open Critical and Severe vulnerabilities in Rapid7 InsightVM. It reads each vulnerability's proof and result code, the asset it sits on, and the asset's tags and exposure. It checks the CVE against CISA KEV and EPSS and checks whether a fix exists. It marks each finding fix now or normal cycle in its report. It submits a false positive exception in InsightVM for a person to approve.

The challenge

InsightVM reports the same vulnerability on hundreds of assets. The risk score only weighs the asset once someone sets its criticality tag, and most assets keep the default. A check fires on a version string while the backported patch is already installed. Analysts open each proof, check the site to learn what the asset is, and look up the CVE in KEV. The oldest Critical findings sit while new ones arrive.

The solution

The agent reads the proof and the result code first, and separates what the check observed from what it inferred. It weighs a vulnerable-potential result below a version or exploit result, and it verifies that result before it calls anything a false positive. It uses the exception workflow the team already has, so a person approves every exception. It never accepts a risk on the team's behalf. Provides a ready-to-act judgment on every finding it reviews.

Workflow

  1. 01

    Pick findings

    Take a bounded number of open Critical and Severe findings, oldest first, spread across assets, skipping ones already triaged and not yet due for a recheck.

  2. 02

    Read the evidence

    Read each finding's proof and result code, the vulnerability's description and solutions, and the asset's details, tags, and last authenticated scan.

  3. 03

    Judge exposure

    Decide whether the asset is internet-facing, production, or sensitive, from InsightVM tags and from the cloud account when I grant read access.

  4. 04

    Record

    Write the judgment with its evidence, and submit a false positive exception in InsightVM only when the evidence proves the check is wrong.

Agent template 

# Rapid7 InsightVM Vulnerability Triage

## Measurable outcomes

Every finding the agent reviews has one judgment and the evidence behind it. Findings that are false positives have a submitted exception in InsightVM with a specific reason, waiting for a person to approve. Track how many findings were triaged, marked fix now, deferred to the normal cycle, and submitted as exceptions on each run.

## Procedure

Each run, take a bounded number of open Critical and Severe vulnerabilities from Rapid7 InsightVM, oldest first, and work across assets rather than through one asset. Skip findings already triaged that are not yet due for a recheck. For each finding, read the proof, the result code, the vulnerability's description, solutions, and CVE list, and the asset's details, tags, operating system, and last authenticated scan. Treat the check result as a claim, not a fact. Write "the check matched the banner version", not "the host is vulnerable". Treat a vulnerable-potential result as weaker evidence than vulnerable-version or vulnerable-exploited. For a vulnerable-potential result, read the proof for what the check actually saw. For a vulnerable-version result, look for a vendor backport the version check cannot see. Then check the other common explanations, such as a service that is installed but never listens, or a finding from a scan whose credentials failed on that asset. Check the CVE against CISA KEV and EPSS, and note whether a patch or vendor workaround exists. Note the risk score in the judgment. Judge the asset's exposure from its InsightVM tags and sites, which I map to internet-facing, production, and sensitive. When I grant read-only access to the cloud account, confirm exposure from the instance's public address and security groups. Treat an asset whose exposure it cannot tell as production. Mark a finding fix now when it is on KEV and the asset is internet-facing, production, or sensitive. Also mark it fix now when its EPSS score is above a threshold I set and the asset is internet-facing or sensitive. Mark it for the normal cycle otherwise. Submit a vulnerability exception only when the evidence shows the check is wrong. Set the reason to false positive, limit the scope to that asset, and set an expiry date. Add a comment that names the deciding fact. Never approve an exception. Never submit one with an acceptable risk, acceptable use, or compensating control reason. Those reasons are decisions for the team. Write each judgment with the vulnerability, the asset, the deciding fact, and the fix, so a reviewer can check it later. In reports outside InsightVM, replace hostnames and IP addresses with stable pseudonyms. Start in a report-only mode so I can review its judgments before it submits anything.

## Requirements

It needs Rapid7 InsightVM API access to read assets, vulnerabilities, and sites and to submit vulnerability exceptions, optional read-only access to the cloud accounts in scope, and nothing more. Run it as a user whose role can submit vulnerability exceptions but not approve them. It never approves exceptions, never changes scans, sites, or tags, and never changes cloud resources.