| 1 | --- |
| 2 | title: Advisories and private reporting |
| 3 | description: What a repository tells people about vulnerabilities in what it ships, and how people tell its maintainers about one privately. Security advisories with G1TSA ids, drafted, published and withdrawn; private vulnerability reports, accepted into draft advisories. |
| 4 | --- |
| 5 | |
| 6 | The Reporting half of a repository's Security page is for vulnerabilities in |
| 7 | what the repository itself ships, as opposed to the |
| 8 | [findings](/guides/security/) g1t makes in its code and dependencies: |
| 9 | |
| 10 | - A **security advisory** is the maintainers' own account of a vulnerability: |
| 11 | what is affected, what fixes it, how bad it is and who found it. It is a |
| 12 | draft until they publish it, visible to anyone who can see the repository |
| 13 | once they do, and can be withdrawn. |
| 14 | - A **vulnerability report** is how someone outside tells the maintainers |
| 15 | privately, when the repository takes such reports: from its Security tab, |
| 16 | without an issue anyone can read. Accepting a report makes a draft advisory |
| 17 | from it. |
| 18 | |
| 19 | Both live under `g1t.sh/<owner>/<project>/security/advisories`; the Security |
| 20 | overview's **Reporting** rows say where each stands. |
| 21 | |
| 22 | ## The security policy |
| 23 | |
| 24 | The first row of the overview is the repository's **security policy**: a |
| 25 | `SECURITY.md` on the default branch (or `.github/SECURITY.md`, or |
| 26 | `docs/SECURITY.md`) that says how to report a vulnerability and which |
| 27 | versions get fixes. When there is none, **Set up a security policy** commits |
| 28 | a starting one on a new branch and opens it as your pull request, as **Set |
| 29 | up code scanning** does with its workflow. The template says how to report, |
| 30 | names the private reporting form when that is on, and leaves the supported |
| 31 | versions for you to fill in. Anyone who can see a public repository sees the |
| 32 | policy from its Security tab. |
| 33 | |
| 34 | ## Advisories |
| 35 | |
| 36 | ### Writing one |
| 37 | |
| 38 | Admins of the repository, and the workspace's |
| 39 | [security managers](/guides/access-and-roles/), write advisories: **New |
| 40 | advisory** under Advisories. An advisory has: |
| 41 | |
| 42 | | Field | What it is | |
| 43 | | --- | --- | |
| 44 | | Title and description | One line, and Markdown: what the vulnerability is, how it is exploited, what to do. The description is needed before publishing. | |
| 45 | | Severity | Critical, high, medium or low. | |
| 46 | | Affected package | How it is distributed (`npm`, `crates.io`, `Go`, `PyPI`, or how the project ships), the package, the versions affected and the versions that fix it, as ranges people write (`>= 1.2.0, < 1.4.1`). | |
| 47 | | CVSS | A vector string and its score, when the maintainers scored it. | |
| 48 | | CVE id | `CVE-2026-12345`, when one was issued elsewhere. | |
| 49 | | Credits | Who found or fixed it: usernames or names, up to twenty. | |
| 50 | |
| 51 | Every advisory has an id of the form `G1TSA-2026-h7kd-3mqw`, given when it is |
| 52 | drafted; pages and the API take it, or the `adv_…` id behind it. |
| 53 | |
| 54 | ### Draft, published, withdrawn |
| 55 | |
| 56 | A **draft** is seen by those who see the repository's findings (Write, or a |
| 57 | security manager). Nobody is told of it. |
| 58 | |
| 59 | **Publish** makes it visible to anyone who can see the repository, at |
| 60 | `…/security/advisories/G1TSA-…`, sends `security_advisory.published` to |
| 61 | [webhooks](/guides/webhooks/) and tells the repository's watchers who chose |
| 62 | **Security alerts**. A published advisory may be edited; the change shows at |
| 63 | once. |
| 64 | |
| 65 | **Withdraw** takes it off the list for everyone but those who see findings, |
| 66 | and sends `security_advisory.withdrawn`. A withdrawn advisory can be published |
| 67 | again. |
| 68 | |
| 69 | ## Private vulnerability reporting |
| 70 | |
| 71 | A repository takes private reports when **Private vulnerability reporting** |
| 72 | is on: a switch on the Security overview's Reporting rows and in |
| 73 | [Security settings](/guides/security/#settings), for Admins and security |
| 74 | managers. Off by default. |
| 75 | |
| 76 | With it on, **Report a vulnerability** is on the repository's Security tab |
| 77 | for anyone who can see it. Someone signed in reports under their name; on a |
| 78 | public repository someone signed out may report too, with an email address |
| 79 | the maintainers can answer at. A report has a title, a description (Markdown) |
| 80 | and, if the reporter has a view, a severity. Only the maintainers see it: the |
| 81 | reporter sees their own report sent, and nothing else of the repository's |
| 82 | reports. |
| 83 | |
| 84 | The workspace's owners and security managers are told at once, in |
| 85 | [Notifications](/guides/notifications/#security) ("A vulnerability was |
| 86 | reported privately to acme/rocket") and by email, whatever their digest |
| 87 | settings say: a report is something to act on. |
| 88 | |
| 89 | To keep the form from being flooded, one reporter sends at most five reports |
| 90 | a day to one repository, a repository holds at most fifty new reports |
| 91 | waiting, and the site limits how fast one address can post to it. |
| 92 | |
| 93 | ### Reviewing reports |
| 94 | |
| 95 | Under **Advisories → Reports**, those who see findings read the reports, |
| 96 | new ones first. An Admin or security manager settles each: |
| 97 | |
| 98 | - **Accept** makes a draft advisory from it, in the reporter's words and |
| 99 | crediting the reporter, for the maintainers to finish and publish. The |
| 100 | report links to the advisory. |
| 101 | - **Decline** closes it, with an optional note for the record. |
| 102 | |
| 103 | Each is written to the workspace's [audit log](/guides/audit-log/), as |
| 104 | advisories drafted, changed, published and withdrawn are. |
| 105 | |
| 106 | ## API and MCP |
| 107 | |
| 108 | | Route | What it does | Scope | |
| 109 | | --- | --- | --- | |
| 110 | | `GET /repos/{owner}/{name}/security/advisories` | Lists advisories; filter with `state`. Published ones to anyone who can see the repository; every state to those who see findings. | `security:read` | |
| 111 | | `POST /repos/{owner}/{name}/security/advisories` | Drafts an advisory: `title`, `severity`, and the fields above in `snake_case`. Admin, or a security manager. | `security:write` | |
| 112 | | `GET /repos/{owner}/{name}/security/advisories/{id}` | One advisory, by `adv_…` or `G1TSA-…` id. | `security:read` | |
| 113 | | `PATCH /repos/{owner}/{name}/security/advisories/{id}` | Changes its fields; what is left out stays. | `security:write` | |
| 114 | | `POST /repos/{owner}/{name}/security/advisories/{id}/state` | `state` `published` or `withdrawn`. | `security:write` | |
| 115 | | `GET /repos/{owner}/{name}/security/reports` | The reports, new ones first; filter with `state`. Those who see findings. | `security:read` | |
| 116 | | `POST /repos/{owner}/{name}/security/reports` | Reports a vulnerability: `title`, `description`, optional `severity`, and `email` without a token on a public repository. | `security:write`, or none | |
| 117 | | `PATCH /repos/{owner}/{name}/security/reports/{id}` | `decision` `accept` or `decline`, with an optional `note`. | `security:write` | |
| 118 | |
| 119 | The MCP server's `security` tool has the same as actions: `advisories`, |
| 120 | `advisory`, `create_advisory`, `update_advisory`, `set_advisory_state`, |
| 121 | `reports`, `report_vulnerability` and `review_report`. The |
| 122 | [API reference](/reference/api/) documents each route. |
| 123 | |
| 124 | Webhooks get `security_advisory.published`, `security_advisory.withdrawn` and |
| 125 | `security_advisory.reported` (which names no reporter and carries no |
| 126 | description: it says to look). |