Watchlist vs Environment Matching
BreachSpider provides two distinct mechanisms for tracking CVEs: the watchlist and environment-based asset matching. Understanding when to use each ensures you get the right intelligence through the right channel.
Side-by-Side Comparison
| Feature | Watchlist | Environment Matching |
|---|---|---|
| How CVEs are tracked | You manually add specific CVEs | Automatic -- CVEs matched to your assets |
| What triggers it | Your decision to follow a CVE | The matching engine finding a CVE that affects your device |
| Alerts are sent when | A newly published CVE matches a watched vendor or product | A newly published CVE matches one of your assets |
| Scope | Any CVE in the 366K+ corpus | Only CVEs affecting your declared vendor/product/version |
| Requires assets | No | Yes -- no assets means no matches |
| Appears in findings | No | Yes -- findings are the core triage unit |
| Appears in reports | No | Yes -- reports are based on environment findings |
| Creates compliance evidence | No | Yes -- findings, acknowledgments, and tickets feed the audit log |
| AI analysis available | Yes (on CVE detail pages) | Yes (on CVE detail pages and in reports) |
When to Use the Watchlist
Use the watchlist when you want to track a CVE that is not (yet) tied to your operational assets:
- Researching a new vendor: You are evaluating Schneider Electric products for an upcoming project. Watch CVEs affecting Schneider products to assess the vendor's security profile before you buy.
- Tracking an industry-wide threat: A new authentication bypass CVE is making headlines. You want to follow developments even though your specific products may not be affected.
- Pre-deployment awareness: You know you will deploy Rockwell ControlLogix PLCs next quarter. Watch relevant CVEs now so you have intelligence before the devices arrive.
- Personal research: You are studying a specific CVE class (e.g., Modbus protocol vulnerabilities) and want to collect examples.
When to Use Environment Matching
Use environment matching for your operational triage and compliance workflow:
- Operational sites: Your water treatment plant has 15 PLCs, 4 HMIs, and 2 SCADA servers. Create an environment, add these as assets, and let the matching engine find every CVE that affects them automatically.
- Compliance evidence: NERC CIP and IEC 62443 require documented vulnerability management. Environment findings, acknowledgments, tickets, and audit log entries create the evidence trail.
- Team triage: The Strike List, findings list, and dashboard metrics are all based on environment matches. Your team's daily workflow starts here.
- Reporting: Executive summaries, risk reports, and compliance evidence packages pull from environment findings.
Using Both Together
The most effective approach uses both mechanisms:
-
Environments for operations: Add your real devices as assets in your environments. The matching engine handles the rest. Triage findings, create tickets, generate reports.
-
Watchlist for intelligence: Watch CVEs that matter to your awareness but are not tied to current assets. Follow new vendor products, track emerging threats, monitor CVE classes.
-
Promote when ready: When a watched CVE becomes operationally relevant (you deploy the affected product), the environment matching engine will pick it up automatically once the asset is added. The watchlist gives you early intelligence; the environment gives you operational triage.
Alert Differences
Watchlist alerts are sent when a newly published CVE matches a watched vendor or product.
Environment alerts are sent when a newly published CVE matches one of your assets with high confidence.
In both cases, changes to an existing CVE (a KEV addition, a new exploit, an EPSS change, a patch) do not send an alert. Both are delivered by email and webhooks. See How Alerts Work.