Definitions: what each term actually means

Dependency scanning is the narrow operation of comparing your application's dependency list (from a lockfile or manifest) against a vulnerability database (NVD, OSV, GitHub Advisory) to find packages with known CVEs.

Software Composition Analysis (SCA) is the broader discipline that includes dependency scanning but also adds: license analysis, reachability analysis, SBOM generation, policy enforcement, and in some cases binary analysis (scanning compiled artefacts where source is unavailable).

The marketing blur: Most vendors call their product "SCA" even if it only does CVE matching against a lockfile. True SCA in the Gartner/NIST sense includes all the additional capabilities described below. Ask vendors specifically what their tool covers before buying.

Dependency scanning in depth

A dependency scanner reads your lockfile, extracts the package name and version for every dependency (direct and transitive), then queries a vulnerability database for matches. The output is a list of packages with known CVEs, their severity, and (usually) a recommended fixed version.

npm audit β€” basic dependency scanshell
# Reads package-lock.json, queries npm advisory database
$ npm audit

# Output:
critical  Prototype Pollution via lodash.merge
  Package: lodash
  Patched in: >=4.17.21
  Dependency of: my-app > express > lodash

# Output is only as good as the lockfile β€” vendored code is invisible

Key limitations of dependency scanning alone:

  • Only sees dependencies declared in the manifest/lockfile β€” vendored code in /vendor/ or /static/ is invisible
  • Does not know if the vulnerable code path is actually called (no reachability)
  • Does not analyse licences
  • Cannot scan compiled binaries or container images

What SCA adds on top of dependency scanning

Full SCA extends the analysis in several directions:

  • Binary analysis: Identifies open source components in compiled binaries where no manifest is available (common for mobile apps, embedded firmware, and vendor software).
  • Container image scanning: Analyses OS packages (apt/rpm) installed in Docker images, not just application dependencies.
  • SBOM generation: Produces a machine-readable inventory of all software components in CycloneDX or SPDX format, which can be shared with customers or used for continuous monitoring.
  • License analysis: Identifies the licences of every component and flags combinations that violate your licence policy (e.g., GPL components in a proprietary product).
  • Policy enforcement: Blocks builds or deployments when components fail licence or vulnerability policy, not just when CVEs are found.

License risk: the concern unique to SCA

Dependency scanners only find security vulnerabilities. They say nothing about whether the licence of a dependency creates legal risk. This matters because:

  • GPL/LGPL copyleft licences may require you to open-source your own code if you link against them in a proprietary product.
  • AGPL extends this to network services β€” if your SaaS uses an AGPL library, you may be required to publish your source.
  • Commons Clause restrictions in some "open source" licences prohibit commercial use.
  • Licence compatibility β€” mixing Apache 2.0 and GPL 2.0 components in the same binary can create conflicts.

The Log4j lesson: The Log4Shell vulnerability (CVE-2021-44228) made everyone aware that a single transitive dependency could be catastrophically vulnerable. SCA tools that generate SBOMs made it possible to answer "are we affected?" in minutes. Teams without SBOMs took days or weeks.

Reachability analysis: reducing noise dramatically

The biggest false positive problem in dependency scanning is flagging CVEs in packages whose vulnerable code is never actually called by your application. A CVE in a JPEG parsing function in an image library you use for CSV reading is not exploitable.

Reachability analysis performs call-graph analysis to determine whether vulnerable code paths in dependencies are reachable from your application code. Tools with reachability support:

  • Snyk β€” reachability analysis for Java, Python, JavaScript
  • AquilaX SCA β€” reachability-aware analysis reducing noise by 60–80% in most codebases
  • Semgrep Supply Chain β€” reachability for multiple languages
  • OWASP Dependency-Check β€” no reachability, pure CVE matching
  • npm audit / pip-audit β€” no reachability, pure CVE matching

Tooling comparison

Capability matrixtext
Tool                  CVE scan  Licence  SBOM  Reachability  Binary
──────────────────────────────────────────────────────────────────
npm audit             βœ“         βœ—        βœ—     βœ—             βœ—
pip-audit             βœ“         βœ—        βœ—     βœ—             βœ—
OWASP Dep-Check       βœ“         partial  βœ—     βœ—             βœ“
Grype (Anchore)       βœ“         βœ—        βœ“     βœ—             βœ“
Trivy                 βœ“         βœ—        βœ“     βœ—             βœ“
Snyk                  βœ“         βœ“        βœ“     βœ“ (partial)   βœ“
AquilaX SCA           βœ“         βœ“        βœ“     βœ“             βœ“

What to use when

  • Quick CVE check in CI: grype or trivy β€” fast, easy to integrate, no account required.
  • Developer-focused feedback: Snyk or AquilaX β€” IDE integration, PR comments, fix PRs.
  • Compliance/SBOM requirements: AquilaX, Syft + Grype, or Dependency-Track β€” full SBOM generation and storage.
  • Licence policy enforcement: AquilaX or FOSSA β€” automated licence approval workflows.
  • Noise reduction: Any tool with reachability analysis β€” starts with Snyk or AquilaX.

The right expectation: Start with dependency scanning (it catches 70% of the value for 5% of the effort), then add SBOM generation for compliance, then add reachability analysis once the volume of false positives starts slowing down remediation.

Full SCA β€” not just dependency matching

AquilaX SCA covers CVE scanning, licence analysis, SBOM generation, and reachability-aware findings β€” so your team focuses on real risks, not noise.

Explore SCA β†’