> ## Documentation Index
> Fetch the complete documentation index at: https://semgrep-ee9d73d8-mintlify-b75b9a88.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# View findings in Semgrep AppSec Platform
Semgrep Code generates a **finding** when a rule matches a piece of code in your codebase. You can use Semgrep AppSec Platform's [**Code** page](https://semgrep.dev/orgs/-/findings) to view all of the findings generated by Semgrep Code after it scans your codebase.
## View findings
To view your findings in Semgrep AppSec Platform:
Log in to [Semgrep AppSec Platform](https://semgrep.dev/login).
In the **Navigation bar**, click **[Code](https://semgrep.dev/orgs/-/findings)**.
By default, Semgrep displays your **Priority** findings. Priority findings are defined as findings that:
* Are categorized as **Security** findings. You can identify findings categorized under **Security** using the badge.
* Are flagged with a severity level of **critical** or **high**
* Are flagged with a confidence level of **high**
* Are flagged by Semgrep Multimodal as likely being a **true positive** or has *not* been analyzed by Multimodal yet
You can switch to the **All** tab at any point to view all findings identified by Semgrep Code. Both the **Priority** findings view and the **All** findings view display high-level information about your findings.
**LOCAL SCANS**
Findings from local scans are differentiated from their remote counterparts through their slugs. Remote repositories are identified as ACCOUNT\_NAME/REPOSITORY\_NAME, while local repositories are identified as local\_scan/REPOSITORY\_NAME.
### Custom Priority tab
Semgrep admins can create a custom priority definition to change the findings shown on the **Priority** tab. To do so:
Log in to [Semgrep AppSec Platform](https://semgrep.dev/login).
In the **Navigation bar**, click **[Code](https://semgrep.dev/orgs/-/findings)**. Ensure that you're viewing the **Priority**.
Using the provided filters, set your parameters for priority findings.
Click **Save**.
You'll see a dialog window asking you to confirm that you want the changes saved for everyone. Click **Save** to proceed.
This change applies to the entire Semgrep organization. You cannot have separate priority definitions for individual users or teams.
## Filter findings
Regardless of whether you use the **Priority** findings view or the **All** findings view, there are multiple grouping and filtering options available to you.
### Time period
The time period filters allow you to see which vulnerabilities were opened, fixed, or triaged during a certain period of time. The time period filter is **not** additive; it is a filter operation that precedes other filters on the page. For example, if you select **Last triaged** and select the status **Status Open** filter, no findings appear because, by definition, there are no triaged findings that are also open.
The following filters are available:
* Triage state update action:
* Opened in
* Triaged in
* Fixed in
* Time period:
* Last day
* Last 7 days
* Last 30 days
* Last 3 months
* Last 6 months
* Last year
* All time
### Project
The **Project** filter allows you to search for findings associated with the selected projects.
### Status
The **Status** filter allows you to search for findings in the selected statuses. See [Triage status](/semgrep-code/triage-remediation#triage-statuses) for additional information.
### Additional filters
Semgrep offers additional filters that you can use to narrow down your results. The following filters are available:
| Filter | Description |
| :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Severity** | Filter by the severity of a finding. Severity is computed based on the values assigned for [Likelihood](/contributing/contributing-to-semgrep-rules-repository/#likelihood) and [Impact](/contributing/contributing-to-semgrep-rules-repository/#impact) by the rule's author. Possible values: |
| **Category** | Filter by the type of security issue or vulnerability the rule detects, such as `security`, `correctness`, and `maintainability`. You can select more than one category at a time. See [Finding categories](#finding-categories) for information on how Semgrep categorizes your findings. |
| **Confidence** | Filter by the likelihood of the rule to detect true positives. The higher the confidence, the more true positives the rule may detect. |
| **Rule mode** | Filter by monitoring, commenting, or blocking rules in your Policies. |
| **Rule** | Filter by rules included in your Policies page. You can select more than one rule or ruleset for filtering. |
| **Ruleset** | Filter by the ruleset name where rules that match the code belong. More than one rule or ruleset can be selected for filtering. |
| **Pro findings only** | Filter for findings identified using Semgrep Pro rules. Also includes findings originating from cross-file or cross-function analysis. |
| **Code lifecycle** | Filter for findings based on whether they are **Production** findings or **Pre-production** findings. **Production** findings are those identified on primary branches, while **Pre-production** findings are those identified on pull request or merge requests. |
| **Project** | Filter for findings based on the tags associated with the project. |
| **Teams** | Filter for findings in projects owned by the selected teams. |
| **Multimodal file risk level** | Filter for findings based on Multimodal's assessment of risk level of files based on the type of code identified. High-risk files contain sensitive information, such as authorization and authentication details, while low-risk files may be things like test files. You can further filter by file type, such as **payments** or **tests**. |
| **Multimodal autotriage** | Filter by whether [Multimodal autotriage](/semgrep-multimodal/overview#auto-triage) has determined the finding to be a **True positive** or **False positive**. |
#### Finding categories
A finding can be categorized in two ways:
1. **Finding categorization based on the issue or code it detects**:
* Anti-patterns
* Security vulnerabilities, such as dangerous function usage
* Business or logic bugs
* Matches based on your own custom rules, such as organization-specific authentication logic
Semgrep rules provide a metadata schema to identify these common categories. Semgrep findings include a `message` field that describes the security issue or bug found in matching code. Additionally, findings can provide a `fix` field that fixes the issue by creating a suggestion within your source code management (SCM) tool, such as GitHub, GitLab, and Bitbucket.
2. **Finding categorization based on the validity of the match**:
* **True positive**: Rules are written to match a certain code pattern. A true positive is a genuine match. The rule is capturing the code as intended.
* **False positive**: A false positive is a mismatch between the intended purpose of the rule and the code it matched. A finding is generated but does not meet the rule's intended need. Rules with a high false positivity rate are said to be **noisy**.
* **False negative**: A false negative is a finding that should have been found by a rule, but was not. This can happen for two reasons:
1. A flaw in the rule's logic. See Reporting false negatives.
2. A bug within Semgrep itself. See the list of Semgrep issues to file a bug report.
## Group and sort findings
By default, Semgrep displays your findings using the **Group by Rule** view. This view shows your findings grouped by the rule Semgrep used to match the code. Your findings are shown sorted **by severity**, but you can opt to sort **by number of findings** for a given rule.
For a given severity, Semgrep further sorts findings as follows:
1. Findings generated by custom rules
2. Findings generated by [Pro rules](/semgrep-code/pro-rules)
3. Issue count in descending order
4. Findings ID in ascending order
To view findings individually, click **Group & sort > No grouping**. Findings are displayed based on the date they were found, with the most recent finding listed at the top.
## Export findings
You can export findings to a **CSV** file. Semgrep can export up to **10,000 most recent findings**. To export more than 10,000 findings, you must use the [API](/api-reference/Introduction).
Semgrep exports all findings to the CSV file regardless of the filters you apply on the page.
Export findings by navigating to the product page and clicking the ** icon** near the **Group & Sort** filters.
| Field | Description |
| :-------------------- | :---------------------------------------------------------------------------------------------------------------------------------------- |
| Id | The unique ID number of the finding. |
| Rule name | The name of the rule. |
| Product | The Semgrep product. Possible values are **Code**, **Code (AI)**, **Supply Chain**, or **Secrets**. |
| Severity | The finding's severity. Possible values are **Critical**, **High**, **Medium**, or **Low**. |
| Status | The finding's triage status. |
| Confidence | Filter by the likelihood of the rule to detect true positives. The higher the confidence, the more true positives the rule may detect. |
| Multimodal component | A descriptor, such as `API`, `Payments processing`, `Infrastructure`, that Multimodal tags the finding with, based on the code's context. |
| Repository name | The name of the repository where Semgrep found the finding. |
| Repository URL | The repository URL. |
| Line of code URL | The URL to the specific line of code where the finding match began. A finding may be several lines long. |
| Semgrep platform link | A link to the finding's **Details** page in Semgrep AppSec Platform. |
| Created at | The time the finding was created in your timezone. |
| Last Opened at | The time the finding was last opened. |
| Branch | The name of the branch where the finding was detected. |
| Triaged at | The most recent time that the finding was triaged. |
| Triage comment | A triage comment created by the user. |
| Triage reason | The reason why the finding was triaged, created by the user. |
| Rule description | The description of the rule. This is the same as the rule's `message` key. |
The following fields are exclusive to **Code** scans:
| Field | Description |
| :---------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Confidence | The finding's confidence. Possible values are **High**, **Medium**, or **Low**.
Only Semgrep Supply Chain and Code findings provide this field. |
| Category | The finding's category, such as **best practices**, **security**, or **correctness**. |
| Is pro rule | Boolean value that returns `TRUE` if the rule that generated the finding is a pro rule. |
| Assistant triage result | Provides Semgrep Multimodal's assessment. Possible values are `True positive` or `False positive`. These values appear only if Multimodal is enabled. |
| Assistant triage reason | A short AI-generated reason why Multimodal thinks the finding is a true or false positive. These values appear only if Multimodal is enabled. |
The following fields are exclusive to **Supply Chain** scans:
| Field | Description |
| :----------- | :--------------------------------------------------------------------------------------------------------------- |
| Dependency | The name of the dependency where the findings was found. |
| Reachability | The reachability status of the finding, such as **Reachable**, **No Reachability Analysis**, or **Unreachable**. |
| Transitivity | States whether the finding originates from a direct or transitive dependency. |
| CVE | The CVE number that the finding is assigned to. |
| EPSS | The EPSS score, which estimates the likelihood that a software vulnerability can be exploited in the wild. |
The following fields are exclusive to **Secrets** scans:
| Field | Description |
| :----------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Secret type | Possible values include **AI-detected**, **Generic secret**, **Connection URI**, and so on. |
| Validation | States whether or not the secret was validated. |
| Project visibility | States whether the project (repository) is public or private. This feature supports GitHub-hosted repositories only. It returns an **Unknown** value for non-GitHub SCMs. |
## View details about a specific finding
To view in-depth information about a specific finding, select the finding whose details you want to view. Then:
* If the default **Group by Rule** is enabled, click the **Details** icon on the card of the finding.
* If the **No grouping** view is enabled, click the **header hyperlink** on the card of the finding.
The finding's details page displays in-depth information about the finding. It also allows you to perform actions such as updating the finding's status as needed, viewing links to any integrations available, such as associated Jira tickets, and communicating with your team regarding the finding. For example, you can add notes to the finding that anyone with access to the finding can see. See [View findings' details](/semgrep-code/finding-details) for more information.
## How Semgrep displays findings on multiple branches
A **single** finding may appear in several branches. These appearances are called **instances** of a finding. Several instances of the same finding may differ in which line of code (LOC) they are on or in their triage state. For example, on `production` the finding may be on line 20, but the same finding was moved further to line 26 in `feature-branch-a`.
Semgrep automatically recognizes that they are fundamentally the same finding and deduplicates these instances so that you do not get an inflated count of findings per ref that the finding is present in.
By default, the Code page displays findings from the [primary branches](/deployment/primary-branch) of all repositories (projects), arranged by most recent scan. You are viewing the **primary branch's instance** of that finding, so you may see variations in LOC or triage state when comparing the finding across branches.
When filtering by primary branch and triage status, the filters are applied based on the **triage status of the finding on the primary branch**. This means that on some feature branches, the instance may already be **Fixed**, but on the primary branch, the finding is still **Open**. The finding status on the primary branch is updated when the PR or MR is merged and Semgrep has scanned the code.
**TIP**
* If you do not see any findings, or there are zero findings after a scan has concluded, check the **Projects** page to view the findings count, if any, and to set a [primary branch](/deployment/primary-branch), if it is not already set.
* The total count of findings in the **Projects** page is based on the **primary branch**.
## Next steps
* Learn more about [viewing a finding's details](/semgrep-code/finding-details).
* Learn how to [triage and remediate Semgrep Code findings](/semgrep-code/triage-remediation).
* Learn how to [get cross-file (interfile) findings for your organization](/semgrep-code/semgrep-pro-engine-intro)
* See [Semgrep Multimodal for Semgrep Code](/semgrep-multimodal/overview) for information on receiving AI-powered security recommendations when reviewing your findings.