When a critical CVE drops on a Friday afternoon, most security teams don't find out from a vendor advisory — they find out from a Slack message asking "are we affected?" Open source dependency vulnerability scanning is the practice of automatically identifying known vulnerabilities in the third-party and open source libraries a codebase pulls in, typically by matching package names and versions against databases like the National Vulnerability Database (NVD), GitHub Security Advisories, and OSV.dev. Modern applications are assembled, not written from scratch: a typical enterprise JavaScript project pulls in 700+ transitive dependencies for a handful of direct ones. Tools like Aikido Security, Snyk, and Safeguard all compete in this space, but they differ sharply in scan depth, noise levels, and how well they connect a vulnerable package to code that's actually reachable at runtime. Here's how the category actually works.
What Is Open Source Vulnerability Scanning?
Open source vulnerability scanning is the automated process of comparing every package in a project's manifest — package.json, requirements.txt, pom.xml, go.mod — against public vulnerability databases to flag known CVEs. The 2024 Sonatype State of the Software Supply Chain report found that the average application depends on 148 open source components, and each one is a potential entry point for a disclosed flaw. Scanners generally work in one of two modes: software composition analysis (SCA), which reads manifest and lockfiles to build a dependency tree, and binary/artifact scanning, which inspects compiled containers or packages after the fact. Aikido Security markets itself as an all-in-one platform bundling SCA with SAST, DAST, and cloud posture scanning under one dashboard, which is appealing for small teams that want a single tool rather than five. The tradeoff is that breadth-first platforms often go shallow on any one capability, and SCA depth is where false positives get made or avoided.
Why Do Vulnerability Scanners Generate So Many False Positives?
Vulnerability scanners generate high false-positive rates because most only check whether a vulnerable package is present, not whether the vulnerable function is actually called by the application. A 2020 academic study of JavaScript dependencies (Pashchenko et al., "Vuln4Real") found that when reachability analysis was applied, roughly 73% of reported vulnerable dependencies turned out to have no reachable path from the application's own code — meaning the vulnerable code was never executed. Log4Shell (CVE-2021-44228) is the canonical example: the JndiLookup class was flagged in every application that bundled Log4j 2.x, but only applications that actually invoked message lookups with attacker-controlled input were exploitable. Teams using presence-only scanners spent weeks triaging thousands of alerts, most of which posed no real risk. This is the single biggest driver of alert fatigue in AppSec teams, and it's why "how many CVEs did we find" is a worse metric than "how many CVEs can actually be triggered."
How Does Aikido Security Handle Dependency Scanning?
Aikido Security handles dependency scanning through its "reachability analysis" feature, launched in 2023, which layers call-graph analysis on top of standard SCA to reduce noise for a subset of supported languages (primarily JavaScript, Python, and Java at general availability). This puts Aikido ahead of pure presence-based scanners, but reachability coverage across its full language matrix has been inconsistent according to user reports on G2 and Aikido's own documentation, which lists reachability as available for a narrower set of ecosystems than SCA scanning overall. Aikido's pricing model is also structured around a broad bundle — SCA, secrets detection, SAST, cloud security, and container scanning combined — which suits teams standardizing on one lightweight tool but can mean less engineering depth invested in any single scanner compared to vendors that specialize purely in software supply chain security.
What's the Difference Between CVSS Score and Actual Exploitability?
CVSS score measures theoretical severity based on attack vector, complexity, and impact, while actual exploitability depends on whether the vulnerable code path is reachable, whether a public exploit exists, and whether compensating controls are in place. CVSS 4.0, published by FIRST in November 2023, still doesn't factor in reachability or real-world exploitation data by default — that's why CISA maintains a separate Known Exploited Vulnerabilities (KEV) catalog, which as of mid-2025 lists more than 1,300 CVEs actively exploited in the wild out of the roughly 240,000+ CVEs published to date. A CVE with a CVSS score of 9.8 sitting in an unreachable code path is lower priority than a CVSS 6.5 vulnerability sitting in a public-facing API handler with a known proof-of-concept. Any team that triages purely by CVSS number, without exploitability context like EPSS (Exploit Prediction Scoring System) probability or reachability, is optimizing for the wrong signal.
How Often Should Open Source Dependencies Be Scanned?
Open source dependencies should be scanned on every pull request and continuously against newly disclosed CVEs, not just on a weekly or monthly cadence. The reason is timing: the median time from a CVE's public disclosure to the appearance of a working exploit has shrunk to under 5 days for high-severity vulnerabilities, according to multiple 2023-2024 threat intelligence reports, and attackers routinely scan the internet for newly disclosed CVEs within hours of an NVD entry going live. A monthly scan cadence means a team could carry a known-exploited dependency in production for up to 29 days before finding out. CI/CD-integrated scanning that blocks merges on new critical CVEs, paired with a background job that re-checks the existing dependency graph daily against updated advisory feeds, closes that window to nearly zero for new code and to a single day for legacy code.
Does SBOM Generation Help with Vulnerability Management?
SBOM (Software Bill of Materials) generation helps vulnerability management by giving teams a queryable inventory of every component in production, which matters enormously when a new CVE drops for a library nobody remembers including. After Log4Shell in December 2021, organizations without SBOMs spent days manually grep-ing codebases and container images to determine exposure; organizations with SBOMs in CycloneDX or SPDX format could query "which services use log4j-core between 2.0 and 2.14.1" in minutes. Executive Order 14028 (May 2021) and subsequent NTIA and CISA guidance have pushed SBOM generation from a nice-to-have to a procurement requirement for U.S. federal software vendors. An SBOM alone doesn't stop an attack, but it collapses response time from days to minutes during the next Log4Shell-scale event — and it's a prerequisite, not a substitute, for reachability-aware scanning.
How Safeguard Helps
Safeguard approaches open source vulnerability scanning as a supply chain security problem first, not a bolt-on feature of a broader compliance suite. Where breadth-first competitors like Aikido spread reachability analysis across many product lines, Safeguard focuses that engineering depth specifically on dependency risk: continuous SCA scanning tied to real-time advisory feeds, reachability analysis to separate exploitable CVEs from cosmetic ones, and automatic SBOM generation in industry-standard CycloneDX format for every build. Safeguard integrates directly into CI/CD pipelines so vulnerable dependencies are caught before merge, not discovered weeks later during an audit, and prioritizes findings using exploitability context — EPSS scores, known-exploited status, and call-graph reachability — rather than raw CVSS numbers alone. For teams that have outgrown noisy, presence-only scanners or found reachability coverage inconsistent across an all-in-one platform, Safeguard offers a scanner built specifically to answer the question that matters: is this dependency actually a risk to us, right now.