Skip to main content

Sponsor Fix Review

Use this workflow when a sponsor sends a fix branch, patch, or PR after you reported a finding. The goal is to decide whether the patch addresses the root cause without introducing new issues.

Prepare the local repository​

  1. Check out the sponsor fix branch locally.
  2. Confirm the branch and commit with Git.
  3. Open the repository in PastePrompt.
  4. Set the diff base to the commit, tag, or branch used for the original review.
  5. Set the diff head to the sponsor fix branch.

Example:

audit-base...sponsor-fix

Build the bundle around the original finding and patch:

  1. Original issue: include a concise issue summary, root cause, affected function, and expected security property.
  2. Expected fix: describe what a correct fix should change.
  3. Git diff: include the diff between baseline and sponsor branch.
  4. Changed files: include full files for changed modules, helpers, tests, or config.
  5. Related dependencies: include interfaces, helpers, shared types, and tests needed to evaluate the fix.
  6. Review criteria: state what would count as fixed, partially fixed, or not fixed.
Original issue:
- Title:
- Root cause:
- Impact:
- Affected code:

Expected fix:
- What behavior should change:
- What invariant should now hold:

Git diff:
- Review the included base/head diff.

Changed files:
- Use full changed file context when needed.

Related dependencies:
- Use included imports, interfaces, tests, and helpers.

Review criteria:
- Determine whether the root cause is fixed.
- Identify regressions or new risks introduced by the patch.
- Do not report speculative issues outside the selected context.
- State what additional file or test is needed if context is insufficient.

Review steps​

  1. Start with diff-only context.
  2. Add full changed files when the patch depends on surrounding code.
  3. Add tests that prove or attempt to prove the fix.
  4. Add dependencies only when they affect the root cause.
  5. Run the secret scanner.
  6. Export Markdown for your review notes.
  7. Validate the fix locally with the repository test harness.

What to verify​

  • The patch fixes the root cause, not only the symptom.
  • The affected invariant now holds.
  • The original exploit or failure scenario is blocked.
  • The patch does not create a new authorization, accounting, data integrity, or integration issue.
  • Regression tests cover the original issue.