endorlabs.comarticleWhy Your SCA is Always Wrong | Endor Labs
Explains why traditional SCA tools are inaccurate: they parse package-manager manifests and assume those match what the code actually uses. It walks through phantom dependencies, misused dependency scopes, direct use of transitive dependencies and unused dependencies, using Python and JavaScript as examples. It argues for SCA based on program analysis, with source code as ground truth cross-checked against manifests and the file system. Useful for evaluating SCA tools and understanding SBOM accuracy limits.
What it is
An Endor Labs vendor argument that SCA tools are inaccurate because they trust package-manager manifests rather than the code. The page is mostly conceptual: it names no CVEs, versions or commands. Its added value is a mapping from each manifest/code mismatch to the kind of SCA error it produces, which works as a test checklist for evaluating a tool.
How it works
The page describes a typical SCA pipeline: scan the file system for manifests, parse them, assume the declared dependencies are accurate, build a dependency graph, then generate the SBOM and run vulnerability analysis. The compiler/runtime never sees the package manager's definitions, so nothing forces the manifest to match what the code imports. Go is the one language named as an exception, because its package management and compiler are integrated.
Each mismatch maps to a distinct error:
| Mismatch | SCA error |
|---|---|
| Phantom dependency (imported, not declared; e.g. manually downloaded or copied) | False negative: vulnerabilities in it go undetected |
| Misused scope (dev/test dependency used in main code) | Real runtime risk deprioritised or underestimated |
| Direct use of a transitive dependency | Wrong severity or inappropriate remediation advice |
| Unused or optional dependency | False positive: alerts and mitigation work for code that never runs |
flowchart LR
M[Manifest] --> D{Matches code?}
C[Source imports] --> D
F[File system] --> D
D -->|yes| OK[Accurate result]
D -->|declared, unused| FP[False positive]
D -->|used, undeclared| FN[False negative]What to do
The page gives criteria for an SCA tool rather than commands. It should:
- Treat source code as ground truth for which dependencies are used.
- Cross-reference those against manifests and against what is on the file system.
- Flag discrepancies explicitly (phantom or unused packages).
To check a candidate tool, test it on a repo containing each of the four mismatch cases above.
Caveats
- The page is vendor content promoting program-analysis SCA. It gives no accuracy figures or benchmarks to support "always wrong".
- Examples are mainly Python and JavaScript. The page says little about how other ecosystems behave beyond the Go exception.
- It does not cover the cost of source-level analysis, such as dynamic imports or build-time complexity.
Organisations named here
- transitive dependencies
Technologies named here
- Python
- SBOM
- JavaScript
- Maven
- Package managers
- Endor Labs
- npm
- PyPI
- Bazel monorepos
- Go
Techniques named here
- Phantom dependencies
- Misused dependency scopes
- Direct use of transitive dependencies
- Unused dependencies
- SCA through program analysis
Also named here
- dependency scopes
Related in Supply Chain
