WackoWiki: Security Advisory Process

https://wackowiki.org/doc     Version: 7 (11/06/2026 13:09)

Security Advisory Process

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[link1] — 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

2. Develop the fix


fix: <short description>

  <what was wrong and what the patch does>

  ref: GHSA-xxxx-xxxx-xxxx		

3. Verify with the reporter

4. Publish the advisory


Fill in the GHSA fields:

Field What to put 
Severity CVSS v3.1 score
Vulnerable versions e.g. < 1.2.3
Patched version Leave blank or master if no release yet 
Fix commits The commit SHA from step 2
Description What the vulnerability is, the impact, the fix
Credit Reporter name, or “anonymous” if requested

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

5. Release & update

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