A post fix review should answer five things: why the flaw existed, whether similar flaws exist, whether a test now guards against it, how well the response ran, and what to change in your process. Keep it blameless, under an hour, and write the outcome down with owners and dates.
Why bother
A fix closes one report. A review improves the odds that you receive fewer of the same kind. Small teams skip it because the next task is already waiting, and then repeat the same mistake in a different file. The CERT Guide to Coordinated Vulnerability Disclosure treats the process as phases from reporting through remediation to public awareness and deployment. A review is the step that feeds lessons back into the earlier ones.
The agenda
Hold it within a week of publishing, while details are fresh. Invite the fixer, the person who ran intake, whoever wrote to customers, and one person who did not work on the case.
- Root cause. Not the line of code, the reason it was written that way. Missing input validation? An unclear internal API? A copied snippet?
- Siblings. Search for the same pattern. Record the result even if it is nothing.
- Guardrail. What test, lint rule or review checklist item would have caught it? Add it now.
- Timeline. Received, acknowledged, validated, fixed, released, published. Where did the longest waits happen?
- Communication. Did the reporter hear from you when promised? Did customers get clear instructions?
- Policy. Did anything in your disclosure policy turn out unclear?
A simple timeline table
| Step | Date | Gap since previous | Note |
|---|---|---|---|
| Report received | |||
| Acknowledged | |||
| Validated | |||
| Fix merged | |||
| Release shipped | |||
| Advisory published |
Fill it from your tracker. The gaps show where to invest. If validation took longest, you may need a documented test environment. If publishing took longest, you may need an advisory template.
Actions that come out of it
Aim for three to five actions, each with an owner and a date. Examples:
- Add a regression test that reproduces the original report.
- Add a lint rule for the unsafe pattern.
- Update the contributor guide with the safe helper function.
- Add the reporter's preferred contact method to the intake form.
- Write the customer notice template you wished you had.
Ask the reporter
Invite the reporter to retest and comment. Many are willing, and a second look at a fix catches incomplete patches. Ask what could have made reporting easier.
Keep it blameless
If people expect blame, they hide mistakes, and you lose the information you need. Focus on the system: what made the mistake easy to make and hard to notice.
Try it yourself
The SAST code scan demo shows how a code pattern gets flagged. Click through to see the kind of check that could become your guardrail after a review.
Click through it at your own pace, or open it full screen.
Quick check
Do we need a review for a low severity report?
A short version helps: root cause and a regression test. Low severity bugs often share causes with high severity ones.
Should the review be public?
That is your choice. Some teams publish a brief write-up. Keep customer data and unpatched details out of anything public.
Safeguard's policies, gates and guardrails can turn a review finding into an automated check on future pull requests. The free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
