Skip to main content
Certain filetypes can generate numerous false positives and delay your triage process. This document helps you achieve a selective middle ground:
  • Continue to include the file type to scan with other rules
  • Reduce time spent triaging false positives

Background

This article uses a real-life case in scanning .svg files. svg files mostly comprise a string of thousands of characters:
Semgrep’s standard artifactory rule (see in Semgrep Registry), for example, reports on:
Because .svg files are made up of thousands of characters, the substring AP6*m... in the .svg snippet creates a false positive finding due to the artifactory rule. It is a false positive because no passwords are leaked by the .svg file.

Choosing the appropriate ignoring solution

Semgrep offers many different ways of ignoring false positives:
  • Adding nosemgrep as a comment on the first line of code in the file. This would require having to keep track of each new file for this target .svg file type and editing each file accordingly, requiring constant maintenance.
  • Ignore the file entirely, by adding it to a .semgrepignore file. This would exclude the file from being scanned with all rules, not just the artifactory rule.

Achieving a happy medium: creating a custom rule to exclude a file type

You can safely assume .svg files do not intentionally contain artifactory passwords, so you can exclude this file type from being scanned. The following procedure demonstrates how to create a customized version of the rule that is generating the false positives that excludes the target file type.
1
Download the rule generating false positives from the Registry.
2
Modify the rule ID to something custom:
3
Exclude the target filetype in question from the rule through the path field:
4
Alter the scan command to still scan for the default configuration you have, with the following changes:  i. Exclude the original noisy rule as articulated in the false positive reporting.  ii. Include the new custom rule that excludes your target paths.
Thus, your original semgrep scan command or semgrep ci command can be similar to the following::