Set Up Dependency Vulnerability Scanning on GitHub

Start with the free layer built into GitHub, then decide whether you need more.

1. Open repository or organization security settings and enable the dependency graph, so GitHub knows what each project uses.
2. Enable dependency alerts, which warn when a package version matches a published advisory.
3. Enable automated security updates so GitHub opens pull requests that bump vulnerable packages.
4. Commit your lockfiles. Scanning a manifest with loose version ranges can't tell you what actually runs in production.
5. Send alert notifications to a place someone reads, such as a shared channel or a weekly digest, not to individual inboxes.

Apply the settings at the organization level so new repositories inherit them. Check archived and forgotten repositories too, since old services with live credentials are a favorite target.

Alerts tell you about existing problems. A pull request check stops new ones. Options range from GitHub's dependency review action, which compares the dependencies a pull request adds or changes against known advisories, to third-party scanners such as Snyk or GitHub Advanced Security features that add code scanning and secret detection alongside dependency checks.

Whichever you choose, set the policy deliberately. A common starting point is to fail the build on critical and high findings that have a fix available, and to warn without failing on the rest. Blocking on issues nobody can fix trains people to bypass the check. Also decide what your scanner does with license problems if you care about them, since some tools report both.

A first scan of a mature project can return hundreds of alerts. Sort them with a few questions rather than fixing in order:

• Is the vulnerable package in production code or only in build and test tooling?
• Is the vulnerable function actually called, or is the package present but the affected feature unused?
• Is the service reachable from the internet, and does the flaw need authentication or special input?
• Is there a known exploit in the wild? A vulnerability that attackers are using jumps the queue regardless of score.
• Is a fixed version available, and is it a patch bump or a breaking major upgrade?

Severity scores are inputs, not orders. A high score in a dev-only tool can wait, and a medium one in your login path might not. Record each decision, including 'accepted risk for now, revisit on date', so the reasoning survives staff changes.

Deadlines turn a backlog into a process. Federal agencies work to fixed remediation windows set by CISA's binding directives, which many private teams borrow as a starting point; check the current directives for the exact windows. Your own targets can be looser or tighter depending on customers and contracts.

How fast you can meet any deadline depends on how fast you can ship. DORA's 2024 report puts lead time for changes anywhere from under one day to one to six months across its performance clusters¹. If a routine patch takes weeks to reach production, work on the delivery pipeline before you tighten the policy. Track time-to-fix per severity and report it monthly.

Patterns that undermine the setup:

• Merging update pull requests without running tests, then reverting when something breaks and never trying again.
• Ignoring transitive dependencies. The vulnerable package is often two levels down, and fixing it means updating the parent or overriding the version.
• Letting the scanner's ignore list grow with no expiry dates.
• Scanning only the default branch and missing long-lived release branches.
• Treating a clean scan as proof of safety. Scanners only know published advisories.

Pair this with secret detection in the same pipeline. For choosing between paid options, see Snyk vs Veracode vs GitHub Advanced Security, and for the workflow by team type, DevSecOps vulnerability scanning.