Skip to main content
Filters enable targeted queries on findings based on attributes such as severity, category, reachability, ecosystem, and policy status. This guide explains how finding filters work, how to apply and combine them effectively, and provides practical examples to support triage, audit, and reporting workflows across your finding inventory.

​
How filters work

Each filter consists of three parts.
  • Key: The attribute you want to filter (for example, Severity, Category, and Ecosystems).
  • Operator: The comparison logic (for example, equals, in, and contains).
  • Value: The target value to evaluate (for example, Critical and Vulnerability).
Finding filters use standard comparison operators to evaluate criteria. See Filter operators for detailed information about available operators and their usage when using the API.

​
Filter implementation techniques

You can use the following filter types to manage your findings effectively.
  • Basic filters: Use the filter bar in the Endor Labs user interface to quickly segment findings by common attributes.
  • Advanced filters: Use advanced filters to create powerful queries that drill deeper into the dataset to fetch results with a specific context.
  • Saved views: Save filters, columns, sort, and search as a reusable, personal or namespace-shared view.

​
Search for findings using basic filters

Use the following basic filters to search for information in your findings.
  • Finding Level: Limit results by finding severity level.
  • Dismissed: Include or exclude dismissed findings. See Filter dismissed findings to learn more about filtering dismissed findings.
  • Category: Choose from CI/CD, Malware, license risks, operational risks, RSPM, GitHub Actions, SAST, AI models, containers, secrets, security, supply chain, or vulnerability and view related findings.
  • Projects: Narrow findings by one or more project names.
  • Custom Tags: Narrow down the list based on custom tags.
  • Attributes: Narrow down the list based on a range of factors such as:
    • if a patch is available to fix the findings
    • if the vulnerable function is reachable
    • if the dependency is reachable
    • if the dependency originates from a current repository or a current tenant
    • if the dependency is a test dependency
    • if the dependency’s discovery type is manifest, phantom, or segment match
    • if the finding originates from itself, direct, or a transitive dependency
    • if the SAST finding is generated by the AI SAST detection agent
    • if AI SAST analysis has classified the SAST finding as a true positive or false positive
    • filter the findings by the Exploited tag from CISA KEV
    • filter the findings by the Warn or Break the Build options set in the action policy
  • EPSS Probability: Choose the Exploit Prediction Scoring System (EPSS) score range.
  • Ecosystems: Filter by language or ecosystem.
  • Location: Narrow findings by where they occur (for example, path or location in the repository).
  • Confidence: Narrow findings by detection confidence.
  • SAST Languages: Narrow SAST findings by programming language.
  • Container Layers: Narrow container findings by image layer.
  • Remediation: Narrow vulnerability findings by fix status.
    • Endor Patch Available: Filters findings where an Endor-provided patch is available to fix the vulnerability.
    • Recommended Upgrade Available: Filters findings where a recommended version upgrade is available.
  • All Time: Choose a time range.

​
Search for findings using advanced filters

For complex queries, use the advanced filter syntax to combine multiple attributes and apply logical operators. Toggle the Advanced option in the filter bar to enter API-style filter expressions directly in the Endor Labs application.
Search using the advanced filters applies to all the branches of a repository. You can retrieve results from any branch by specifying the relevant context ID or type. See View findings associated with a project for an example of scoping findings to a specific branch.
The Advanced Filters use the GetFinding API call to fetch results. The following table lists the available attributes for finding filters.

​
Interactive filter builder

​
API filter use cases

The following examples demonstrate how to combine these attributes for common security and compliance workflows.
Find critical and high-severity findings where a fix is available and the vulnerable function is reachable.
Identify vulnerability findings with an EPSS score greater than 10% to focus on issues most likely to be exploited in the wild.
Retrieve all active, non-dismissed vulnerability findings for a single project.
List all vulnerability findings from PyPI packages across the namespace.
List vulnerability findings whose affected Maven dependency has native scope provided. Normalized scope stays Normal. Gradle source scans and JVM binary scans always report compile, so this filter does not apply to them.
Review all dismissed findings across the namespace to verify exception policies are applied correctly.
Retrieve findings scoped to a specific branch or repository version by providing the context ID.
Find findings tied to CVEs in the CISA KEV database that have no available fix, to assess risk that you can’t remediate yet.
Surface the SAST findings that the AI SAST detection agent generated and AI analysis confirmed as true positives, so triage starts with the highest-confidence results.
Return only the SAST findings that static rules produced, with AI SAST findings filtered out.
Surface supply chain findings that affect only direct dependencies to prioritize the most actionable issues.

​
Saved views

A saved view captures the current state of the Findings table, including filters, search text, column visibility and order, sort, and aggregation, as a named view you can reapply later. Save a view for yourself, or share it with everyone in the namespace so your team works from the same curated results. Unlike a saved filter, which stores only a filter expression, a saved view stores the full table state. You need a role with write permission for saved views in the namespace to create, edit, or delete them. See Authorization roles to learn more about roles and permissions.

​
Save the current table state as a view

  1. Select Findings from the left sidebar.
  2. Apply the filters, search, columns, sort, and aggregation you want the view to capture.
  3. Click Save View in the table header.
  4. Enter a name in the View name field.
  5. Choose Personal to keep the view private, or Shared with namespace to make it visible to everyone in the namespace.
  6. Click Save.
If a saved view is already active, clicking Update View updates that view in place instead of creating a new view. To create a new view without changing the active one, select the arrow next to Save View, then select Save as new.

​
Apply a saved view

  1. Select Findings from the left sidebar.
  2. Select the current view name at the top of the Findings table.
  3. Select Saved Views to switch from the built-in views list.
  4. Select the view you want to apply.
Saved views also appear alongside the built-in views under Findings in the left sidebar.

​
Edit a saved view

You can edit a saved view you own, or a view shared with the namespace. Edit the table state that the view captures, or its name and visibility. Only the owner of a view can change its visibility. To update the table state that a view captures:
  1. Apply the saved view you want to edit.
  2. Change the filters, search text, columns, sort, or aggregation.
  3. Click Update View.
To change the name or visibility of a view:
  1. Select Findings from the left sidebar.
  2. Select the current view name at the top of the Findings table.
  3. Select Saved Views.
  4. Select the vertical three dots next to the view, then select Edit.
  5. Enter a new name in the View name field.
  6. Optionally, under Visibility, choose Personal or Shared with namespace.
  7. Click Save.
To edit the active view instead, select the arrow next to Update View in the table header, then select Edit.

​
Delete a saved view

You can delete a saved view you own, or a view shared with the namespace, from either the view picker or the table header.
  1. Select Findings from the left sidebar.
  2. Select the current view name at the top of the Findings table.
  3. Select Saved Views.
  4. Select the vertical three dots next to the view, then select Delete.
To delete the active view instead, select the arrow next to Update View in the table header, then select Delete.