Let’s be honest: that flood of security alerts in your inbox can feel completely overwhelming. We’ve been there too.

As a developer advocate and a product manager focused on security at GitHub, we’ve seen firsthand how overwhelming it can be to triage vulnerability alerts. Dependabot is fantastic at spotting vulnerabilities, but without a smart way to prioritize them, you might be burning time on minor issues or (worse) missing the critical ones buried in the pile.

So, we’ve combined our perspectives—one from the security trenches and one from the developer workflow side—to share how we use Exploit Prediction Scoring System (EPSS) scores and repository properties to transform the chaos into clarity and make informed prioritization decisions.

Understanding software supply chain security

If you’re building software today, you’re not just writing code—you’re assembling it from countless open source packages. In fact, 96% of modern applications are powered by open source software. With such widespread adoption, open source software has become a prime target for malicious actors looking to exploit vulnerabilities at scale.

Attackers continuously probe these projects for weaknesses, contributing to the thousands of Common Vulnerabilities and Exposures (CVEs) reported each year. But not all vulnerabilities carry the same level of risk. The key question becomes not just how to address vulnerabilities, but how to intelligently prioritize them based on your specific application architecture, deployment context, and business needs.

Understanding EPSS: probability of exploitation with severity if it happens

When it comes to prioritization, many teams still rely solely on severity scores like the Common Vulnerability Scoring System (CVSS). But not all “critical” vulnerabilities are equally likely to be exploited. That’s where EPSS comes in—it tells you the probability that a vulnerability will actually be exploited in the wild within the next 30 days.

Think of it this way: CVSS tells you how bad the damage could be if someone broke into your house, while EPSS tells you how likely it is that someone is actually going to try. Both pieces of information are crucial! This approach allows you to focus resources effectively.

As security pro Daniel Miessler points out in Efficient Security Principle, “The security baseline of an offering or system faces continuous downward pressure from customer excitement about, or reliance on, the offering in question.”

Translation? We’re always balancing security with usability, and we need to be smart about where we focus our limited time and energy. EPSS helps us spot the vulnerabilities with a higher likelihood of exploitation, allowing us to fix the most pressing risks first.

Smart prioritization steps

1. Combine EPSS with CVSS

One approach is to look at both likelihood (EPSS) and potential impact (CVSS) together. It’s like comparing weather forecasts—you care about both the chance of rain and how severe the storm might be.

For example, when prioritizing what to fix first, a vulnerability with:

• EPSS: 85% (highly likelihood of exploitation)
• CVSS: 9.8 (critical severity)

…should almost always take priority over one with:

• EPSS: 0.5% (much less likely to be exploited)
• CVSS: 9.0 (critical severity)

Despite both having red-alert CVSS ratings, the first vulnerability is the one keeping us up at night.

2. Leverage repository properties for context-aware prioritization

Not all code is created equal when it comes to security risk. Ask yourself:

• Is this repo public or private? (Public repositories expose vulnerabilities to potential attackers)
• Does it handle sensitive data like customer info or payments?
• How often do you deploy? (Frequent deployments face tighter remediation times)

One way to provide context-aware prioritization systematically is with custom repository properties, which allow you to add contextual information about your repositories with information such as compliance frameworks, data sensitivity, or project details. By applying these custom properties to your repositories, you create a structured classification system that helps you identify the “repos that matter,” so you can prioritize Dependabot alerts for your production code rather than getting distracted by your totally-not-a-priority test-vulnerabilities-local repo.

3. Establish clear response Service Level Agreements (SLAs) based on risk levels

Once you’ve done your homework on both the vulnerability characteristics and your repository context in your organization, you can establish clear timelines for responses that make sense for your organization resources and risk tolerance.

Let’s see how this works in real life: Here’s an example risk matrix that combines both EPSS (likelihood of exploitation) and CVSS (severity of impact).

