Safeguard
Supply Chain•

Does the scanner cover your stack? An ecosystem checklist

A checklist for confirming a dependency scanner reads every language, package manager, build file and image type you use, before you sign anything.

Safeguard Security Team
3 min read

Before choosing a scanner, list every language, package manager, build system and artifact type you ship, then ask the vendor to show each one scanned with real output. A support matrix on a web page is a claim. A scan of your own repository is evidence.

Build your stack inventory first

Most gaps come from the corners of a company, not the main product. Walk through these categories and write down what exists:

  • Main application languages and their package managers.
  • Secondary languages: scripts, data pipelines, mobile apps, infrastructure code.
  • Build systems, including multi-module and monorepo layouts.
  • Container images and their base operating systems.
  • Front end bundles and their package managers.
  • Internal packages from private registries.
  • Vendored or copied third party code.
  • Binaries or libraries with no source.

Ask each team to add anything missing. Surprises are normal.

What "supported" can mean

A vendor may list an ecosystem as supported when the tool does one of several very different things:

  1. Reads a manifest only.
  2. Reads a lockfile and builds a full tree.
  3. Runs the build to resolve dependencies.
  4. Adds vulnerability matching and, perhaps, reachability.

Ask which level applies per ecosystem. The gap between level one and level four is wide.

The test

For each item in your inventory, pick a representative repository and ask for a scan. Check these points:

  • Does the component count look plausible compared with the lockfile?
  • Are transitive packages present with their paths?
  • Do names and versions come through exactly, including pre-release tags and local versions?
  • Are private registry packages resolved, or shown as unknown?
  • Does a monorepo show each subproject separately?
  • Do licenses appear alongside vulnerabilities if you need them?

Record results in a simple table, one row per ecosystem and one column per test. Mark each cell pass, partial or fail.

Private registries and authentication

Private packages often fail quietly. If the scanner cannot authenticate to your registry, those components vanish from the report or appear without data. Ask how credentials are stored, what permissions the scanner needs and whether read-only tokens are sufficient. Least privilege applies to the scanner too.

Coverage you will want in a year

Think about the next twelve months. A mobile app, a new language for a data team or a move to containers may be planned. Ask about roadmap, but weigh roadmap items lightly. Only count what works today.

Handling gaps

You will probably find some. Options include a complementary tool for the edge ecosystem, a generated SBOM imported into the main system, or an agreed exclusion with a named owner. A documented gap beats a silent one.

Where Safeguard fits: it handles SBOM and dependency scanning, and the free scan lets you test your public repositories against your checklist.

Try it yourself

Click through it at your own pace, or open it full screen.

Look at how components are grouped and check that your own ecosystems would appear this way.

Quick check

Is a vendor's supported ecosystems list enough?

No. Ask for a scan of your own repository per ecosystem and check the output.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.