Dependabot at 800 repositories, 520 of them unprotected
After onboarding 800 repositories to GitHub Advanced Security, the security team finds Dependabot alerts enabled everywhere but security updates disabled on 520 repositories. Developers report that Dependabot pull requests fail with Dependabot can't resolve your JavaScript dependency file because packages come from a private registry at https://npm.internal.example.com, authenticated by a token that currently lives in an Actions secret and in developers' local .npmrc files. Version updates alone would open roughly 60 pull requests per day across the estate, and the CI queue already exceeds four hours. A policy draft requires remediation of critical vulnerabilities within 7 days, high within 30, and medium within 90, but teams say they cannot keep up and are dismissing alerts in bulk with the reason won't fix. Two repositories contain a vulnerable transitive version of a widely used HTTP library that has no direct dependency entry.
1. How do you restore private registry access for Dependabot?
Read the worked answer
Dependabot does not read Actions secrets or a developer's .npmrc. Configure an organization-level Dependabot registry: type npm-registry, URL https://npm.internal.example.com, and a token stored as a Dependabot secret. Dependabot secrets are a separate store from Actions secrets, so an identically named Actions secret will not resolve.
Reference the registry in dependabot.yml with registries: [internal-npm] or *. Commit no secret: configuration may reference ${{secrets.NPM_TOKEN}}, but never the literal token. Confirm the token has read scope for every package appearing in the lockfile; a token missing one scope produces the same resolution error and looks like a configuration problem.
Verify by rerunning a failing update job and reading Dependabot's update logs rather than assuming success. Test in one repository first, then promote the registry organization-wide so all 520 repositories inherit the same definition.
2. How do you make the 7/30/90-day remediation policy credible?
Read the worked answer
Attack volume with configuration before policy: group updates per ecosystem, schedule weekly, set open-pull-requests-limit, and ignore major upgrades for dependencies that need manual migration. Security updates stay enabled everywhere and must not wait for the weekly schedule.
Automate the safe path: auto-merge patch updates for development dependencies using dependabot/fetch-metadata, gated by required status checks and a ruleset, and only where the repository has meaningful tests. Use Dependabot auto-triage rules for dev-only low-severity alerts, dismissing with tolerable_risk and a comment instead of bulk won't fix, which destroys the signal security needs. Add dependency-review-action to pull requests to block newly introduced critical and high vulnerabilities.
A 7/30/90 policy is only credible when the backlog is small. Track open critical and high alerts per repository weekly and escalate to named owners, not just publish counts.
3. What do you do about the transitive vulnerability with no direct dependency entry?
Read the worked answer
Read the alert's dependency path to find the parent that introduces the vulnerable package. Dependabot security updates try to bump that parent. If a patched parent exists, merge the update. If none exists, use npm overrides in the root package.json to force the patched transitive version, regenerate the lockfile, run the full test suite, and let Dependabot continue from the new lockfile. Validate that the override does not break consumers and remove it once the parent ships a fixed release.
If no patched version exists at all, document a compensating control (exposure analysis, WAF rule, feature disabled), dismiss with vulnerable_code_not_in_execute_path only if that is demonstrably true, and set a review date. Do not dismiss as won't fix just because the team is behind; that hides the item from SLA reporting. Use dependency review to prevent reintroduction.