DenlyHandle Dependabot and GitHub security alerts in a small app
Updated 2026-11-03
A Dependabot alert means GitHub matched a vulnerable version in your dependency graph. On a small or generated app, work the open alerts that can run in production, merge a security update when the build passes, and dismiss an alert only with a reason you could defend later. Choosing Renovate instead of Dependabot is a different decision.
This is the day-to-day pass over alerts that already exist. The comparison of Dependabot and Renovate, including version-update schedules and groups, is Renovate vs Dependabot. Alerts come from the GitHub Advisory Database once the dependency graph can see a manifest or lockfile. A zip that never reached GitHub has none of this until you push it. A Lovable or Bolt export becomes eligible after the GitHub connection in those guides. The steps below follow GitHub’s page on viewing and updating Dependabot alerts.
Open the alert list and turn the graph on
On the repository, open the Security and quality tab. If you do not see that tab, open the repository menu and choose Security and quality. In the sidebar, under Findings, open the Dependabot menu and click Vulnerabilities. Each alert has its own number. Older alerts that grouped every vulnerability for one package redirect to a filtered list for that package.
The list stays empty when the dependency graph is off, or when the manifest sits in a folder GitHub is not reading. Enable the graph and Dependabot alerts under Settings, Advanced Security, the same switches the Renovate comparison spells out. Dependabot security updates are a further switch: they open a pull request toward the minimum patched version. A missing control is not proof that the repo is clean. It can be your permission on the repository, or an organization policy. Do not describe that as “GitHub found nothing”.
For a public repository you can also list open alerts from the API, which GitHub documents as a public preview. gh sends the auth header. You need a token that can read the alerts. Classic personal access tokens need the security_events scope, or public_repo when the repository is public.
gh api --paginate "/repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100"The web list is enough for a single app. Use the API when you want the same list in a terminal. The --paginate flag follows every page; per_page alone only changes one page’s size. The response fields include state, security_advisory.severity, and dependency.package.name.
Sort what can run in production ahead of build tools
The default sort is Most important. GitHub describes that order as a mix of impact, whether a fix is available, and relevance, using signals such as CVSS, the dependency’s scope, and whether a vulnerable function appears to be called. It is a queue, not a severity you should paste into a status report as if you measured it yourself.
| What you see | How to treat it |
|---|---|
| Runtime scope, or no Development label | First. The package can ship to users. |
A Development label, or the filter scope:development | Later, unless the tool runs on production data. Build-only tools are a smaller blast radius, not a free pass. |
| Reachable or Potentially reachable | Higher in the queue. Reachability analysis is a public preview for JavaScript and TypeScript repositories that use npm, pnpm, or Yarn. A call path is evidence of a call, not proof of an exploit. |
| Unreachable | Lower priority. GitHub says not to dismiss an alert only because of that verdict. The result can change when the code or the advisory changes. |
| Reachability unavailable | Use severity, scope, and whether a patch exists. Unavailable does not mean the function cannot be called. |
Filter from the dropdowns, or type in the search box. Click a label on an alert to filter to it. Secret scanning and code scanning are other menus on the same Security and quality tab. They are not Dependabot alerts, and dismissing one does not clear the other.
Merge a security update only after the checks pass
Open the alert. If security updates are enabled, the page can link a pull request that moves the dependency to the minimum patched version, not necessarily the newest release. If there is no link, the alert page can offer Create Dependabot security update. That creates the pull request. It does not merge it.
Read the changelog quoted on the pull request and the diff of the lockfile. Then run the same checks you trust locally. A generated app often has a test script and a build, and nothing else:
npm ci
npm test
npm run buildUse the install that matches the lockfile. Merge when those commands pass and you understand the version change. A green check on a major of React or Next.js is not enough on its own. Follow the upgrade guide for that major. The pull request body also lists Dependabot commands you can comment. Those commands are for that pull request. They do not dismiss the underlying alert by themselves. Merging the fix is what closes it.
Fix an alert that has no pull request
A missing pull request has several possible causes. Open the alert’s update error, confirm security updates are enabled, and follow GitHub’s Dependabot troubleshooting guide. Missing lockfile information, registry credentials or availability, timeouts, and the ten-open-security-PR limit can block an update. Resolve that cause before changing dependency ranges.
When dependency resolution is the blocker, inspect the package and patched version the alert names. Review a direct package or parent-package upgrade first; a tested root override is another option for a transitive package, using the audit-fix checklist. Push the lockfile after the checks pass. The alert should move to fixed once GitHub reads the new graph. If it stays open, check whether the installed version is still vulnerable or a second copy remains. npm ls the-package shows the copies.
There is nothing to install when the advisory says no patch exists. Track the upstream release. Do not invent a version in an override.
Dismiss with a reason, and reopen it if you were wrong
You can dismiss an open alert only. GitHub’s dismiss reasons, as the DismissReason values name them, are:
- A fix has already been started.
- No bandwidth to fix this.
- Risk is tolerable to this project.
- This alert is inaccurate or incorrect.
- Vulnerable code is not actually used.
On the alert, open Dismiss, choose the reason, and add a comment that says what you checked. The comment lands on the alert timeline. “No bandwidth” and “tolerable risk” are not permanent facts. Revisit them. Unreachable is not one of the reasons. Do not pick “vulnerable code is not actually used” unless you checked the call, not only the verdict badge.
To see dismissed alerts, open the Vulnerabilities list and click Closed. Reopen returns a dismissed alert to the open list. An alert that is already fixed cannot be reopened. If a fix was reverted, expect a new alert when the graph sees the vulnerable version again, rather than a button on the old one.
Auto-triage rules can dismiss or prioritize alerts for you. On a small app, leave those off until you have dismissed a few by hand and know which reason you actually mean. An automatic dismiss on day one hides the queue this page is for.
For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request.
Commands and product behavior on this page were checked against the vendor documentation linked here on 3 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.
Read next
Renovate vs Dependabot, and when neither is enough · npm audit fix is not working: why, and what to do instead