Software Composition Analysis in Vexta: 7 Ecosystems Covered

Software composition analysis is the practice of identifying every third-party dependency a codebase pulls in and checking each one against known vulnerabilities, since a modern application's attack surface is mostly code the team did not write itself. Vexta runs this across seven package ecosystems, parsing manifest and lockfiles directly and matching what it finds against its local CVE mirror.

The problem: most of an app's code isn't the app's own code

A typical web application might have a few thousand lines of code its own team wrote sitting on top of hundreds of third-party packages, each with its own dependencies. A vulnerability in a transitive dependency three levels deep is just as exploitable as a bug in first-party code, but it is far easier to miss because nobody on the team wrote it and nobody is reading its changelog.

Manually cross-referencing every dependency version in a `package-lock.json` or a `go.sum` against a CVE database does not scale past a handful of packages, and most real projects carry far more than that once transitive dependencies are counted.

Which ecosystems does Vexta's SCA cover?

Vexta's SCA module parses dependency manifests across seven ecosystems: npm, reading `package.json`, `package-lock.json`, and `yarn.lock`; pip, reading `requirements.txt`, `Pipfile.lock`, and `poetry.lock`; gem, reading `Gemfile.lock`; Go, reading `go.mod` and `go.sum`; Composer, reading `composer.lock`; Cargo, reading `Cargo.lock`; and Gradle/Maven, extracting from `build.gradle` and `pom.xml` through regex-based parsing.

That spread covers the dependency formats behind most of the stacks a hunter runs into during a web or API-focused engagement, JavaScript, Python, Ruby, Go, PHP, Rust, and JVM projects, without needing separate tooling per language.

How does Vexta match a dependency to a known vulnerability?

Once a manifest is parsed, each dependency and its resolved version get checked against Vexta's local CVE mirror, the same offline database built from NVD, EPSS, and CISA KEV data that the rest of the scanner uses. That means SCA matching does not depend on a live connection to any public vulnerability database at scan time.

For every known-vulnerable component found, Vexta creates one finding, using its standard `vulns.Finding` structure, the same format used across the rest of the scanner, so an SCA result is not a separate, differently-shaped report bolted on afterward. KEV status and EPSS probability scores get injected directly into that finding's description, so a hunter reading the result immediately sees whether a vulnerable package has confirmed real-world exploitation behind it or just a theoretical CVE entry.

Why does Vexta cap results at 200 per scan?

A large, long-lived codebase can carry dependency trees with hundreds of known-vulnerable components once every transitive package is checked, most of them low severity and unlikely to matter in the time a hunter has. Vexta caps SCA output at the 200 highest-CVSS hits per scan, so the findings list stays focused on the dependencies actually worth reviewing first rather than burying them under low-severity noise from packages nobody is going to patch this week.

That cap is about scan output, not detection coverage: Vexta still checks every parsed dependency against the CVE mirror. It is the reporting step that keeps the list to the highest-severity 200, ranked by CVSS. For a hunter working a time-boxed engagement, that ranking decides which dependency findings are worth writing up first, rather than starting from an alphabetical or file-order list and working down until the clock runs out.

Where SCA fits alongside the rest of a scan

SCA runs as one part of Vexta's broader detection surface, alongside the CVE template engine, SAST and secret detection, and active vulnerability testing. A dependency finding gets the same downstream treatment as anything else Vexta detects: it can factor into the Vexta Confidence Score, and if it sits on a path toward a sensitive asset, it can show up in attack-path chaining like any other finding.

That consistency is deliberate: a hunter reviewing results does not need to context-switch between an SCA-specific report format and everything else the scan turned up. A vulnerable dependency, a misconfigured header, and a confirmed SQL injection all show up in the same findings view, sorted by the same confidence and severity signals. Exact ecosystem coverage and cap behavior may be refined over time; see plans on the pricing page for current details.

Key takeaways

What Vexta's software composition analysis actually does: