Pick the question before the scan mode
A repository-wide baseline, a scoped service scan and a PR diff scan answer different questions. Choose the smallest mode that covers the decision you need to make and record the checkout commit, scan configuration and exclusions.
Use a repository you are authorised to assess. Keep scan output outside tracked source files unless you deliberately intend to review and commit a report.
Read four kinds of evidence
A small finding count is not proof of safety if key paths were skipped. Check the current official README and CLI reference for commands and prerequisites before running a local trial.
- Human-readable report: what the tool says and where to begin.
- Structured findings: identifiers, code locations, claimed impact and evidence.
- Manifest: source revision, tool version, configuration and run status.
- Coverage: what paths, languages or files were examined or excluded.
Validate one candidate before fixing it
- Trace the claimed untrusted source to the dangerous operation.
- Check guards, validation, identity and production configuration that the scan may have missed.
- Build a safe, synthetic reproducer or focused test for the vulnerable behaviour.
- Classify the finding as confirmed, plausible or unsupported with evidence.
- Define both the security invariant and the legitimate behaviour the patch must preserve.
- Make a small fix, rerun the focused test and relevant repository tests.
Finding: <ID AND LOCATION>
Source to sink: <PATH>
Assumed configuration: <VALUE>
Existing guard: <YES / NO / UNKNOWN>
Reproducer: <SAFE TEST AND RESULT>
Decision: <CONFIRMED / PLAUSIBLE / UNSUPPORTED>
Fix and regression test: <COMMIT / COMMAND / RESULT>Compare evidence across runs
AI-assisted scans can vary even on the same revision. Match findings by root cause rather than raw count, rerun the baseline when needed, and verify the original path after a fix. Start CI in report-only mode until you understand noise, coverage and cost; a blocking threshold should follow that evidence.