Notifications
Clear all
Topic starter
20/08/2026 6:01 pm
TL;DR: 77% of application code now comes from third-party sources, while 88% of SCA alerts are noise in many environments, leaving teams buried in triage and missing the vulnerabilities that are actually exploitable, according to Pixee. The practical shift is from counting findings to governing reachable risk, because prioritisation that ignores execution paths, authentication boundaries, and deployment context does not scale.
NHIMG editorial — based on content published by Pixee: 77% of Your Code Came From Somewhere Else. Now What?
By the numbers:
- 77% of your application code didn't come from your developers.
- The average enterprise application contains 528 open source components.
- The average time between vulnerability disclosure and active exploitation has dropped to 15 days.
Questions worth separating out
Q: How should security teams prioritise SCA findings in modern delivery pipelines?
A: Prioritise SCA findings by exploitability, not by raw count.
Q: Why do traditional SCA tools overwhelm security and development teams?
A: Traditional scanners report every matched vulnerability without understanding whether the issue is actually usable in the application.
Q: What breaks when organisations treat all dependency vulnerabilities as equal?
A: The remediation process breaks first, because teams cannot investigate or fix every finding at the same pace.
Practitioner guidance
- Implement reachability-based triage Classify dependency findings by whether the vulnerable code path is actually invoked, exposed, and reachable in production.
- Tie SCA findings to runtime exposure Prioritise internet-facing services, user-input paths, and authenticated endpoints differently from dormant libraries or internal-only components.
- Automate safe dependency fixes Generate and test remediation pull requests for non-breaking updates so developers are not forced to choose between security debt and broken builds.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- Benchmark data on false positive rates, triage load, and developer productivity impact across SCA programmes
- A practical reachability-analysis workflow for separating callable vulnerabilities from dormant dependency noise
- Step-by-step remediation sequencing for dependency upgrades that would otherwise break builds
- Examples of how teams consolidate findings from multiple scanners into a single remediation layer
👉 Read Pixee's analysis of why reachability-based SCA is replacing alert-heavy triage →
SCA alert overload: what reachability analysis changes for teams?
Explore further
20/08/2026 6:39 pm
Reachability, not raw vulnerability count, is the governing concept modern AppSec needs. The article makes clear that scanner output is not the same as usable risk. Security programmes that still reward volume over exploitability end up funding triage rather than reducing attack surface. Practitioner conclusion: change the unit of management from findings to reachable exposure.
A question worth separating out:
Q: What should teams do when a dependency fix risks breaking production builds?
A: Use test-backed automated remediation and stage changes in regular development workflows rather than forcing ad hoc upgrades. If a fix cannot be validated against the build and test suite, it should be treated as an incomplete control. The aim is to remove risk without creating operational instability.
👉 Read our full editorial: Reachability-based SCA is replacing alert-heavy vulnerability triage
