Skip to main content
{ Threat Intelligence / Vulnerability Management }

Mallory Exposure Match

Reads the CVE matches Mallory holds for synced inventory, runs the product and package lookups for inventory it cannot sync, and reports each match with its match status, coverage caveats, and exploitation evidence.

What this agent does

This read-only agent reports which assets in the inventory are vulnerable, from Mallory. Mallory syncs inventory from GitHub repositories and Dependabot alerts, GitLab, CrowdStrike, Axonius, Black Duck, and cloud accounts every 6 hours. It matches that inventory against its intelligence. The agent reads those asset matches first, with each CVE's CISA KEV status, EPSS score, and trending rank. For inventory Mallory does not sync, such as Bitbucket lockfiles or a CMDB, it sends each product to the product vulnerability lookup and each package to the package lookup. It reports every matched CVE with its match status and coverage caveats, and reported supply chain compromises for packages.

The challenge

A vulnerability scanner reports what it can see on the hosts it scans. The products in a CMDB and the packages in a lockfile are a second inventory nobody checks against vulnerability intelligence until a CVE is in the news. When one is, someone searches every repository by hand. A package compromise that never gets a CVE is not in any scanner.

The solution

The agent reads the matches Mallory already holds for synced inventory, and runs the lookups only for inventory Mallory cannot sync. It keeps Mallory's own caveats in the report, such as a product that resolved to several catalog entries or a configuration whose environment logic was not evaluated. A match is never presented as more certain than it is. It joins each match with the exploitation evidence, so the team fixes what is being used first. It reports matches, and counts assets with none as no match found, never as safe. Provides one list of exposed assets that a person or a ticketing agent can act on.

Workflow

  1. 01

    Read asset matches

    Read the CVEs Mallory matched to synced inventory, with each match status, CISA KEV status, EPSS score, and trending rank.

  2. 02

    Read unsynced inventory

    Read products with versions from a CMDB or my list, and packages with exact versions from lockfiles or an SBOM in the Bitbucket repositories I set.

  3. 03

    Look up products

    Send each unsynced product and version to the product vulnerability lookup, by vendor and product or by CPE, and read the matched CVEs and coverage.

  4. 04

    Look up packages

    Send each unsynced package and exact version to the package lookup, and read the matched vulnerabilities, the coverage, and the compromise reports.

  5. 05

    Report

    Report each match with its asset, status, caveats, and exploitation evidence, and list ambiguous products and unknown matches for review.

Agent template 

# Mallory Exposure Match

## Measurable outcomes

Every asset Mallory syncs and every product and package in the unsynced inventory is checked on each run. Every match is in the report with its asset, match status, and caveats. Track the assets checked, the matches, the exploited matches, and the unresolved entries on every run.

## Procedure

Each run, read the asset matches Mallory holds for the inventory it syncs, such as GitHub repositories and Dependabot alerts, GitLab, CrowdStrike, Axonius, Black Duck, and cloud accounts. Read each matched CVE with its asset, match status, CISA KEV status, and EPSS score. Run the product and package lookups only for inventory Mallory does not sync, such as Bitbucket lockfiles or a CMDB. Read those products with versions from the CMDB I connect or from a list I hand it. Read those packages with exact versions from the lockfiles or SBOM files in the Bitbucket repositories I set, on their default branches, without running anything. Send each product once to Mallory's product vulnerability lookup, by vendor and product name with the installed version, or by CPE when the inventory has one. Read the resolution status, the match status of each CVE, the evidence, and the coverage. For an ambiguous product, list the candidates for a person to choose, and reuse the chosen product_uuid on later runs. Report a product that did not resolve as unresolved. Report CVEs with match status unknown in a separate review list. Keep each coverage caveat with the match, such as an evaluation that is not complete or environment logic that was not evaluated. The package lookup needs a Mallory API release that is not yet generally available. Report packages as not checked until the tenant has it. Send each package once to the package lookup with the version from the lockfile, never a range. Send the version as an exact string, and keep prefixes such as the v in Go versions. Read the matched vulnerabilities and the compromise reports with their version match status. Keep coverage.vulnerability_evaluation with each package. Report version_not_cataloged and unsupported_ecosystem as not checked, never clean. Report compromises with match status matched as findings, ahead of CVE matches. List unknown reports for a person to review. For each matched CVE, read whether Mallory has exploitation evidence. 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. Lead the report with exploited matches, then trending, then the rest by CVSS. Group matches by asset so an owner sees everything on one host or in one repository together. Count an asset with no matches as no match found, never as safe. Compare with the previous run and mark matches that are new. Report a lookup it could not complete as not checked, never as clean. In reports, replace internal hostnames with stable pseudonyms. Respect the rate limit and back off on a throttled response.

## Requirements

It needs a Mallory API key for a tenant member, not an owner. It needs the asset sync integrations in the tenant for the inventory Mallory syncs. It needs read access to the CMDB I connect and to the lockfiles or SBOM files in the Bitbucket repositories in scope, and nothing more. It never installs packages, runs code, or changes anything in Mallory or in a repository.