Understanding BCS Score

BCS (BreachSpider Confidence Score) is the platform's proprietary exploitation priority score. Developed by CITED Relevance LLC, BCS answers the question every OT operator needs answered: "How urgently should I act on this vulnerability?"

BCS is not a severity score. It is a priority score. It combines severity with real-world exploitation intelligence to tell you what to fix first.

The Score

BCS ranges from 0.0 to 10.0. Higher scores mean higher urgency.

Five Input Factors

BCS combines five distinct signals:

1. CVSS Score (Base Severity)

The standard severity score. A higher CVSS elevates BCS, but CVSS alone does not determine priority. A CVSS 9.8 with no exploit is less urgent than a CVSS 7.5 with a confirmed exploit.

2. EPSS Score (Exploitation Probability)

The FIRST.org daily probability of exploitation. High EPSS significantly elevates BCS because it means attackers are actively targeting this CVE class.

3. KEV Status (Confirmed Active Exploitation)

If the CVE appears in the Known Exploited Vulnerabilities catalog, BCS is elevated substantially. KEV status is the strongest single signal -- it means exploitation is not predicted, it is confirmed.

4. PoC/Exploit Availability (Public Attack Code)

Whether proof-of-concept or functional exploit code has been published. Public exploit code lowers the barrier for attackers, making exploitation more likely even if not yet observed at scale.

5. ICS/OT Relevance (Industrial Control System Impact)

A 0.0-1.0 score reflecting how directly this CVE affects ICS/OT systems. CVEs that affect PLCs, SCADA protocols, industrial network equipment, or engineering software receive higher ICS relevance scores. This factor ensures that BreachSpider prioritizes vulnerabilities that matter to your OT environment over generic IT issues.

BCS Tiers

BCS vs CVSS

This is the most important distinction to understand when using BreachSpider:

Example 1: CVE with CVSS 7.5, KEV flagged, public exploit available, affects Siemens S7 PLCs directly. BCS: 9.8. This is a moderate-severity vulnerability with confirmed exploitation against ICS devices. Act immediately.

Example 2: CVE with CVSS 9.8, no KEV, no exploit, affects obscure desktop software with no ICS relevance. BCS: 6.2. This is a severe vulnerability in theory, but there is no evidence of exploitation and it does not affect OT environments.

The Strike List sorts by BCS, not CVSS. This means the CVE you should fix first is at the top, regardless of whether it has the highest CVSS score.

How BCS Updates

BCS is not static. It recalculates when any of its five input factors change:

• EPSS update: Daily recalculation when FIRST.org publishes new EPSS scores.
• KEV addition: Immediate BCS elevation when a CVE is added to the KEV catalog.
• Exploit publication: BCS increases when proof-of-concept or functional exploit code is published.
• Maturity change: BCS adjusts when exploit maturity changes (e.g., POC to FUNCTIONAL).

When BCS changes for a CVE that matches your assets, the Strike List reorders, and alerts fire if configured.

Using BCS for Operational Decisions

Daily triage: Check the Strike List. The top entries are your highest-BCS findings. Start there.

Maintenance window planning: Filter findings by BCS 7.0+ to identify everything that should be addressed in the upcoming window.

Management reporting: The Executive Summary report includes BCS distribution, showing how many findings fall in each tier.

Compensating control decisions: When you cannot patch (legacy PLCs, vendor dependencies), BCS helps you decide which findings deserve compensating controls (high BCS) versus which can be monitored (low BCS).

Vendor conversations: Share high-BCS findings with your automation vendor to justify firmware update requests. A BCS 9.0+ finding with KEV and exploit evidence is a compelling case for emergency maintenance.