Open source now makes up the majority of most application codebases — some estimates put it at 70-90% of the code running in production. That scale is exactly why open source dependency scanning has become a non-negotiable control rather than a nice-to-have. When a single transitive dependency five layers deep can carry a critical CVE, "we don't know what's in our software" stops being an acceptable answer for security teams, auditors, or customers asking for an SBOM. Most teams shorten the practice to OSS scanning, and the term shows up throughout vendor documentation, procurement checklists, and audit questionnaires alike.
Anchore built its name on this problem, growing out of container image scanning into a broader open source composition analysis platform used heavily in federal and regulated environments. It's a mature, capable tool. But dependency scanning today is judged on more than CVE matching — it's judged on how fast results ship, how few false positives waste engineering time, and how well the findings connect to the rest of your supply chain security posture: signing, provenance, SBOM generation, and policy enforcement. This post breaks down what open source dependency scanning actually needs to do in 2026, where tools like Anchore fit, and how Safeguard approaches the same problem differently.
What Is Open Source Dependency Scanning, and Why Does It Matter Now?
Open source dependency scanning is the automated process of identifying every open source component in an application — direct and transitive — and matching those components against known vulnerability databases, license terms, and malicious package indicators. It matters now because the attack surface has moved upstream. The 2024 XZ Utils backdoor (CVE-2024-3094) was inserted into a compression library used by OpenSSH across most major Linux distributions, and it was caught days before widespread deployment only because a Microsoft engineer noticed a 500-millisecond SSH login delay. Sonatype's 2024 State of the Software Supply Chain report recorded over 700,000 malicious packages published to open source registries that year alone, more than the cumulative total from all prior years combined. Manual dependency review cannot keep pace with that volume, which is why scanning has moved from a periodic audit activity into a CI/CD gate that runs on every commit and every build.
How Does Anchore Approach Composition Risk?
Anchore approaches composition risk primarily through image and artifact scanning, using its Syft SBOM generator and Grype vulnerability scanner as the open source core of its commercial Enterprise platform. Syft catalogs packages inside container images, filesystems, and archives, while Grype cross-references that catalog against vulnerability feeds to surface CVEs. This lineage — Anchore Engine was originally built around static container analysis dating back to 2016 — means its strongest coverage is still container-centric, with policy enforcement (Anchore's OPA-based "Gates" system) layered on top for compliance frameworks like FedRAMP and DoD's Container Hardening Process. Anchore Enterprise adds a management UI, RBAC, and reporting on top of the open source tools, which is why it's popular with government contractors that need documented, auditable scanning pipelines. The tradeoff is that teams often need to stitch together separate tooling for source-level dependency scanning, secrets detection, and build provenance, since Anchore's core strength is the SBOM-and-CVE-match workflow rather than an end-to-end supply chain security surface.
Why Do CVE Databases Alone Produce So Many False Positives?
CVE databases alone produce high false-positive rates because a CVE match only confirms a vulnerable version string is present, not that the vulnerable code path is reachable or ever executed. Endor Labs' 2023 research found that over 60% of CVE alerts in typical Java and JavaScript projects point to code that is never actually called by the application at runtime. Chainguard and other researchers have reported similar reachability gaps in npm and PyPI ecosystems. Traditional scanners like Grype excel at matching package metadata against advisory feeds but generally stop there, leaving triage teams to manually work through hundreds of "critical" findings to determine which handful are actually exploitable. At an average remediation cost of engineering hours per ticket, a 60% noise rate isn't a rounding error — it's the single biggest reason security teams report alert fatigue as their top blocker to acting on scan results, according to multiple industry surveys published in 2024 and 2025.
What Happened With Log4Shell, and What Did It Teach Security Teams?
Log4Shell (CVE-2021-44228), disclosed on December 9, 2021, taught security teams that dependency depth is invisible without automated scanning. The vulnerability lived in Apache Log4j 2, a logging library so deeply embedded as a transitive dependency that organizations spent weeks just discovering whether they were affected at all — Cisco, VMware, and dozens of other vendors issued rolling advisory updates through January 2022 as new affected products surfaced. The U.S. Cyber Safety Review Board's 2022 report on Log4Shell concluded that the industry lacked adequate tooling to answer a basic question: "where is this library used?" That gap is precisely what SBOM-driven dependency scanning is designed to close, and it's why CISA and NIST have since pushed SBOM requirements into federal procurement rules (NTIA minimum elements, 2021; Executive Order 14028 follow-on guidance). Four years later, the lesson holds: without continuous, automated scanning across the full dependency tree, a single popular library can become an organization-wide blind spot overnight.
Does License Risk Matter as Much as Vulnerability Risk?
License risk matters just as much as vulnerability risk for many organizations, because a copyleft license buried in a transitive dependency can force unwanted disclosure obligations or block an acquisition due-diligence process entirely. GPL, AGPL, and similarly restrictive licenses show up more often than most engineering teams expect once you scan past direct dependencies — it's common for composition analysis to surface license conflicts three or four levels deep in a dependency graph that no one on the team consciously chose. Anchore and most composition analysis tools do include license detection, but it's frequently treated as a secondary report rather than a policy gate with the same enforcement rigor as CVE severity thresholds. For companies preparing for SOC 2 audits, enterprise procurement reviews, or M&A due diligence, license findings need the same CI/CD-blocking treatment as a critical vulnerability, not a static appendix generated once a quarter.
How Often Should Dependency Scanning Actually Run?
Dependency scanning should run on every pull request and every build, not on a weekly or monthly schedule, because new CVEs and newly published malicious packages appear continuously — NVD published over 40,000 new CVE records in 2024, an all-time high, and that pace has continued into 2025 and 2026. A scan that only runs at release time means code can sit in main for weeks carrying a vulnerability that was disclosed the day after the last scan ran. Continuous scanning also matters because attackers increasingly target the registries directly with typosquatting and dependency-confusion attacks, meaning the risk isn't just "old code with old CVEs" but "new code pulled in yesterday that's already malicious." Treating dependency scanning as a point-in-time compliance checkbox rather than a continuous control is one of the most common gaps auditors flag in SOC 2 and ISO 27001 reviews today.
How Safeguard Helps
Safeguard treats open source dependency scanning as one layer of a connected supply chain security pipeline rather than a standalone SBOM-and-CVE report. Scans run automatically on every commit, pull request, and build, matching dependencies against vulnerability, license, and known-malicious-package data with reachability context so security teams can prioritize the CVEs that are actually exploitable in their codebase instead of triaging every version-string match. License policy violations are enforced as CI/CD gates with the same severity model as vulnerabilities, so a copyleft dependency three levels deep gets caught before merge, not during a due-diligence review.
Because Safeguard is built around the full software supply chain — SBOM generation, artifact signing, provenance attestation, and dependency scanning in one platform — findings don't live in an isolated silo the way they often do when composition analysis is bolted onto a container scanner. A vulnerable transitive dependency, its build provenance, and its signing status are visible together, giving teams the context Anchore-style tools typically require a second system to provide. For teams that inherited Log4Shell-style blind spots or are preparing for SOC 2 and FedRAMP audits, that means fewer false positives to chase, faster answers to "are we affected," and a scanning posture that runs continuously rather than on a schedule.
If your team is evaluating open source dependency scanning (OSS scanning) tools and wants to see how reachability-aware scanning and integrated provenance compare to a traditional CVE-matching approach, Safeguard's team can walk through a scan of your actual dependency graph.