Skip to main content

Findings in CI

When running any Semgrep product in CI, Semgrep is able to track the lifetime of an individual finding. When configured to perform a diff-aware scan, Semgrep only shows new findings relative to some specified baseline commit.

In the code, a Semgrep finding in CI 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 Code findings​

Semgrep AppSec Platform builds on CI findings to track status and provide additional context for managing findings within your organization. A finding can be one of four statuses in Semgrep AppSec Platform:

  • OPEN
  • REVIEWING
  • FIXING
  • IGNORED
  • FIXED

Finding status​

You can manage finding status through triage in Semgrep AppSec Platform'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 has not been ignored. An open finding represents a match between the code and a rule enabled in the repository. Open findings require action, such as rewriting the code to eliminate the detected vulnerability.
ReviewingIndicates that the finding requires investigation to determine what the next steps in the triage process should be.
FixingFindings for which you have decided to fix. Commonly used to indicate that these findings are tracked in Jira or assigned to developers for further work.
FixedFixed findings were detected in a previous scan but are no longer detected in the most recent scan of that same branch due to changes in the code.
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 AppSec Platform or by adding a nosemgrep code comment. You can also provide a reason for why you are ignoring a finding: False positive, Acceptable risk, No time to fix.

Removed findings​

Findings can also be removed. Semgrep considers a finding removed if it is not found in the most recent scan of the branch where Semgrep initially detected it due to any of the following conditions:

  • The rule that detected the finding isn't enabled in the policy anymore.
  • The rule that detected the finding was updated such that it no longer detects the finding.
  • The file path where the finding appeared is no longer found. The file path was deleted, renamed, added to a .semgrepignore file, added to a .gitignore file, or added to the list of ignored paths in Semgrep AppSec Platform.
  • For GitHub organization accounts: the PR or MR where the finding was detected has been closed without merging.

Your removed findings do not count toward the fix rate or the number of findings. The removed findings also do not appear in Semgrep AppSec Platform.

Findings triaged across refs

Findings triaged (ignored, reopened) in a specific branch, PR, or MR are also triaged in all other branches, PRs, and MRs of a particular repository. Additionally, if you filter for Git references (refs) on the Findings page, then triage a finding, the finding is also automatically triaged in all other branches, PRs, MRs, and refs.

Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.