You can tell a genuine Dependabot pull request by four things: the author is the dependabot account, the title and body follow the standard layout, the commits show as verified, and only dependency files changed. If any one of those is off, treat it as an ordinary outside contribution and review it that way.
Why the question matters
Bot pull requests get fast approvals. That speed is the point, and it is also what makes them a good disguise. A person can open a pull request that looks like an update bot, with a tidy title and a believable version bump, and hope a tired maintainer clicks merge.
You do not need special tooling to check. You need to know what the real thing looks like.
The four checks
GitHub's documentation says Dependabot pull requests are easy to identify: the author is dependabot, the bot account Dependabot uses, and by default the pull request carries the dependencies label. The same documentation says Dependabot signs its own commits by default, even when the repository does not require signed commits.
| Signal | A genuine Dependabot pull request | Question it if |
|---|---|---|
| Author | The dependabot bot account | The handle is similar but not identical, or it is a normal user account |
| Label | dependencies by default (unless you changed it in config) | No label, or an unfamiliar one on a pull request that claims to be a bot |
| Commits | Show as verified | Unsigned, or signed by a different identity |
| Body | Includes a "Dependabot commands and options" section | A hand-written paragraph that mimics it |
| Files | Manifest and lockfile for the package named in the title | Source files, workflow files, scripts, or unrelated packages |
The label default can be changed in your configuration, so a missing label alone proves little. The author and the file list tell you more.
Check the files before the words
A version bump should touch a manifest and usually a lockfile. If the diff also edits a workflow file, an install script, or application code, stop. Real update bots do not do that in a dependency pull request.
Open the Files tab first and read the title second. Titles are easy to forge. A diff is harder to hide behind.
What to do when something is off
- Do not merge and do not run the branch locally with secrets in your environment.
- Look at the author profile. A brand new account with one pull request is a signal, not proof.
- Compare the claimed update with the registry page for that package. Confirm the version exists and who published it.
- If it looks hostile, use GitHub's report tools. Maintainers can report a pull request to GitHub Support or to repository admins from the Report content menu, as described in GitHub's abuse reporting documentation.
- Close it with a short, neutral comment. You do not owe a stranger an explanation.
Make impersonation harder
Your own automation can check the same thing. GitHub's Actions guide for Dependabot gates workflows with a condition on github.event.pull_request.user.login == 'dependabot[bot]'. Pair that with required reviews and required status checks on the target branch, so that no pull request, real or not, merges on appearance alone.
If you use a CODEOWNERS file, put workflow and release scripts under a named owner so a change there always asks for a human.
Where Safeguard fits
If you want a second view of what a dependency change pulls in, a free scan at https://gold.safeguard.sh/scan lists the packages and known vulnerabilities in a project. It does not prove who wrote a pull request, so keep the manual checks above.
Quick check
Does a verified commit badge prove the pull request is safe?
No. It shows who signed the commit, not whether the change is harmless. Still review the diff.
Can I rely on the dependencies label?
Not alone. It is a default that you can change, and anyone with write access can add a label to any pull request.
Should I close a suspicious pull request or leave it open?
Close it, report it if it looks hostile, and avoid running its code on a machine that holds credentials.
Sources
- Managing pull requests for dependency updates, GitHub Docs
- About Dependabot security updates, GitHub Docs
- Automating Dependabot with GitHub Actions, GitHub Docs
- Reporting abuse or spam, GitHub Docs
Last reviewed: 19 October 2026.
