> ## Documentation Index > Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt > Use this file to discover all available pages before exploring further. # View findings in Semgrep AppSec Platform Semgrep Secrets generates a **finding** when a rule matches a piece of code in your codebase. You can use Semgrep AppSec Platform's [**Secrets** page](https://semgrep.dev/orgs/-/findings) to view all of the findings generated by Semgrep Secrets 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 **[Secrets](https://semgrep.dev/orgs/-/secrets)**. By default, Semgrep displays your **Priority** findings. Priority findings are defined as **valid** secrets with **critical** or **high** severity. You can switch to the **All** tab at any point to view all findings identified by Semgrep Secrets. Both the **Priority** findings view and the **All** findings view display high-level information about your findings. Each finding in the list includes information such as finding age, code location, project, branch, and validation status. **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 by default 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-secrets/findings#triage-statuses) for additional information. ### Severity The **Severity** filter allows you to view findings of particular severities. Secrets finding severity is derived from the corresponding rule severity, as is the case for other Semgrep findings. However, Semgrep Secrets rules may provide different severities based on validation state and environment. For example, an invalid secret may be assigned **Medium** severity, a valid secret for a sandbox environment may be assigned **High** severity, and a valid secret in a production environment may be assigned **Critical** severity. This reflects the different risk levels associated with each situation. Possible values: ### Additional filters Semgrep offers additional filters that you can use to narrow down your results. The following filters are available: | Filter | Description | | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Validation state** | Filter by [whether the secret is operative on the related service](#validation). Semgrep Secrets rules include validators, which can check whether the secret is valid for the service with which it is associated. | | **Secret** type | Filter by the type of secret, such as **private key**, or the web service that makes use of the secret, such as **Sendgrid** or **Stripe**. | | **Repository** visibility | Filter by whether the repository's [visibility](#repository-visibility) status. | | **Historical findings** | Filter for findings that are valid, leaked secrets in previous Git commits. | | **Project** tags | Filter for findings based on the tags associated with the project. | | **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**. | #### Triage statuses **Triage** is the prioritization of a finding based on policies or criteria set by your team or organization, such as severity, coding standards, business goals, and product goals. Semgrep AppSec Platform uses the logic specified in the table below to automatically mark findings as either fixed or removed when they are no longer present in the code. You can manually **Ignore** findings or set them as **To fix** or **Reviewing** in Semgrep AppSec Platform directly through **triage** or **bulk triage** actions. The triage statuses are as follows: | Status | Description | | :------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Open** | Findings 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. | | **Reviewing** | Indicates that the finding requires investigation to determine what the next steps in the triage process should be. | | **Provisionally ignored** | Findings where Semgrep has determined the secret to be **invalid**. The secret has been revoked, was never functional, or used for a custom or private endpoint that Semgrep can't communicate with. | | **To fix** | Findings that you have decided to fix. Commonly used to indicate that these findings are tracked in Jira or assigned to developers for further work. | | **Fixed** | Fixed 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. | | **Ignored** | Findings marked as ignored are present in the code but have been labeled unimportant. Ignore false positives or deprioritized issues. Mark findings as [ignored through Semgrep AppSec Platform](/semgrep-code/triage-remediation) or by adding a [nosemgrep code comment](/ignoring-files-folders-code/#reference-summary). You can also provide a reason for ignoring a finding: **False positive**, **Acceptable risk**, **No time to fix**. | | **Closed** | Vulnerabilities that are no longer detected after a scan. This can be due to changes in the underlying rule or the code. | #### Validation Refers to whether or not a secret is active and can be used to grant resources or authentication, or if a secret is inactive. * **Confirmed valid:** Semgrep made an HTTP request using the secret, and it returned an HTTP status code of 200 or similar **and** some indication of valid access. For example, a service can include a `"message": "ok"` in the response body. * **Confirmed invalid:** Semgrep made an HTTP request using the secret and it returned an HTTP status code of 401 or similar. * **Validation error:** Semgrep made an HTTP request using the secret, but either the network request could not be made, a timeout occurred, or the HTTP status code returned a different HTTP status code. In this case, the Semgrep Team recommends manually reviewing the finding. * **No Validator:** The rule does not have a validator. The Semgrep Team recommends manually reviewing the finding. #### Repository visibility Refers to whether or not the repository is a public repository or private. This is detected through your source code manager. | Repository visibility | Description | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Public | Repository access doesn't require authentication; at a minimum, it can be viewed by anyone. | | Private | Repository access requires authentication. | | Unknown | Semgrep Secrets is unable to detect your repository visibility. This is typically assigned to: | **INFO** Semgrep supports visibility detection only for GitHub repositories. ## 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. 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/v1/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-secrets/finding-details) for more information. ## Next steps * Learn more about [viewing a finding's details](/semgrep-secrets/finding-details). * Learn how to [triage and remediate Semgrep Code findings](/semgrep-secrets/triage-remediation).