The prompt
Score 10 of 10, Excellent
Use it when A security scanner flagged a vulnerability in your code or dependencies, and you want it fixed properly, with a test that proves the hole is closed.
- {{finding}}
- {{affected_area}}
- {{test_command}}
- {{scan_command}}
- {{off_limits}}
Full prompt and why it works
Prompt
Goal: Fix the security finding below in this repository, so that the vulnerability is closed everywhere it occurs and the scanner no longer reports it, without changing behavior for legitimate users. Context: - The finding, as the scanner reports it (tool, rule or advisory ID, severity, file and line): """ {{finding}} """ - Where the affected code or package is used, as far as I know: {{affected_area}} - Test command: {{test_command}} - Command to re-run the scanner locally: {{scan_command}} Constraints: - First confirm the finding applies to our code. For a code finding, trace whether untrusted input can reach the flagged line; for a dependency, read the advisory and check whether we call the affected function. Reply with your conclusion before editing: real and reachable, real but not reachable, or a false positive, with the evidence. Wait for my go-ahead if you think it is a false positive. - Search for the same pattern elsewhere in the codebase, because one finding often has siblings the scanner missed, and list each one. - Fix the cause with the standard defense for this kind of bug, such as parameterized queries for SQL injection or output encoding for cross-site scripting, using what the framework already provides. Do not write your own escaping, sanitizing or cryptography. - For a dependency, upgrade to the lowest version that contains the fix, as the advisory states. If that is a new major version, stop and describe the breaking changes first. - Add a test that fails before the fix and passes after it, for example a request with a malicious input in tests/security/. Include only as much attack input as the test needs. - Do not suppress the finding with an ignore comment, a baseline entry or a scanner setting. Do not touch {{off_limits}}. - If the repository is public, keep the commit message neutral, such as "Validate redirect targets", and describe the vulnerability only in your report to me. Done when: - The new test passes and {{test_command}} passes. - {{scan_command}} no longer reports the finding, or, if the scanner cannot run here, you have explained why the fix closes it. Verify: run the tests and the scan, then report in this format: Reachable (yes or no, with the evidence), Fix, Other places changed, Test added, Commands run with the last 20 lines of their output, and Related risks you noticed but did not change.
Variables
- {{finding}}
- The scanner's finding as reported: tool, rule or advisory ID, severity, file and line, and its description.
- {{affected_area}}
- Where the flagged code or package is used, as far as you know, or "not sure".
- {{test_command}}
- The command that runs the tests, for example pytest or npm test.
- {{scan_command}}
- The command that re-runs the scanner, for example npm audit or semgrep scan, or "none, it only runs in CI".
- {{off_limits}}
- Files, folders or systems that must not change, for example the authentication service or database migrations.
Why it works
- If unsure. The agent first shows whether untrusted input can reach the flagged line, and waits before acting on a suspected false positive, so no fix is applied on a guess.
- What good looks like. A test that fails before the fix and passes after it proves the hole is closed, rather than only that the scanner has gone quiet.
- What to avoid. Ignore comments, baselines and scanner settings are off the table, as is home-made escaping or cryptography, which keeps the fix to the standard defense.