Supply chain drift is what happens when your dependency estate diverges from your intended policy without anyone noticing. A package that was on your approved list gets a new CVE. A transitive dependency that was clean in January picks up a new dependency in March that carries a GPL license your legal team hasn't reviewed. A developer pins a production service to a specific version of a utility library for a hotfix and never unpins it, leaving that service running a version with known vulnerabilities six months later.
At 10 repositories, a manual quarterly audit catches this. At 200 repositories across 15 teams, the audit doesn't happen because no single team has enough context about all 200 codebases to run it effectively. Supply chain drift becomes the steady-state.
Why the problem compounds with scale
Three properties of dependency graphs make drift detection harder at scale rather than just proportionally harder:
First, transitive dependency graphs are not static between your own releases. A new version of a package you depend on can introduce new transitive dependencies without any action on your part. If you're pinning your direct dependencies but not your lockfile, or if you're regularly updating transitive dependencies as part of standard patch maintenance, your effective dependency surface is changing continuously even when you don't change your package.json.
Second, policy violations don't propagate uniformly across teams. One team might be fastidious about dependency hygiene. Two others might not have thought about it since their last incident. At 200 repositories, both situations exist simultaneously, and the highest-risk repos are rarely the ones getting the most attention.
Third, new CVEs are published continuously against existing versions. A snapshot audit run on a Tuesday may be clean. By Friday, three new entries in the GitHub Advisory Database cover packages in your production stack. Without continuous monitoring, the clean audit report is a point-in-time artifact that becomes stale immediately.
What "supply chain drift" looks like in practice
Consider a growing logistics software platform managing roughly 180 microservices across a mix of Node.js, Go, and Python repos. The platform team runs quarterly dependency audits using a script that checks each repo's lockfile against a known-bad package list. Between audits, new CVEs get published, transitive dependencies update, and two or three new services get created from a template that includes a copy of the old dependency config. By the next quarterly audit, 40% of repos have at least one finding that wasn't there three months ago. The audit produces a spreadsheet. Teams are notified. Most fix the critical findings within a month. Medium findings sit in the backlog indefinitely.
This is not a failure of the team or the process. It's the expected output of a point-in-time audit model applied to a continuous drift problem. The audit schedule creates natural accumulation windows where new violations build up between audits, then get processed in a burst that consumes engineering time that would otherwise go to feature work.
The same 40% drift rate in a continuous monitoring model produces a different workload distribution: smaller PRs arriving steadily, most auto-merging, a small set requiring human review. Total remediation effort is comparable or lower, but it's distributed across the cadence of the work rather than spiking quarterly.
The detection architecture for continuous monitoring
Effective continuous supply chain drift detection requires three components working together.
Trigger coverage. Scans need to run on multiple triggers, not just schedule. Push-triggered scans catch violations introduced by code changes. Advisory-publication-triggered scans catch new CVEs against existing versions without any code change. Both triggers are necessary because they cover different classes of drift. Dependabot runs on schedule and on push but doesn't currently trigger on new advisory publication for existing pinned versions. Repohelm monitors advisory feeds and triggers re-evaluation of affected repos when a new CVE covers a version currently in use.
Consistent policy evaluation. All repos must be evaluated against the same policy version, with overrides tracked explicitly. If one team has loosened the severity threshold for their repo, that override should be visible and auditable at the org level. Otherwise, policy compliance reporting conflates "clean because compliant" with "clean because exempted."
Cross-repo deduplication. A CVE that appears in 60 repos doesn't generate 60 independent fix PRs in Repohelm. It generates one finding report per repo, each with an appropriate PR, but the org-level view shows the finding once with a count of affected repos. This matters for prioritization: a critical CVE affecting 60 repos is a different priority level than one affecting 3, even if the CVSS scores are identical.
The signal-to-noise problem at scale
One reason teams avoid continuous scanning at large repo counts is that naive continuous scanning generates overwhelming alert volume. If every transitive dependency version update produces a scan finding and every finding produces a notification, a 200-repo estate generates hundreds of noise events per week that desensitize engineers to the actual signals.
This is where the policy evaluation layer earns its cost. A policy that only surfaces findings above a calibrated severity threshold, only flags transitive dependencies at depths where reachability analysis confirms a live call path, and only opens PRs for packages where a fix version exists, produces an alert volume that stays proportional to actual risk rather than proportional to the size of the dependency graph.
We're not claiming zero false positives. Reachability analysis has limits: it works well for static call graphs but can undercount dynamic dispatch patterns in languages that use them heavily. EPSS scores are probabilistic, not deterministic. The right framing is that a well-calibrated policy reduces the false positive rate enough that the remaining alerts are worth reviewing, even at 200-repo scale.
Drift reporting as a governance artifact
One use of the cross-repo drift view that teams discover after deployment: it becomes a useful governance artifact for security and compliance conversations. A report showing "18 repos with critical CVE findings, 12 of which have PRs open and in review, 6 of which have no action taken and are now past the 7-day SLA" is an actionable document that a platform team lead can use in a weekly sync. It doesn't require anyone to run a manual audit. It doesn't require interpreting a spreadsheet.
The audit that matters is continuous, not quarterly. The artifact it produces is a live state of compliance, not a point-in-time snapshot. At 200 repositories, that's the only model that keeps drift from becoming the default condition of your codebase.