When a vendor says it supports your ecosystem, it can mean it detects manifest files, resolves the full dependency tree, matches advisories accurately, or proposes fixes. These are four different capabilities. Ask which of them is covered for your package manager, and have the vendor prove each on your own repository.
The four levels
An ecosystem is a package world with its own manager and registry, such as the ones used by JavaScript, Python, Java, Go, Rust or .NET projects. Support is not binary. Think of it as a ladder.
| Level | Meaning | Test |
|---|---|---|
| 1. Detection | Finds the manifest or lockfile | Does it notice your file at all? |
| 2. Resolution | Builds the full tree, including transitive packages | Does the count match your package manager's own output? |
| 3. Matching | Maps each package version to the correct advisories | Are known vulnerable versions flagged, safe versions not? |
| 4. Remediation | Suggests or creates an upgrade that works | Does the proposed version resolve and build? |
Many tools reach level 1 across dozens of ecosystems and level 4 across only a few. That is not dishonest, but it changes what your team will experience.
Where gaps hide
Resolution is the common weak spot. A manifest lists what you asked for. A lockfile records what was installed. A scanner that reads only the manifest can miss every transitive package. Ask whether lockfiles are required, optional or ignored, and what happens in a project with none. The post on checking scanner language and ecosystem support has related checks.
Matching has its own traps. Package names differ between registries and advisory databases, and a naming mismatch produces silent misses. Ask how the vendor maps names and versions, and how it handles private or renamed packages.
Build tools add another layer. Projects that generate dependencies at build time, vendor code into the repository, or use custom registries can all look empty to a scan that only reads files.
A short test you can run this week
- Pick one representative repository per ecosystem you use.
- Record the dependency count from your package manager's own tree command.
- Run the scanner and compare counts. Investigate any gap above a few percent.
- Add a package you know has a published advisory and confirm it is flagged.
- Ask for the fix suggestion and try applying it on a branch.
Keep the notes. They make a stronger evaluation record than a feature checklist.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how direct and transitive packages are separated in the inventory, which is exactly the level 2 detail to demand from any tool.
Quick check
Is a longer ecosystem list a better scanner?
Not by itself. Depth in the ecosystems you use matters more than breadth across ones you do not.
Do we need a lockfile for accurate results?
Usually yes. Without one, the installed versions are a guess and results can differ between runs.
Safeguard offers SBOM and dependency scanning, and you can test it on your own project with the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
