Ask the reporter how they want to be named before you publish, record that preference, add the credit with the right type, and write your credit rules in your policy. On GitHub, credited people must accept before their username becomes public, and only after the advisory is published.
Why credit matters
Credit is often the main thing a reporter gets for the work. It also shows other researchers that your project treats people fairly. Getting it wrong, such as misspelling a name or leaving someone out, costs goodwill that is hard to rebuild.
Steps
- Ask early. In your first reply, ask for the name, handle or organisation they want shown, and whether they prefer anonymity.
- Record it in the case file.
- Include everyone who helped. The finder, anyone who supplied a proof of concept, and anyone who tested the fix.
- Pick a credit type that matches the contribution.
- Confirm before publishing. Send the draft wording to the reporter.
- Publish and notify. Tell them the advisory is live.
How it works on GitHub
GitHub's documentation says that to credit someone you open the advisory in edit mode, go to the Credits section, search for people, add them, and choose a credit type from the dropdown beside each name. Each person receives an email or web notification inviting them to accept credit. Their username becomes publicly visible only if they accept, and only after the advisory is published. After publication, anyone can see the credits the credited users have accepted.
Practical consequence: add credits well before publication so that people have time to accept.
Cases to plan for
| Case | Approach |
|---|---|
| Reporter wants anonymity | Honour it; do not mention name or organisation |
| Reporter has no GitHub account | Name them in the advisory text, using the wording they gave you |
| Several independent reporters | Follow your written policy and apply it equally |
| Team of researchers | Ask whether to list the team or individuals |
| Reporter uses a handle | Use the handle exactly as given |
Write the credit rules
Put these in your policy: who gets credit, whether duplicate reporters are credited, whether credit is listed in release notes, and whether you keep a thank you page. The post on duplicate reports covers the awkward case.
Credit is not payment
Credit and a reward are different. If you do not offer payments, say so in the policy, and do not hint that credit will lead to a payout. See reporters who ask for payment.
Quick check
Can we publish the advisory if the reporter has not accepted credit?
Yes. The advisory goes out, and the credit appears once they accept. Do not delay a customer facing fix for it.
Should we credit someone who broke our rules?
Decide with your leadership, following your policy. See the post on researchers who break disclosure rules.
Safeguard's compliance and evidence automation can help keep a dated record of the handling of each case. The free scan is at gold.safeguard.sh/scan.
Sources
- GitHub Docs, editing a repository security advisory
- GitHub Docs, about repository security advisories
Last reviewed: 19 October 2026.
