Short orientation for everyone involved — reporters and maintainers — covering the full lifecycle of a vulnerability report in WackoWiki.

For reporters

1. Check the Security Policy — make sure the issue actually qualifies.
2. Open a GitHub Security Advisory (preferred) or email the maintainer.
3. Describe the problem: how to reproduce, what the impact is. A fix suggestion is welcome but not required.
4. Wait for acknowledgement (target: 48 h). No response after 7 days? Follow up.
5. Verify the fix when the maintainer asks you to.
6. Get credited in the published advisory (or stay anonymous — just say so).

For maintainers

1. Receive & triage

• Acknowledge the report (even if it's just “got it, looking at it”).
• Confirm it qualifies under the Security Policy. If it doesn't, explain why and close it as a regular issue if appropriate.

2. Develop the fix

• Work on the fix. Keep the reporter in the loop if you need clarification.
• Commit the fix to master. Reference the GHSA ID in the commit message body:

fix: <short description>

  <what was wrong and what the patch does>

  ref: GHSA-xxxx-xxxx-xxxx		

3. Verify with the reporter

• Message the reporter: «Fix is committed — can you confirm it closes the issue?»
• Wait 48 h.
• Confirmed → proceed to publish.
• Not closed / bypass found → fix again, re-verify, then publish.
• No response → publish anyway. You've given them the chance.

4. Publish the advisory

Fill in the GHSA fields:

Publish. The GHSA auto-link in the commit resolves immediately.

5. Release & update

• Cut the release tag (hotfix or regular, depending on severity).
• Update the published GHSA: set “Patched version” to the release tag.
• Link the advisory in the release notes / changelog.

Decision tree (quick reference)

Report received
│
├─ Qualifies?
│   ├─ No → explain, close, optionally open regular issue
│   └─ Yes ↓
│
├─ Fix developed & committed
│
├─ Reporter verifies?
│   ├─ Yes → publish
│   ├─ No (bypass) → fix again → verify → publish
│   └─ No response (48 h) → publish
│
├─ Advisory published
│
└─ Release cut
    └─ Update GHSA "Patched version" field		

What NOT to do

• Don't publish the advisory before the fix is in master.
• Don't open a public GitHub Issue for an undisclosed vulnerability.
• Don't request a CVE. The GHSA ID is the reference.
• Don't block publication on reporter silence.
• Don't leave the “Patched version” field blank indefinitely — update it when the release ships.