Fix Finding

Fix Finding

Objective

Turn a security finding into a minimal, validated code change when the issue still exists. If the issue is already fixed, prove that with focused validation and report that no code change was needed. The result should include the fix if one was needed, focused regression tests or another repeatable validation check, proof that normal behavior still works, and proof that the original issue no longer reproduces.

Inputs

Start by extracting any available finding details:

• title and affected component
• vulnerable source, sink, or broken control
• attacker-controlled input
• expected security invariant
• impact and required preconditions
• existing PoC, reproducer, test, or validation evidence
• files and line references

If a critical field is missing, inspect the repository to fill it from code evidence. Ask the user only when the fix would otherwise require guessing a product policy or security invariant.

Note on Runtime Validation

Use this guidance whenever reproducing the finding, running tests, or validating the fix:

• Try hard to make runtime validation run before falling back to code inspection.
• First consult the repository instructions such as AGENTS.md, README.md, setup docs, test docs, build files, or package-manager metadata for the necessary requirements.
• If dependencies, generated files, services, or local setup are missing, use the repository's documented setup, package manager, build system, or existing test commands to install or generate what is needed.
• Treat setup errors as intermediate blockers to investigate and repair with targeted commands, not as an immediate reason to abandon runtime validation.
• Do not abandon a reproduction, build, test, or validation command just because it takes time when there is output, resource usage, generated artifacts, or other evidence of progress and no hard evidence of failure.
• If a long-running command appears inconclusive, run targeted checks such as process status, recent logs, output file timestamps, resource usage, or test runner status to distinguish progress from a hang before stopping or weakening validation.

Workflow

1. Scope the fix.
   • Inspect the affected files and the smallest set of supporting files needed to understand the vulnerable path.
   • Identify the narrowest code boundary where the security invariant should be enforced.
   • Check for existing helpers, validators, permission checks, sanitizers, policy objects, and test patterns before adding new ones.
2. Reproduce or encode the issue before fixing when feasible.
   • Prefer a failing regression test, unit test, integration test, property test, or realistic-interface reproduction.
   • Follow the runtime validation guidance above before deciding runtime reproduction is not feasible.