Skip to content
Docs Oneleet Docs

Dependency scanning overview

Some background

Section titled “Some background”

Everyone knows to patch vulnerabilities in their dependencies as soon as possible. Right?

Well, of course, but it’s easier said than done. It means keeping track of every new CVE, and reading every GitHub security advisory, for each of your 1,000+ dependencies. Good luck with that. Many teams, especially small teams, don’t bother – given the choice between product work and dropping everything to patch the third JavaScript prototype pollution vulnerability this week, most teams choose product work. After all, CVE-2099-12345 is unlikely to be exploitable in our app, right? Let alone actually exploited?

It’s a textbook case of alert fatigue. To stay both productive and reasonably secure, you need a way to prioritize which vulnerabilities to address, and when. A classic way to prioritize CVEs is by their CVSS base scores. A package vulnerability’s base score is essentially a measure of its severity, under the assumption that an application uses the vulnerable component(s) of the package, in a vulnerable configuration and environment, without any preexisting mitigations.

CVSS base scores are designed this way because they’re incomplete: they’re intended to be combined with other metrics (“temporal” and “environmental” in CVSS v3.1) that reduce the base score to a system-specific score at a certain point in time. Applying these calculations to adjust the base score is, at least traditionally, a manual process. CVSS can work for large organizations with dedicated Security Operations Centers, but if it takes an average developer at a small firm just as long to triage a vulnerability with CVSS as it does to apply the patch and move on, it’s not difficult to see why full CVSS scoring has poor overall industry adoption.

Meanwhile, the most popular tool for smaller players to stay on top of dependency vulnerabilities, GitHub’s Dependabot alerts, doesn’t help with CVSS at all beyond providing base scores. And even then, Dependabot alerts will happily open dependency bump PRs for CVSS “critical”s just as often as for CVSS “low”s, without clearly tagging which is which. If you aren’t completely on top of your Dependabot-PR-merging game, you can easily miss merging a PR that fixes something serious you’re vulnerable to, because it was drowning in a sea of 20 other relatively unimportant PRs.

This is a sad state of affairs. We’re doing something about it.

What’s Oneleet dependency scanning?

Section titled “What’s Oneleet dependency scanning?”

Simply put, we’ve rebuilt Dependabot alerts for the realities of dependency management in 2026.

Like Dependabot alerts, Oneleet dependency scanning alerts you to vulnerabilities in your open-source dependencies. Unlike Dependabot alerts, we’ve designed dependency scanning to make triage seamless and straightforward, so you can keep on top of both your riskiest vulnerabilities and your promises to investors.

We’ve built dependency scanning with the venerable open-source tools Syft and Grype at the core. This lets us provide support for 25+ package ecosystems, including npm, PyPI, Go, Cargo, Composer, RubyGems, Apache Maven, and many more. Using this solid foundation, we offer:

  • unified on-platform issue management
  • alerts for high-risk vulnerability detections
  • automated exploitability assessments, produced by an AI agent that scrutinizes your codebase
  • adaptive risk scoring, based on public metrics like CVSS base scores and private metrics like exploitability assessment results