GitHub's Dependabot opens patch pull requests, not a full audit

The workload

Manually auditing every dependency a modern application pulls in — often hundreds of transitive packages — for known vulnerabilities is not something a solo founder can realistically repeat by hand. GitHub's documentation on Dependabot security updates describes the automated alternative most solo founders rely on instead: a GitHub feature, enabled per repository, that watches a project's manifest and lock files and opens pull requests when a listed dependency has a known vulnerability. The founder's workload becomes reviewing and merging, or rejecting, pull requests Dependabot opens, rather than searching for vulnerabilities in the first place.

What the documents show

GitHub's documentation states, verified, that 'GitHub may send Dependabot alerts to repositories affected by a vulnerability disclosed by a recently published GitHub security advisory,' and a companion page on Dependabot alerts states, verified, that 'only advisories reviewed by GitHub trigger alerts' — the detection surface is bounded by what the GitHub Advisory Database has reviewed, not every vulnerability that exists. When one is found, the security-updates documentation states, verified, that Dependabot 'raises a pull request to update the dependency to the minimum version that includes the patch.' The same document states a real scope limit: updates trigger 'only for dependencies that are specified in a manifest or lock file,' and for most ecosystems Dependabot 'is unable to update an indirect or transitive dependency if it would also require an update to the parent dependency,' so a vulnerable package buried several layers deep may not get an automatic fix.

The operating cost

Dependabot security updates and alerts are a GitHub feature available on public repositories at no separate charge, and on private repositories as part of GitHub's existing plans; the documents do not state a standalone per-repository fee for this specific feature. The recurring cost is review time: each opened pull request needs a human to confirm the version bump does not break the application before merging, unpaid engineering time whose volume depends on how many flagged dependencies a given codebase carries.

The stop condition

GitHub's documentation does not claim Dependabot constitutes a complete security review; its own stated scope is manifest-and-lock-file dependencies with GitHub-reviewed advisories, which is narrower than a full audit. This is an editorial stop condition: Dependabot coverage should be treated as a floor, not a substitute for periodically checking the transitive dependencies Dependabot's own documented limitation says it may not reach, particularly for a product handling payment or regulated personal data, where the cost of a missed vulnerability outweighs the review time a broader audit would take.

• Are Dependabot alerts and security updates actually enabled on every repository this product ships from?
• How many open Dependabot pull requests are sitting unreviewed right now?
• Does this codebase have vulnerable transitive dependencies that GitHub's own documented limitation says Dependabot may not be able to fix automatically?

Dependabot narrows a genuinely unmanageable manual task to a reviewable queue of pull requests, scoped to what GitHub's own advisory database has reviewed and what a manifest file names directly. That scope, stated in GitHub's own documentation, is also its limit.