Dependency Risk Modeling in Modern Software Supply Chains
Framework for quantifying and prioritising supply chain risk across npm, PyPI, and Go module ecosystems based on provenance, maintenance activity, and exposure surface.
The problem with dependency counts
Most supply chain risk discussions start with the dependency count and stop there. "Your application has 1,200 transitive dependencies" is a real number, but it doesn't tell you where the risk is concentrated. A dependency count is a theoretical attack surface; a dependency risk model is an attempt to map that surface to realistic threat scenarios.
The framework described here came from two years of supply chain reviews across organisations that ranged from "no lockfile, pinning nothing" to "SLSA level 3, sigstore everything." The consistent gap was not tooling; it was a coherent model for prioritising which dependencies to watch closely.
The three axes of dependency risk
We evaluate every direct dependency on three axes:
**Maintenance health**: Is the package actively maintained? How many unique maintainers have committed in the last 12 months? How quickly have past CVEs been patched? A package with one maintainer, no commits in 18 months, and an unpatched moderate CVE from last year is a higher-risk dependency than a package with three active maintainers and a 48-hour CVE response history.
**Execution depth**: At what point in the software lifecycle does this package execute? A devDependency that runs only during local development has a different risk profile than a production runtime dependency that processes user-supplied data. Build-time tools that run with access to secrets (npm lifecycle hooks, postinstall scripts) sit in a high-risk category regardless of maintenance health.
**Exposure surface**: What capabilities does this dependency have that aren't needed for its stated function? A markdown parser that can execute shell commands is a higher-risk dependency than one that cannot, even if they have identical maintenance scores.
Transitive risk propagation
The hard part of dependency risk is transitives. Your direct dependencies are 40 packages. Their dependencies, and their dependencies' dependencies, are 1,200. You reviewed the direct ones. You probably haven't reviewed the transitives.
The approach that scales: score direct dependencies, then propagate risk scores to their transitives weighted by the execution depth of the direct dependency. A transitive of a build tool inherits a lower base risk than a transitive of a production HTTP handler. This doesn't eliminate the need to look at transitives, but it triages the ones that warrant human review.
Where the incidents actually happen
Reviewing post-mortems for supply chain incidents in 2024-25, 58% involved packages with fewer than three active maintainers. Almost all involved packages where the build pipeline had outbound network access during package installation. Almost none involved packages that had active provenance attestation.
The implication: the risk is concentrated in low-maintenance packages with build-time execution capability, and the cheapest mitigation is to restrict outbound network access from build containers. Provenance attestation is valuable but adoption is too low to rely on it as a primary control. Build isolation is the leverage point.