Say you get an alert about a vulnerability in your payment processing library that has both a high EPSS score and high CVSS rating. Red alert! Looking at our matrix, that’s a “Fix first” situation. You’ll probably drop what you’re doing, and put in some quick mitigations while the team works on a proper fix.

But what about that low-risk vulnerability in some testing utility that nobody even uses in production? Low EPSS, low CVSS… that can probably wait until “when convenient” within the next few weeks. No need to sound the alarm or pull developers off important feature work.

This kind of prioritization just makes sense. Applying the same urgency to every single vulnerability just leads to alert fatigue and wasted resources, and having clear guidelines helps your team know where to focus first.

Integration with enterprise governance

For enterprise organizations, GitHub’s auto-triage rules help provide consistent management of security alerts at scale across multiple teams and repositories.

Auto-triage rules allow you to create custom criteria for automatically handling alerts based on factors like severity, EPSS, scope, package name, CVE, ecosystem, and manifest location. You can create your own custom rules to control how Dependabot auto-dismisses and reopens alerts, so you can focus on the alerts that matter.

These rules are particularly powerful because they:

• Apply to both existing and future alerts.
• Allow for proactive filtering of false positives.
• Enable “snooze until patch” functionality for vulnerabilities without a fix available.
• Provide visibility into automated decisions through the auto-dismiss alert resolution.

GitHub-curated presets like auto-dismissal of false positives are free for everyone and all repositories, while custom auto-triage rules are available for free on public repositories and as part of GitHub Advanced Security for private repositories.

The real-world impact of smart prioritization

When teams get prioritization right, organizations can experience significant improvements in security management. Research firmly supports this approach: The comprehensive Cyentia EPSS study found teams could achieve 87% coverage of exploited vulnerabilities by focusing on just 10% of them, dramatically reducing necessary remediation efforts by 83% compared to traditional CVSS-based approaches. This isn’t just theoretical, it translates to real-world efficiency gains.

This reduction is not just about numbers. When security teams provide clear reasoning behind prioritization decisions, developers gain a better understanding of security requirements. This transparency builds trust between teams, potentially leading to more efficient resolution processes and improved collaboration between security and development teams.

The most successful security teams pair smart automation with human judgment and transparent communication. This shift from alert overload to smart filtering lets teams focus on what truly matters, turning security from a constant headache into a manageable, strategic advantage.

Getting started

Ready to tame that flood of alerts? Here’s how to begin:

• Enable Dependabot security updates: If you haven’t already, turn on Dependabot alerts and automatic security updates in your repository settings. This is your first line of defense!

• Set up auto-triage rules: Create custom rules based on severity, scope, package name, and other criteria to automatically handle low-priority alerts. Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale.

• Establish clear prioritization criteria: Define what makes a vulnerability critical for your specific projects. Develop a clear matrix for identifying critical issues, considering factors like impact assessment, system criticality, and exploit likelihood.

• Consult your remediation workflow for priority alerts: Verify the vulnerability’s authenticity and develop a quick mitigation strategy based on your organization’s risk response matrix.

By implementing these smart prioritization strategies, you’ll help focus your team’s energy where it matters most: keeping your code secure and your customers protected. No more security alert overload, just focused, effective prioritization.

Want to streamline security alert management for your organization? Start using Dependabot for free or unlock advanced prioritization with GitHub Code Security today.

Written by

Andrea is a Senior Developer Advocate at GitHub with over a decade of experience in developer tools. She combines technical depth with a mission to make advanced technologies more accessible. After transitioning from Army service and construction management to software development, she brings a unique perspective to bridging complex engineering concepts with practical implementation. She lives in Florida with her Welsh partner, two sons, and two dogs, where she continues to drive innovation and support open source through GitHub's global initiatives. Find her online @acolombiadev.

Carlin is a Product Manager at GitHub working in GitHub Advanced Security, with a focus on Dependabot. Her background in software engineering and data science informs her data-driven approach to product management. She lives in Washington with her partner and their dog, Cookie, and spends her free time cycling and playing competitive board games.