A Semgrep finding that looks wrong should not be dismissed immediately. Static analysis tools often lack full business context, but they are also good at detecting patterns humans miss during review. The goal is to separate real risk from noise without training the team to ignore the scanner.
Start with the rule, not the annoyance
Read the rule message, severity, and matched code. Identify what the rule is actually warning about: injection, unsafe deserialization, missing validation, hardcoded secrets, path traversal, insecure randomness, or another class of risk.
Triage workflow
- Identify source and sink. Where does the input come from and where does it go?
- Check trust boundary. Is the input user-controlled, API-controlled, file-controlled, CI-controlled, or developer-only?
- Look for validation. Is validation allowlist-based and close to the boundary?
- Check exploitability. Can an attacker influence the value in a realistic path?
- Decide fix vs suppress. Prefer a small code hardening fix when it is cheap.
- Document suppressions. A suppression without explanation becomes future risk.
Good suppression format
# nosemgrep: python.lang.security.audit.dangerous-subprocess-use
# Safe because command is selected from a fixed allowlist above. Do not replace with user input.
subprocess.run(command, check=True)A vague comment such as “false positive” is not enough. Future maintainers need the reasoning.
When to tune rules
If a rule fires repeatedly on a safe internal pattern, tune the rule or add a project-specific rule. But do not globally disable high-value categories such as injection, secrets, or deserialization.
AI-generated code risk
AI coding tools often generate plausible validation that is too late, too broad, or not connected to the sink. When Semgrep flags AI-generated code, review the data flow manually before accepting the AI explanation.
Team policy
- High severity findings need explicit review before merge.
- Suppressions require a reason.
- Repeated false positives should become rule tuning work.
- AI-generated suppressions should be treated as suspicious until reviewed.
Related CodeRiskTools resources
- AI Code Security hub
- Free 5-point AI code review checklist
- CodeRiskTools product library — optional paid kits if you want templates and local checklists.
- Compare SAST tools
- Expert AI Code Security Audit — professional deep review for teams.
Note: This article is educational and designed for local/security-conscious workflows. Do not paste private source code or secrets into third-party tools.
How to decide whether a Semgrep finding is real
A good Semgrep triage process starts with data flow. Ask where the value originates, how it is transformed, and where it is used. The same code pattern can be safe in a closed internal constant and unsafe when connected to request parameters, file names, webhook payloads, or CI variables.
Source, transform, sink
Write a short note for each finding: source, validation, sink, and decision. For example, a path traversal warning may be safe if the value is selected from a fixed allowlist. It is not safe if the path is only checked for being non-empty or for not containing one suspicious string.
Prefer tiny hardening fixes
If the finding is easy to fix, harden the code even when exploitability is uncertain. Clear allowlists, typed schemas, safer library calls, and narrower file-system paths reduce future risk and make later reviews easier.
Use suppressions as documentation
A suppression should explain why the code is safe now and what future change would make it unsafe. This prevents a future developer or AI assistant from copying the pattern into a riskier context.
Semgrep triage examples
- Command execution: safe only when command and arguments come from a fixed allowlist.
- Path traversal: normalize paths and verify they remain inside an approved base directory.
- SQL injection: use parameterized queries instead of string concatenation.
- Hardcoded secrets: replace with environment variables or secret storage; do not suppress real credentials.
- Unsafe deserialization: prefer safer formats and schema validation.
FAQ: Semgrep false positives
Is a Semgrep false positive harmless?
It may be harmless in the current context, but it still deserves a short explanation. A future refactor can make the same pattern reachable from untrusted input.
When should I tune a Semgrep rule?
Tune a rule when it repeatedly flags a known-safe project pattern. Do not globally disable high-value security categories just to reduce noise.
How should AI-generated suppressions be handled?
Review them manually. AI assistants may add suppressions to make checks pass without proving the code is safe.
False positive review record
When a Semgrep finding is closed, leave enough context that another reviewer can understand the decision later. A useful record includes the rule name, affected file, why the data source is trusted or constrained, what validation protects the sink, and whether a small hardening change was made anyway.
This is especially important for AI-assisted development. If a coding agent later edits nearby code, the original safety assumption may no longer hold. A clear suppression comment or ticket note prevents a safe exception from turning into an invisible vulnerability after refactoring.
Recommended decision labels
- Fix now: real risk or cheap hardening opportunity.
- Suppress with reason: safe because of allowlist, fixed input, or unreachable path.
- Tune rule: repeated noisy pattern that is safe across the project.
- Needs owner review: business logic or data sensitivity is unclear.
