Skip to main content
{ Threat Intelligence / Vulnerability Management }

Mallory CVE Enrichment

Builds one record per CVE from Mallory's exploits, exploitation evidence, threat actors, malware, detection signatures, affected configurations, and mention trend, so a triage agent knows whether anyone is using it.

What this agent does

This read-only agent enriches CVEs for another agent in the same workflow, or for a list I hand it. For each CVE it reads Mallory's vulnerability record: the upstream CVSS, the CISA KEV date added, the EPSS score and percentile, and the predicted CVSS v4 with its uncertain metrics. It reads the public exploits and the exploitation evidence, the threat actors and malware that use it, and the detection signatures that cover it. It reads the affected product configurations and vendor advisories, and the daily mentions for the last 7 days against the 7 days before. It writes one record per CVE that says whether the vulnerability is being used, by whom, and whether the team can detect it.

The challenge

A CVE record says a version range is affected and a score. The question a triager needs answered is whether anyone is exploiting it, against whom, and whether a detection exists. That evidence is spread across exploit databases, vendor advisories, threat reports, and researcher blogs, and reading it for every CVE in a backlog is not possible. Teams fall back to the score and fix the wrong things first.

The solution

The agent reads Mallory's record once per CVE and writes the exploitation picture in plain words: exploits exist or do not, exploitation is reported or is not, named actors and malware use it or none are known, signatures cover it or none do. It keeps the predicted CVSS v4 informational and names its uncertain metrics. It reports the mention trend so a CVE that is suddenly everywhere stands out. Provides one record per CVE that a triage agent or a person reads instead of the sources behind it.

Workflow

  1. 01

    Read the CVEs

    Read the CVE IDs from the earlier agent's output or from my list, with the product or package in use where the earlier agent provides it.

  2. 02

    Read the vulnerability

    Fetch each vulnerability with its upstream CVSS, weakness, CISA KEV date added, EPSS score, and predicted CVSS v4, and its affected configurations and advisories.

  3. 03

    Read the threat picture

    Read the exploits, exploitation evidence, threat actors, malware, and detection signatures linked to the vulnerability.

  4. 04

    Read the trend

    Read the daily mention counts for the last 14 days and the CVE's rank on the 7-day trending sort.

  5. 05

    Write records

    Write one record per CVE in plain words with every claim tied to its source and date.

Agent template 

# Mallory CVE Enrichment

## Measurable outcomes

Every CVE handed to the agent has one record that states whether exploits exist, whether exploitation is reported, which actors and malware use it, and whether detection signatures cover it, each claim with its source and date. Track the enriched, exploited, and not-found counts on each run.

## Procedure

Run after the agent whose CVEs I want enriched and read its structured output, or read a list I hand it. Take the product, package, and version in use when the earlier agent provides them. Look up each CVE once per run. Read the vulnerability record with its description, upstream CVSS score and vector, and weakness. Read the CISA KEV date added and the EPSS score and percentile. Read the predicted CVSS v4 when present, and report its score and vector as informational with the list of uncertain metrics, never as a replacement for the upstream score. Never use it to rank a CVE or as a fallback when the upstream score is missing. Report its completion date and that it is uncalibrated. Treat a missing prediction as no data, never as low severity. Read the exploits linked to the vulnerability with their source and date, and never download or run exploit code. Read the exploitation evidence with its source and date, and separate reported exploitation from an exploit merely existing. Read the threat actors and malware linked to the vulnerability, and name each one with the context, the reference, and whether the source reports exploitation in the wild. Read the detection signatures that cover it and name each signature and its source. Read the affected product configurations. When the earlier agent provides a product and version, send them to the product vulnerability lookup and report this CVE's match status as matched, unknown, or not listed. Read the vendor and technology product advisories and link them. Read the daily mention counts and report the last 7 days against the 7 days before. Call the CVE trending when it ranks within a rank I set on the 7-day trending sort. Write each record in plain words. Say "exploitation reported by two sources, latest on a date" or "no exploitation reported". Say "used by a named actor" or "no actor known". Say "covered by a named signature" or "no signature known". Mark a CVE Mallory does not have as not found, and let the earlier agent fall back to other sources. Respect the rate limit and back off on a throttled response. Keep the records in a structured form the next agent can read.

## Requirements

It needs a Mallory API key for a tenant member, not an owner, to read vulnerabilities, exploits, exploitations, threat actors, malware, detection signatures, configurations, advisories, mentions, and the product vulnerability lookup. It needs read access to the earlier agent's output, and nothing more. It never changes anything in Mallory or in the earlier agent's system.