How to get an alert when a dependency has a new security advisory
Turn on Dependabot alerts for repositories you can commit to — that is the first-party answer, it is free, and for your own code it is the right one. It has a hard limit that catches most people: GitHub emails a new alert only to someone who already has write, maintain or admin permission on that repository, so for a dependency owned by somebody else, Dependabot is structurally silent. The four other options below exist to cover that gap, and two of them answer an unauthenticated request with no account at all. Every fact on this page was checked against a primary source on 4 August 2026, and each source is linked at the bottom.
1. Dependabot alerts — the default, and the write-access gate
Dependabot alerts fire on two events, and GitHub Docs names both: Dependabot scans a repository’s default branch and sends an alert when “a new vulnerability is added to the GitHub Advisory Database” or when “your dependency graph changes — for example, when you push commits that update packages or versions”. One qualifier narrows what counts: “Only advisories reviewed by GitHub trigger alerts.” An unreviewed CVE sitting in the database produces nothing, which keeps the noise down and means Dependabot is not a complete view of everything published against a package.
The delivery rule is the part that decides whether Dependabot can answer the question at all, and GitHub Docs states it as two conditions that must both hold: GitHub sends email about new alerts to people who both “have write, maintain, or admin permissions to a repository” and “are watching the repository and have enabled notifications for security alerts or for all activity on the repository”. Write access is the gate. Dependabot reports vulnerabilities in dependencies of repositories someone can commit to — it has nothing to say about a package that someone merely installs, or about a repository they read and do not own. For first-party code, enable it and stop reading. For anything else, it is the wrong tool by design rather than by omission.
2. The GitHub Advisory Database API — every reviewed advisory, no repository needed
GitHub publishes its advisory database over a REST endpoint that requires no repository relationship and, in practice, no credentials. The documented endpoint is GET /advisories, and GitHub describes its default behaviour precisely: it “lists all global security advisories that match the specified parameters”, and “if no other parameters are defined, the request will return only GitHub-reviewed advisories that are not malware”. The filters are the useful part — type (reviewed, unreviewed or malware), ecosystem (npm, pip, maven, nuget, composer, go, rust, rubygems, actions, pub, swift, erlang or other), severity from unknown to critical, and a published date or date range.
The endpoint was called without any token on 4 August 2026 to check that the “no account” claim survives contact with the running service, and it does. A request for the three most recent reviewed critical advisories returned HTTP 200 with content type application/json and three entries: GHSA-v8fg-2rw7-q452 (Sequelize, SQL injection against Oracle DB, published 3 August 2026), GHSA-6h5j-32cf-4253 (Apostrophe, server-side prototype pollution) and GHSA-p849-8hwh-84j9 (NocoBase, SQL injection leading to PostgreSQL-superuser RCE). The response carried an x-ratelimit-limit header of 60, which is the unauthenticated ceiling — 60 requests an hour is ample for a cron job polling by ecosystem and far too little for anything scanning per package on demand. Adding a token raises it.
3. OSV.dev — match an exact package and version
OSV.dev answers a different shape of question: not “what was published today” but “is this exact version vulnerable”. Its API documents POST /v1/query for a single package and POST /v1/querybatch for many at once, which is the endpoint a script walking a lockfile wants. On limits, the documentation is one sentence — “Currently there are no limits on the API” — which is the least restrictive position any of the five options here takes, and also the one most likely to change without an announcement.
Called unauthenticated on 4 August 2026 with the package undici at version 6.0.0 in the npm ecosystem, POST https://api.osv.dev/v1/query returned HTTP 200, content type application/json, and 19 vulnerabilities — among them GHSA-2mjp-6q6p-2qxm (HTTP request/response smuggling), GHSA-35p6-xmwp-9g52 (response queue poisoning via keep-alive sockets) and GHSA-3787-6prv-h9w3 (proxy-authorization header not cleared on cross-origin redirect). The GHSA prefixes are worth noticing: OSV was answering with GitHub advisory identifiers for an npm package, which is what makes it a practical way to reach GitHub-reviewed data keyed by version rather than by publication date. Nineteen results against one pinned version is also a fair illustration of why a per-repository alert stream and a per-version query are not substitutes for each other.
4. npm audit and its equivalents — a scan, not an alert
npm audit is a command, and understanding what it actually does explains why it cannot notify anyone of anything. The npm documentation describes the exchange in one sentence: “The audit command submits a description of the dependencies configured in your project to your default registry and asks for a report of known vulnerabilities.” Mechanically, npm “will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path /-/npm/v1/security/advisories/bulk”. A request goes out, a report comes back, and nothing is subscribed to anything.
That makes npm audit — and the equivalent commands in other package managers — a CI gate rather than an alerting channel. It answers the question at the moment a pipeline runs, which is exactly right for blocking a merge and useless for learning that a package pinned six weeks ago was disclosed yesterday, unless something schedules the run. The common working setup is an audit step on every build plus a nightly scheduled run against the default branch, so that a newly-published advisory against unchanged code surfaces within a day instead of waiting for someone to open a pull request.
5. The Standup — reviewed high and critical CVEs, pushed daily
The Standup does not watch a dependency list on anyone’s behalf, and saying so first is the point of putting it last. There is one wire, the same for every reader, and no way to register a package for a personal alert. What is on it is deliberately narrow: the ADVISORY kind carries GitHub-reviewed CVEs at high and critical severity only, graded tier 1 — the grade this site reserves for something that is broken right now — and each entry links straight back to the advisory rather than summarising it. Anyone who needs per-package coverage of every severity should query OSV.dev against their lockfile, which does that properly and costs nothing.
The overlap is checkable rather than asserted, which is the reason to mention it. GHSA-p849-8hwh-84j9 — the NocoBase SQL-injection advisory the GitHub API returned as one of the three most recent criticals when it was called on 4 August 2026 — is in this archive as a tier-1 advisory entry linking to that same GHSA page. What a daily wire adds is the reading no configuration produces: the advisory arrives next to the platform outage and the vendor changelog entry from the same morning, for someone who has not yet decided which packages to care about. It is free to read in full, the archive is open, and the daily email is double opt-in with one-click unsubscribe.
The NocoBase advisory as it appears on the wire is that entry, and the archive filtered to advisories is every one published so far.
The five options compared
Each row states what the tool tells you, what access it demands, whether it pushes or waits to be asked, and what it costs, as verified on 4 August 2026. The access column is the one that decides most cases.
Tool | What it tells you | Access required | Push or pull | Cost |
|---|---|---|---|---|
Dependabot alerts | Reviewed advisories affecting your repo’s dependency graph | Write, maintain or admin on the repo — to get the email | Pushed — email and the repo’s Security tab | Free |
GitHub Advisory Database API | Every GitHub-reviewed advisory, filterable by ecosystem and severity | None — the endpoint answers unauthenticated | Pulled — you poll it | Free; 60 requests an hour unauthenticated |
OSV.dev API | Advisories matching an exact package name and version | None — no key, no account | Pulled — you query it | Free; no limits stated |
npm audit | Known vulnerabilities in the tree at the moment you run it | None beyond the project checkout | Pulled — you run the command | Free |
The Standup | Reviewed high and critical CVEs, the same list for every reader | None — an email address | Pushed — the wire and one daily email | Free |
Which one to pick
For repositories a team owns and can commit to, Dependabot alerts are the answer and nothing else is needed: first-party, free, and wired to the same GitHub-reviewed advisory data the other options read. For a dependency nobody on the team can write to — a package pulled from a registry, a fork read but not owned, a service run from someone else’s image — Dependabot cannot help by construction, because its email requires write, maintain or admin permission on the repository. That is the case the other four exist for.
For a lockfile, OSV.dev’s querybatch endpoint is the shortest path: no key, no account, and answers keyed to an exact version rather than to a publication date. For watching a whole ecosystem — every reviewed critical npm advisory, say — the GitHub Advisory Database API filtered by ecosystem and severity is the better shape, within the 60-requests-an-hour unauthenticated ceiling. npm audit belongs in CI as a gate, plus a scheduled nightly run so that advisories published against unchanged code still surface. Most working setups are two of these rather than one: something that gates the build, and something that pushes when nobody is building.
Common questions
Why does Dependabot never alert me about vulnerabilities in packages I use?
Because Dependabot alerts are scoped to repositories, not to packages, and the email requires permission on the repository. GitHub Docs states that alert emails go to people who both “have write, maintain, or admin permissions to a repository” and “are watching the repository and have enabled notifications for security alerts or for all activity on the repository”. A package installed from npm is a dependency of a repository, so it will appear in alerts for a repository that depends on it and that the reader can write to — and nowhere else. To track a package independently of any repository, query OSV.dev or the GitHub Advisory Database API.
Can I query GitHub’s advisory database without an account or a token?
Yes. GET https://api.github.com/advisories answered an unauthenticated request on 4 August 2026 with HTTP 200, content type application/json, and reviewed advisory records including GHSA-v8fg-2rw7-q452 and GHSA-p849-8hwh-84j9. The response carried an x-ratelimit-limit header of 60, so an unauthenticated caller gets 60 requests an hour against the core resource. Filtering by ecosystem, severity and published date happens in query parameters, which keeps a polling job to one request per pass rather than one per package.
Does npm audit tell me when a new advisory is published?
No. npm audit reports what is known at the moment it runs and subscribes to nothing. The npm documentation describes it as submitting “a description of the dependencies configured in your project to your default registry”, which then returns “a report of known vulnerabilities”. An advisory published the day after a build produces no signal until something runs the command again. Scheduling a nightly audit against the default branch is the usual fix, and it is what turns a scan into something approximating an alert.
What is the difference between a GitHub-reviewed and an unreviewed advisory?
GitHub-reviewed advisories are the ones GitHub has curated and mapped to affected package versions, and they are the only ones that do anything automatically: GitHub Docs states that “only advisories reviewed by GitHub trigger alerts”. Unreviewed advisories are present in the database but do not fire Dependabot. The REST API exposes the distinction directly through its type parameter, which accepts reviewed, unreviewed or malware, and defaults to returning “only GitHub-reviewed advisories that are not malware”. The Standup carries reviewed advisories only, at high and critical severity.
Can The Standup alert me about a specific package?
No. The Standup is one wire and one daily email, identical for every reader, with no per-reader watch list and no way to register a package. What it carries under the ADVISORY kind is GitHub-reviewed CVEs at high and critical severity, each linking to the advisory itself. Anyone who needs per-package coverage should query OSV.dev against their lockfile — it is free, needs no account, and answers by exact version. The wire is for the surface area around that: the advisory in a transitive dependency nobody pinned, the outage at the platform a service deploys to, the changelog entry from a vendor nobody set a watch for.
Sources
Every claim above traces to one of these, each checked on 4 August 2026. Two of them are HTTP responses rather than pages, recorded with what was called and what came back. Product behaviour and rate limits change without notice — check the source rather than this page if a decision rests on it.
GitHub Docs — About Dependabot alerts — What triggers an alert, which advisories qualify, and who is emailed. Fetched 4 August 2026.
GitHub REST API — List global security advisories — The GET /advisories endpoint and its type, ecosystem, severity and published filters. Fetched 4 August 2026.
api.github.com/advisories — Called unauthenticated 4 August 2026: HTTP 200, application/json, three critical advisories, and an x-ratelimit-limit header of 60.
OSV.dev — API documentation — The POST /v1/query and /v1/querybatch endpoints, and the statement on limits. Fetched 4 August 2026.
api.osv.dev/v1/query — Called unauthenticated 4 August 2026 for undici 6.0.0 on npm: HTTP 200, application/json, 19 vulnerabilities returned.
npm Docs — npm-audit — What the audit command submits, where it submits it, and what it asks for. Fetched 4 August 2026.
Where to go next
How to get an email when a GitHub repo publishes a release is the same comparison for releases rather than advisories — custom watch, releases.atom, Dependabot and NewReleases.io. How to track vendor changelogs and status pages in one place is the same comparison again for the third stream — the /history.atom feed convention, changelog RSS, StatusGator and this wire. The best developer news digest emails for releases and outages compares the edited digests — TLDR, Console.dev, Changelog News and daily.dev — and explains why an editor never picks the reviewed CVE in your lockfile. What the wire covers is the full list of the nine kinds on the feed and how the daily email works. Advisories and outages is the archive filtered to the reviewed-CVE and live-incident view. The wire is the current feed, newest first.