Skip to main content
Filters enable targeted queries based on attributes such as severity, package ecosystems, dependency resolution, and platform source. This guide explains how filters work, how to apply and combine them effectively, and provides practical examples to support triage, audit, and reporting workflows across large codebases.

​
Access project filters

Perform the following steps to apply filters to the project list.
  1. Select Projects from the left sidebar.
  2. Filter your projects using the list of available filters in the filter bar.
  3. Toggle the Advanced option in the filter bar to apply API-style filters.
You can combine multiple filters to create more specific searches and narrow down the project list based on multiple criteria.

​
How filters work

Each filter consists of three parts.
  • Field: The attribute to be filtered (for example, Package Count and Platform Source).
  • Operator: The comparison logic (for example, equals, greater than, and in).
  • Value: The target value to evaluate (for example, npm and 100).
Project filters use standard comparison operators to evaluate criteria. See Filter operators for detailed information about available operators and their usage. When you apply multiple filters, the system combines them using logical AND operations across filters for different fields and logical OR operations across filters for the same field. For example:
  • Filter 1: Package Ecosystems contains: npm
  • Filter 2: Platform Source in: GitHub
  • Filter 3: Package Count: greater than 1
  • Filter 4: Reachability Analysis Status greater than or equal to: 90%
Multiple filters This combination returns only projects that use npm packages, are from GitHub, have more than one package, and have a reachability analysis status of at least 90%.

​
Filter implementation techniques

You can use the following filter types to manage your projects effectively.

​
Preset filters

The following examples demonstrate how to apply preset filters for common project scenarios.

​
Filter projects by custom tags

Use custom tags to filter projects based on environment or predefined labels assigned during project initialization or scan configuration. For example, to view only projects related to SAST, use the Custom Tags contains: sast filter. filter by custom tags

​
Filter projects by findings severity

Prioritize remediation efforts by filtering projects based on the severity of security findings. You can select from Critical (C), High (H), Medium (M), or Low (L) severity filters to target different priority levels. For example, to identify projects with critical findings, select the C filter. filter by severity

​
Filter projects by package ecosystem

Use package ecosystem filters to segment projects by programming language or package management system for targeted security policies such as stricter vulnerability thresholds for JavaScript projects or specific license compliance checks for Java applications. For example, to focus on PHP projects for a security assessment, use the Package Ecosystems contains: Packagist filter. filter by package ecosystem

​
Filter projects by source platform

Use platform source filters to segment projects by their source platform and correlate findings with platform-native security tools like GitHub’s Dependabot alerts or GitLab’s vulnerability scanning. For example, to identify projects analyzed from GitLab, use the Platform Source in: GitLab filter. filter by source platform

​
Filter projects by dependency resolution quality

Use dependency resolution status to identify projects with resolution issues that impact security analysis accuracy. You can filter by a single value or a range of percentages. For example, to identify projects with poor dependency resolution, use the Range filter to find projects with Dependency Resolution Status greater than 0% and less than 50%. filter by resolution

​
Filter projects by scan timestamp

Use last scanned filters to identify projects with stale security data that require fresh scans for current security posture. You can select from predefined time ranges or use the calendar to select a specific date. For example, to identify projects scanned within the last 24 hours, use the Last Scanned: Last Day filter. filter by last scanned

​
Filter projects by complexity

Identify projects based on their size and complexity, which may require different levels of security attention and resources. For example, to focus on large projects with extensive dependency trees, use the Package Count: greater than 100 filter. filter by complexity

​
Filter projects by reachability analysis status

Use reachability analysis status to identify projects based on the success rate of call graph generation and reachability analysis. You can filter by a single value or a range of percentages. For example, to identify projects with successful reachability analysis, use the Reachability Analysis Status greater than or equal to: 90% filter. filter by reachability status

​
Filter projects using API

For complex queries, use the advanced filter syntax to combine multiple attributes and apply logical operators. The following table lists the available attributes for project filters.

​
API filter use cases

The following examples demonstrate how to combine these attributes for common security and compliance workflows.
Find GitHub projects with more than 5 critical findings and a reachability analysis status below 80%.
spec.platform_source == "PLATFORM_SOURCE_GITHUB" and spec.finding_counts.critical > 5 and spec.package_coverage.call_graph_success_rate < 0.8
Identify projects not scanned in the last 7 days that still have outdated dependencies.
spec.last_scanned < now(-168h) and spec.dependency_counts.outdated > 0
Find projects where dependency resolution is below 90%, which may indicate incomplete security analysis.
spec.package_coverage.success_rate < 0.9
Identify projects with more than 100 total packages that also have a high number of critical vulnerabilities.
spec.package_coverage.total > 100 and spec.vulnerability_counts.total.critical > 20
Find projects where more than 50 findings have been dismissed, useful for auditing triage quality.
spec.finding_counts.dismissed > 50
Focus on npm projects with a high number of critical vulnerabilities.
spec.package_coverage.ecosystems contains ECOSYSTEM_NPM and spec.vulnerability_counts.total.critical > 10