Semgrep: the finding path is under the scan root

The path starts where the scan started

A finding prints a path such as app/health.py. That path is relative to the directory you pointed Semgrep at, or to the project root the job used. It is not a search key for every file of that name in the repository. Two services can each have an app/health.py.

The line number is inside that file, under that root. Opening a different copy and seeing a clean line does not clear the finding.

The root is in the job, not always in the finding

The finding text may not repeat the directory you passed. The job log or the working directory of the command does. Write it next to the path. If the job log was discarded, write “scan root not recorded” and do not pick a file by name alone.

A baseline commit, when one was set, is also part of the run. It does not change which directory the path is relative to. Keep it as its own field if you have it.

What to file

File the scan root, the path as printed, the line, and the rule id. If you opened a file, write the full path you opened and say it is under that root. Do not write that a different copy was the one scanned.

Worked case: the other health.py

A finding says app/health.py line 12, rule hb-no-debug-print. The job’s working directory was services/api. The repository also has tools/app/health.py, which does not have that line. A draft opens the tools copy, sees no match, and closes the finding.

The note says the scan root was services/api, so the file is services/api/app/health.py line 12. The tools copy was not this scan. The finding stays open against the file under that root.

scan root: services/api
path as printed: app/health.py  line: 12
rule: hb-no-debug-print
file that was scanned: services/api/app/health.py
other copy: tools/app/health.py was not this scan