Security Advisory Process

1

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:


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

  • 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.

Comments

  1. Maintainer-only — operational details

    Appendix: Maintainer Operational Notes

    Adding a GHSA reference to an already-committed fix 


    If the fix was committed before the GHSA ID was issued:

    Latest commit on the branch:
    BASH 
    git commit --amend
# add GHSA-xxxx-xxxx-xxxx to the message body
git push --force-with-lease


    Older commit (e.g., second-to-last):
    BASH 
    git rebase -i HEAD~N   # N = commits back to the target
# change "pick" → "reword" on the target commit
# add GHSA-xxxx-xxxx-xxxx to the message
git push --force-with-lease


    If you don't want to rewrite history (shared branch, or just to keep it simple):
    BASH 
    git commit --allow-empty -m "ref: GHSA-xxxx-xxxx-xxxx"

    Force-push safety


    --force-with-lease only overwrites the remote if its tip matches your local origin/<branch>. If someone else pushed in the meantime, it's rejected. For a solo project this is a no-op safety check, but make it a habit.

    EGit caveat: EGit may run a background git fetch between your rebase and your push, which updates origin/master to the new remote tip and silently nullifies the lease. For solo work this doesn't matter. On a shared repo, disable EGit's auto-fetch or use git push --force-if-includes (Git 2.30+).

    Dangling commits after rebase


    After a reword rebase, the old commit becomes unreachable. On GitHub it shows the banner “This commit does not belong to any branch on this repository.”
    • You cannot trigger GC on GitHub. It will be pruned on their schedule.
    • Locally, clean it up if it bothers you:
    BASH 
    git reflog expire --expire-unreachable=now --all
  git gc --prune=now

    • The “two commits with the same diff” you see in the GitHub commit list is the old (dangling) one. It won't appear in git log, PRs, or clones. Ignore it.

    GHSA auto-link timing


    The GHSA ID in a commit message only resolves to a clickable link after the advisory is published. While the advisory is in draft, it renders as plain text. No re-push needed after publishing.

    Updating the advisory after release


    When you cut the release tag:
    1. Edit the published GHSA → set “Patched version” to the tag (e.g., v1.2.4).
    2. Add the tag to the release notes / changelog with a link to the advisory.

    You can edit a published GHSA at any time — there's no “re-publish” step.