Developer Context vs. Reachability in AppSec

Reachability has become a buzzword in the world of application security (AppSec). While security teams see reachability as a prioritization tool, developers often push back against additional tech debt—especially when it involves upgrading open-source packages.

This divergence raises a critical question: Is it more valuable to provide developers with focused, actionable context or to deliver comprehensive reachability insights for every vulnerability?

Decoding the NPM Landscape

Let’s use NPM as an example to unpack this debate. Here's what the data reveals:

• 🌍 2,000 packages on NPM contain 2,530 high or critical severity vulnerabilities.
• 🌐 Of these, 353 packages had over 1 million downloads in the last month, accounting for 588 vulnerabilities.
• 📈 Among these popular packages, 97 have an Exploit Prediction Scoring System (EPSS) score above 0.5% (as a reference, Log4j’s score is ~80%), representing 135 vulnerabilities.
• 🧠 Arnica’s dataset from millions of findings reveals that 81 NPM packages collectively represent 108 high and critical vulnerabilities.

From this data, 5.3% of all high and critical vulnerabilities on NPM can be prioritized as top-tier risks. These are easier for security teams to justify fixing, and they resonate better with developers. The Value of Code Risk Prioritization for Developers Why does this matter? Developers are inundated with security tasks, many of which they view as blockers to their primary objective: shipping quality software. By narrowing focus to a small, high-priority subset of vulnerabilities, security teams can better align with developer goals and drive faster remediation. The key question becomes: How much value does reachability add when the developer focus is on the subset of vulnerabilities that matter most? Would doubling down on developer-first context—such as actionable insights on real-world exploitability and high-priority risks—yield greater value? Case Studies in Context Consider these real-world insights into NPM packages:

• ☢ The most exploited package, mongo-express, sees fewer than 5K downloads monthly—a sharp contrast to its high exploitation rate.
• ☣ The second most downloaded vulnerable package, js-yaml, also ranks fourth by EPSS score. Interestingly, its vulnerabilities trace back to versions released over a decade ago in 2013.

These examples illustrate that download counts alone don’t capture risk. A package’s exploitability, historical relevance, and potential reachability within a codebase are critical metrics for prioritization. A Developer-Centric Approach to Security The goal isn’t just reducing vulnerabilities—it’s making secure coding a seamless part of the development process. To achieve this, AppSec strategies should:

1. ‍Leverage Actionable Insights: Highlight risks with real-world relevance, such as vulnerabilities with active exploits or significant EPSS scores. ‍
2. Automate Wherever Possible: Tools like Arnica streamline risk detection, mitigation, and collaboration by integrating directly into developer workflows, such as pull requests or ChatOps tools. ‍
3. Focus on Developer Adoption: Rather than overwhelming developers with exhaustive lists, provide clear, prioritized risks with actionable mitigation steps.

Final Thoughts: Reachability vs. Developer Focus

As AppSec evolves, the debate between providing full reachability context and developer-focused insights will persist. However, data shows that prioritizing the vulnerabilities most likely to impact production environments not only reduces risk but also fosters better collaboration between security and development teams. The point is... reachability on its own is not enough. Risks need to be detected, prioritized, and triaged in a way that aligns to developer focus and workflows.  In the end, effective AppSec isn't about finding every vulnerability—it’s about fixing the right ones, faster.