skip to content

In GitHub, what is a repository security advisory, and what does private vulnerability reporting add?

level: seniorimportance: should knowfreq 31%

answer

  1. A vulnerability in your code, not your dependencies
  2. There is a private place to build the fix
  3. Publication is what reaches consumers
  4. Version ranges are the machine-readable part

basics

~20 s

A GitHub repository security advisory is a draft record of a vulnerability in your own project, with a private fork for developing the fix and an optional CVE request. Private vulnerability reporting gives researchers a private channel that opens such a draft instead of a public issue.

solid answer

~50 s

A **repository security advisory** lives under the repository's Security tab. You draft it privately: summary, severity, affected package with a vulnerable version range, and the patched version. GitHub gives you a **private temporary fork** so the fix can be developed and reviewed without the commit appearing publicly before disclosure, and you can invite specific collaborators. You may request a CVE identifier through GitHub, which is a CVE Numbering Authority. On publish, the advisory becomes a **GHSA** entry in the GitHub Advisory Database. That is what makes it operational for everyone else: consumers whose dependency graph shows a version inside your declared vulnerable range get alerted. The version range is the payload — get it wrong and you either miss affected users or alarm unaffected ones. **Private vulnerability reporting** is a repository setting that gives researchers a *Report a vulnerability* button. Without it, the only channel most projects offer is a public issue, which is disclosure before a fix exists.

code

json · 12 lines
json
{
  "summary": "Path traversal when extracting archives",
  "description": "Entries containing ../ escape the target directory.",
  "severity": "high",
  "vulnerabilities": [
    {
      "package": { "ecosystem": "maven", "name": "com.example:archiver" },
      "vulnerable_version_range": ">= 2.0.0, < 2.4.1",
      "patched_versions": "2.4.1"
    }
  ]
}

go deeper

for a junior

Know that GitHub repositories can publish security advisories about their own vulnerabilities, and that private vulnerability reporting is how researchers reach maintainers without opening a public issue.

for a middle

Explain the draft, the private temporary fork for developing the fix, publication into the advisory database, and why the affected version range is the field that makes downstream alerting work.

for a senior

Demonstrate coordinated-disclosure judgment: who owns intake, keeping the fix private until release, publishing an accurate range, and having the patched version actually available at publication.

for a principal

Own the policy across a portfolio — a monitored intake channel for every public repository, a named responder, and disclosure timelines your organisation can actually meet.

## Two sides of the same feature Most security discussion on GitHub is about vulnerabilities in *your dependencies*. Advisories are the other direction: a vulnerability in **your own code**, which you must coordinate, fix and announce. Interviewers use this to find out whether a candidate has ever been on the receiving end of a report. ## The advisory itself A repository security advisory is drafted privately in the repository's Security tab. Its fields are not decoration — each one has a downstream consumer: - **Summary and description** — what a consumer reads when they are triaging. - **Severity** — either a qualitative level or a CVSS vector, used to prioritise. - **Affected package(s)** — ecosystem plus package name, in the form that ecosystem uses. - **Vulnerable version range** and **patched version** — the fields that make automated matching work. While drafting, GitHub can create a **private temporary fork** of the repository. Fix development and review happen there, invisible to the public, so the fix commit does not tip off attackers before the release. You add named collaborators — including the reporter, often — and nobody else sees the work. GitHub is a CVE Numbering Authority, so you can request a CVE identifier from the draft rather than going elsewhere. Independently, the advisory always gets a **GHSA** identifier of its own. ## Publication and what it triggers Publishing does two things. The advisory becomes visible on the repository, and the entry lands in the **GitHub Advisory Database**. From there, every downstream repository whose dependency graph contains your package at a version inside the vulnerable range can be alerted — that is the whole point of the exercise. A carefully written advisory reaches thousands of consumers automatically; a vaguely written one, with a range like "all versions before the latest", produces noise that people learn to ignore. This is why the version range deserves real care. Too wide and you generate alerts for people who were never affected, which trains them to dismiss your advisories. Too narrow and genuinely vulnerable consumers hear nothing at all. ## Private vulnerability reporting Private vulnerability reporting is a repository setting. When enabled, the repository's Security tab offers a **Report a vulnerability** button to anyone who finds one, and the report arrives as a private draft advisory visible to maintainers. It can be enabled per repository, and organisations can enable it across repositories including new ones. Why it matters is a process argument, not a technical one. Without a private channel, a researcher's realistic options are: open a public issue (immediate zero-day disclosure), email an address that may not exist or may not be monitored, or give up. Every one of those is a bad outcome for your users. The button costs nothing and converts "disclosed on a public issue tracker" into "disclosed to maintainers, coordinated, published with a fix available". It also creates the paper trail. Report, discussion, fix in the private fork, publication, credit to the reporter — all in one place, timestamped, rather than scattered across email threads. ## The failure modes worth naming - **Nobody is watching the channel.** Enabling reporting without assigning someone to receive it is theatre. Reports go stale, researchers publish anyway, and you learn about it from social media. - **The fix is pushed to a public branch first.** The private fork exists precisely to avoid this, and it is the most common self-inflicted disclosure. - **Publishing without a release.** An advisory naming a patched version that is not yet available leaves consumers alerted and unable to act. - **No advisory at all.** Fixing quietly in a patch release means downstream consumers on the vulnerable version get no alert, because nothing was ever published for their graph to match against. ## The senior-level point The technical mechanism is small; the discipline around it is what an interviewer is probing. Coordinated disclosure means: a private intake channel that someone owns, private fix development, an advisory whose version ranges are accurate, a release ready at publication, and credit to the reporter. The GitHub features exist to make each of those steps the path of least resistance — but they do not supply the owner, and that is the piece organisations most often skip.

  • Why develop the fix in the private temporary fork rather than a normal branch?
    Because a public branch is public. A commit that patches an input-validation bug is a road map to the bug, and pushing it before the release hands attackers a window against every unpatched consumer. The private fork lets the fix be written and reviewed normally while staying invisible until you publish.
  • Is it enough to fix the vulnerability quietly in the next patch release?
    No. Without a published advisory there is nothing for downstream dependency graphs to match against, so consumers still on the vulnerable version are never alerted. They upgrade whenever they happen to, which for a transitive dependency can be never. The advisory is the part that reaches them.
  • What has to exist behind the reporting button for it to be worth enabling?
    A named owner who receives reports, an expected response time, and a rehearsed path from draft to published advisory with a release available. Enabling intake nobody monitors is worse than having no channel: the researcher believes they disclosed responsibly, waits, and then publishes when you do not reply.

saying these in an interview costs you the question

  • Confusing an advisory with a dependency alert
  • Developing the fix on a public branch before disclosure
  • Writing a vulnerable range as all earlier versions
  • Enabling private reporting with nobody monitoring it
  • Believing an advisory requires a CVE to be useful

context

resolving links…