Stop Chasing CVSS Scores and Start Prioritizing Real Exploitation

TLDR: Most vulnerability management programs fail because they rely on static CVSS scores rather than actual threat intelligence. By integrating the Exploit Prediction Scoring System (EPSS) into your CI/CD pipelines, you can focus remediation efforts on the small percentage of vulnerabilities that are actively being exploited in the wild. This shift from theoretical risk to empirical evidence significantly reduces the attack surface and prevents burnout for both security and development teams.

Vulnerability management is currently broken. Every day, roughly 110 new CVEs are published, and on Tuesdays and Thursdays, that number often spikes to over 250. If you are still relying on CVSS base scores to dictate your patching priority, you are fighting a losing battle against noise. CVSS was never designed to be a risk-based prioritization tool. It measures severity, not the likelihood of exploitation. When you treat a high-severity vulnerability with no known exploit the same as one currently being used in a T1190 Exploit Public-Facing Application campaign, you are wasting cycles on issues that will never be weaponized.

The Reality of Exploitation

Data shows that the vast majority of vulnerabilities never see a public exploit. When you look at the distribution of EPSS scores, the curve is heavily skewed toward zero. Most vulnerabilities are just noise. The goal of a modern security program should be to filter out that noise and focus on the tiny fraction of bugs that threat actors are actually using.

Consider CVE-2019-1653, a Cisco vulnerability that remains a high-scoring example of what happens when a bug is weaponized. If you are managing a network, you need to know which of your assets are vulnerable to this specific issue, not just every asset that has a high CVSS score. EPSS provides a sliding 30-day window of probability, updated daily. By running this model against your environment, you can identify which vulnerabilities are statistically likely to be exploited in the immediate future.

Integrating EPSS into Your Pipeline

For pentesters and developers, the most effective way to use this data is to bake it directly into your deployment workflows. If you are using GitHub Actions, you can automate the policy enforcement. Instead of failing a build for every vulnerability, you can set a threshold. If a dependency has an EPSS score above 0.6, the build fails. This forces the conversation between security and engineering to happen when it matters most: before the code hits production.

name: 'Dependabot EPSS Action'
on: [push]
jobs:
  epss-compliance:
    runs-on: ubuntu-latest
    steps:
      - name: 'EPSS Policy'
        uses: advanced-security/dependabot-epss-action@v0
        with:
          token: ${{ secrets.EPSS_GITHUB_TOKEN }}
          epss-threshold: "0.6"

This approach turns security from a "no" department into a data-driven partner. When you tell a developer that a library needs to be updated because it has a high probability of being exploited in the next 30 days, you have a much stronger case than simply pointing to a generic severity score.

Where Pentesters Should Look

During a penetration test or a bug bounty engagement, you should be using this data to guide your reconnaissance. If you are scanning a target, don't just dump a list of every CVE found by Nuclei. Cross-reference those findings with the latest EPSS data. If you find a vulnerability with a high EPSS score, that is your primary target. It is the path of least resistance for an attacker and the most likely point of failure for the organization.

Tools like Metasploit are often used to validate these findings, but the real value is in the prioritization. If you can show a client that they have 500 vulnerabilities but only 10 are actively being exploited, you have provided more value than a 100-page scan report. You are helping them focus their limited resources on the threats that actually matter.

The Defensive Reality

Defenders need to understand that EPSS is not a silver bullet. It is a model, and like any model, it is only as good as the data fed into it. If your environment is highly specialized—such as an OT or medical network—the general EPSS model might not capture the specific threats you face. You should always validate the model's output against your own internal telemetry.

Furthermore, EPSS does not replace the need for basic hygiene. You should still aim to patch everything, but you must prioritize based on reality. If you have not yet addressed the known exploitable vulnerabilities in your environment, do that first. Once your house is clean, use EPSS to maintain that state by focusing on the emerging threats that are gaining traction in the wild.

Stop treating every vulnerability as an emergency. Start treating the ones that are actually being used as the only ones that matter. If you are not already pulling the daily EPSS CSV files and mapping them to your asset inventory, you are missing the most important signal in the current threat landscape. Go to the EPSS documentation and start building your own risk-based prioritization today. Your team will thank you for the reduced noise, and your security posture will be significantly stronger for it.