Software composition analysis is only as good as the ecosystems it actually understands. A tool that scores every dependency in your package-lock.json but silently skips your go.sum, your Cargo.lock, or the OS packages baked into a container base image isn't giving you a security program — it's giving you a false sense of one. Engineering teams today routinely mix JavaScript, Python, Go, Java, Rust, Ruby, PHP, and .NET in a single product, often spread across dozens of repositories, multiple monorepos, and a growing number of container images that ship their own operating-system packages on top of the application layer. When evaluating SCA vendors, the question "which languages and package managers do you support, and how deep does that support actually go once you get past the marketing list" matters more than almost any other line item on a buyer's checklist, because a missed ecosystem is a permanent blind spot no dashboard will ever surface.
This post compares how Safeguard and Black Duck approach language and package manager coverage — not just the marketing list of supported ecosystems, but the underlying detection methodology, build-integration requirements, and transitive-dependency depth that determine whether coverage translates into accurate results.
Why does "supported languages" undersell the real question?
Every SCA vendor publishes a list of supported languages. What that list hides is how dependencies are discovered in each ecosystem, and that detail is where accuracy diverges. There are three broad detection strategies in the SCA market:
- Manifest and lockfile parsing — reading
package.json/package-lock.json,requirements.txt/poetry.lock,pom.xml,go.mod/go.sum,Gemfile.lock,Cargo.lock,composer.lock,.csproj/packages.lock.json, and similar files directly, without needing to execute a build. - Build-integrated resolution — invoking the native build tool (Maven, Gradle, npm, NuGet restore) to have it resolve the full dependency graph, which is more accurate for languages with complex resolution rules but requires the scanner to run inside (or alongside) a working build environment.
- Binary and snippet matching — fingerprinting compiled artifacts, container layers, or source snippets against a knowledge base to identify components when no manifest is present at all, which matters for legacy code, vendored dependencies, and third-party binaries.
A vendor that only does the first is fast but can miss anything not declared in a lockfile. A vendor that requires the second gets more accurate transitive graphs but adds friction to onboarding and CI. Black Duck is a long-established player in this space and, per its own product documentation, leans heavily on the second and third strategies through its Detect scanner and Knowledge Base — binary composition and snippet matching are historically among its most-marketed differentiators, particularly for shops with large volumes of legacy or vendored code. That approach has real strengths for exactly that use case, and real costs: build-integrated scanning generally means the scanner needs access to a working, buildable environment for each project, which raises setup and maintenance overhead as the number of repos and languages grows.
How does Safeguard approach dependency discovery?
Safeguard is built around manifest and lockfile-first scanning: it parses the dependency files your ecosystem already produces — package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile.lock, pom.xml, build.gradle/gradle.lockfile, go.mod/go.sum, Gemfile.lock, Cargo.lock, composer.lock, and .NET's packages.lock.json — without requiring the project to be built first. This design choice is deliberate: it means a new repository can be onboarded and scanned in minutes rather than requiring a working build pipeline to be wired into the scanner first, which matters most for organizations with hundreds of repos across multiple languages and inconsistent build tooling.
The tradeoff is symmetric to Black Duck's: manifest-first scanning is faster to deploy and easier to run consistently in CI, but it depends on the ecosystem's lockfiles being present and committed. Safeguard's guidance to customers is to enforce lockfile commits as a baseline hygiene practice — the same practice that makes builds reproducible also makes SCA coverage complete.
Container and OS package coverage: where do both tools look?
Application-level dependencies are only part of the supply chain. Container images ship OS packages (via apt, apk, yum/dnf) that carry their own CVE exposure, and a scanner that only inspects application manifests will miss vulnerabilities in the base image entirely.
Safeguard scans container images layer-by-layer, identifying OS packages installed by common Linux package managers alongside the application dependencies baked into the image, so a single scan surfaces both an outdated openssl package from the base image and a vulnerable npm package in the application layer on top of it. Black Duck also supports container scanning through its Detect tooling, consistent with its broader binary-composition approach — teams evaluating either vendor should confirm current OS-package and base-image coverage directly against each vendor's own published documentation, since package manager support in this specific area is one of the more frequently updated parts of any SCA product.
Does transitive dependency depth actually match the advertised language list?
A language appearing on a "supported" list doesn't guarantee full transitive resolution. The two failure modes to watch for are: (1) a scanner that reads only direct dependencies from a manifest and stops there, and (2) a scanner that resolves transitives but silently caps resolution depth for very large graphs (common in npm and Maven trees, which can run tens of thousands of nodes deep).
Safeguard resolves full transitive dependency trees from lockfiles — since modern lockfiles (package-lock.json, poetry.lock, Cargo.lock, go.sum) already encode the fully-resolved graph the package manager computed, Safeguard doesn't need to re-run resolution logic itself; it reads the graph the build tool already solved. This is a direct advantage of lockfile-first scanning over build-invocation scanning for ecosystems where lockfiles are authoritative and complete. For ecosystems where lockfiles are optional or inconsistently committed (older Maven projects without a lockfile plugin, for instance), transitive accuracy depends on the manifest actually declaring version ranges cleanly — a limitation that affects any manifest-based scanner, Safeguard included, and is worth testing directly against your own repos during evaluation rather than taking any vendor's list at face value.
What should you actually test during a bake-off?
Marketing pages list languages; they rarely show you dependency-graph completeness on your actual codebase. A practical evaluation checklist:
- Run both tools against the same repo and diff the total component count — not just the CVE count, since a tool can only flag vulnerabilities in packages it actually detected.
- Include at least one monorepo with mixed package managers (e.g., an npm workspace alongside a Python service) to see whether coverage holds across a realistic polyglot structure.
- Check a container image with both application dependencies and OS packages layered in, and confirm both are surfaced in one report rather than requiring separate tooling.
- Look for lockfile gaps — deliberately remove a lockfile from a test branch and see whether the scanner degrades gracefully (falls back to manifest ranges) or misses the dependency tree entirely.
- Ask each vendor directly, in writing, for their current supported-ecosystem list rather than relying on either company's blog posts (including this one) — package manager support changes frequently and vendor documentation is the only source of truth at the moment you're evaluating.
How Safeguard Helps
Safeguard's SCA engine is built for polyglot organizations that need broad, fast, low-friction coverage without wiring a scanner into every project's build pipeline. It parses lockfiles and manifests across JavaScript/TypeScript (npm, yarn, pnpm), Python (pip, Poetry, Pipenv), Java/Kotlin (Maven, Gradle), Go (go modules), Ruby (Bundler), Rust (Cargo), PHP (Composer), and .NET (NuGet), resolves full transitive dependency graphs directly from the lockfiles your build tools already produce, and extends the same scan to container images to catch OS-package vulnerabilities alongside application dependencies — all without requiring a working build environment for onboarding.
For teams currently running Black Duck or evaluating it alongside other vendors, the right next step isn't to take either vendor's coverage claims at face value — it's to run a side-by-side scan against your own repos, including your messiest monorepo and your oldest legacy service, and compare the actual component and vulnerability counts each tool returns. Safeguard supports exactly that kind of proof-of-concept: point it at your existing repos and container registries, and get a full dependency inventory back without changing your CI pipeline first. If lockfile hygiene turns out to be the gap, Safeguard also surfaces which repos are missing lockfiles so you can close that gap before it becomes a blind spot in any SCA tool you choose.