Skip to main content

Managing findings

Findingsโ€‹

A finding is the core result of Semgrep's analysis. Findings are generated when a Semgrep rule matches a piece of code. After matching, a finding can make its way through 3 parts of the Semgrep ecosystem: Semgrep CLI, Semgrep CI, and Semgrep App.

Semgrep CLIโ€‹

Semgrep command line findings are produced by a specific rule matching a piece of code. Multiple rules can match the same piece of code, even if they are effectively the same rule. For example, consider the following rule and code snippet:

rules:
- id: finding-test
pattern: $X == $X
message: Finding test 1
languages: [python]
severity: WARNING
- id: finding-test
pattern: $X == $X
message: Finding test 2
languages: [python]
severity: WARNING
print(1 == 1)

Running Semgrep

semgrep --quiet --config test.yaml test.py

Running Semgrep produces the following findings:

test.py
severity:warning rule:finding-test: Finding test 1
1:print(1 == 1)
--------------------------------------------------------------------------------
severity:warning rule:finding-test: Finding test 2
1:print(1 == 1)

For more information on writing rules, see Rule syntax.

Semgrep CIโ€‹

Semgrep CI, designed to continuously scan commits and builds, improves on Semgrep findings to track the lifetime of an individual finding. When configured to perform a diff scan, it will only show new findings relative to some specified baseline commit.

In the code, a Semgrep CI finding is defined by a 4-tuple:

(rule ID, file path, syntactic context, index)

These states correspond to:

  1. rule ID: The rule's ID within the Semgrep ecosystem.
  2. file path: The filesystem path where the finding occurred.
  3. syntactic context: The lines of code corresponding to the finding.
  4. index: An index into identical findings within a file. This is used to disambiguate findings if the same syntactic context occurs multiple times in the same file.

Semgrep Appโ€‹

Semgrep App builds on Semgrep CI findings to track status and provide additional context for managing findings within your organization. A finding can occupy 4 statuses in Semgrep App: OPEN, IGNORED, FIXED, REMOVED.

Finding statusโ€‹

You can manage finding status through triage in Semgrep App's Findings page. The finding statuses are as follows:

StatusDescription
OpenFindings are open by default. A finding is open if it was present the last time Semgrep scanned the code and it has not been ignored. An open finding represents a match between the code and a rule that is enabled in the repository. Open findings require action, such as rewriting the code to eliminate the detected vulnerability.
IgnoredFindings that are ignored are present in the code, but have been labeled as unimportant. Ignore findings that are false positives or deprioritized issues. Mark findings as ignored through Semgrep App (see Managing finding status) or by adding a code comment (see nosemgrep comments).
Fixed

Fixed findings were detected in a previous scan, but are no longer detected in the most recent scan of that same branch.

To change the state of a finding to fixed:

  1. Fix the code so the rule does not match it.
  2. Edit the Semgrep rule so it no longer matches the code.

Findings can also be removed. A removed finding does not count towards the fix rate or the number of findings. The removed finding also does not appear in the Semgrep App. A finding is removed if it is not found in the most recent scan of the branch where it was detected due to any of the following conditions:

  • The rule isn't enabled on the repository anymore.
  • The file path where the finding appeared is no longer found (it was deleted, renamed, added to a .semgrepignore, added to a .gitignore or added to the list of ignored paths in Semgrep App).
  • The PR or MR where the finding was detected has been closed without merging.

Find what you needed in this doc? Join the Slack group to ask the maintainers and the community if you need help.