Compared with GitHub Security Advisories
GitHub Security Advisories is the default for anything hosted on GitHub, and for a great many projects it is the right answer. This page is about the specific points where it stops fitting, and the one place it is decisively better.
An advisory that belongs to a repository
You open a draft advisory inside a repository, describe the vulnerability and affected versions, optionally request a CVE, and publish. The draft is private to the repository's maintainers until then, and it can be deleted. GitHub is a CNA, and the CVE Program lists its scope as covering CVEs requested by code owners using the Security Advisories feature, plus open-source vulnerabilities found by GitHub or Microsoft researchers that no other CNA covers.
The repository is not incidental to that. It is what the advisory is attached to, who can see the draft, and which ecosystem the published record is filed under.
What it does better, and it is not close
Publishing a GHSA puts your advisory into the GitHub Advisory Database, and from there Dependabot alerts every downstream project that depends on your package. Nobody has to subscribe to anything. That is a distribution channel GAdvisory has no access to and cannot build, and for a package author it is frequently the entire reason the advisory is being written.
It is also free, needs no infrastructure and no configuration, and the temporary private fork it gives you for developing the fix alongside the advisory is a genuinely good piece of workflow that GAdvisory does not have an equivalent for.
If your product is an open-source package your users pull from a registry, start there. Read the rest of this page only if something below actually applies to you.
Where it stops fitting
The coupling is the first thing to bite. One advisory belongs to one repository, so a vulnerability spanning several components, a product that is not a repository at all, or a closed-source appliance has nowhere natural to go. A project hierarchy exists because shipped products do not map one-to-one onto repositories.
The second is where the record is and who can read it. Drafts live on github.com under GitHub's terms, which is a considered risk for an open-source library and a different one for an embargoed flaw in a medical device. There is no version of it that runs inside your perimeter, and no version that keeps working when the network does not.
The third is the published surface. A GHSA is served from github.com, under GitHub's branding, at GitHub's URL. If your customers expect a security page on your own domain, or a regulator expects to find your disclosure record where your product is, that is not something the feature is trying to provide.
You do not have to choose
GAdvisory can mirror an advisory to a GitHub repository as a GHSA, so the record is yours and the Dependabot reach is still there. Drafts are free to iterate on; publishing one live needs explicit per-advisory consent, because that step is irreversible.
That is the arrangement most people who adopt GAdvisory while still shipping open source end up with: the authoritative record on their own infrastructure, and a mirrored GHSA doing the ecosystem's alerting.
Related
The other comparisons, and what it takes to run this yourself.