
Evaluating and Scoring OSS Packages | Endor Labs | Blog | Endor Labs
Endor Labs blog post detailing their "Endor Score" methodology for evaluating open source package risk, distinguishing operational risk (activity, popularity, licensing, code quality) from security risk (vulnerabilities, secrets, malicious code, security practices). It argues against compressing everything into a single opaque score, favoring transparent, deterministic "facts" (e.g., recent commit counts, normalized SAST findings) that users can combine into custom policies, and discusses pitfalls like event-selection bias, threshold selection, and the unproven predictive power of these signals.
TL;DR Endor Labs explains its fact-based (vs single-score) approach to scoring OSS dependency risk across activity, popularity, quality, and security dimensions.
Organisations named here
- OWASP Top 10 Risks for Open Source Software
Technologies named here
- Endor Labs Open Source
- Endor Score
- DroidGPT
- Google Assured Open Source Software
- OpenSSF Scorecard
- Dependabot
- GitHub security event logs
- Endor Labs
- GitHub
- SBOM
- PCI DSS
Techniques named here
- Supply chain attack via malicious OSS packages
- Risk propagation in dependency/social graphs
- Secrets exposure in source code
Related in Supply Chain


