This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Best practices: Working with dependency filters

Learn how to implement and use dependency filters to search, prioritize, and manage dependencies across your organization.

This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Learn how to implement and use dependency filters to search, prioritize, and manage dependencies across your organization.

Filters enable targeted queries on dependencies based on attributes such as ecosystem, reachability, direct versus transitive usage, severity, and Endor scores.

This guide explains how dependency filters work, how to apply and combine them effectively, and provides practical examples to support triage, audit, and reporting workflows across your dependency inventory.

Each filter consists of three parts.

  • Key: The attribute to be filtered (for example, Ecosystems, Dependency Reachability, and Direct ).
  • Operator: The comparison logic (for example, equals, in, and greater than ).
  • Value: The target value to evaluate (for example, Maven and Yes).

Dependency filters use standard comparison operators to evaluate criteria. See Filter operators for detailed information about available operators and their usage when using the API.

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: Ecosystems in: npm
  • Filter 2: Dependency Reachability: Potentially Reachable
  • Filter 3: Direct: Yes
  • Filter 4: Dependency Scopes: Normal
Multiple dependency filters applied

This combination returns only dependencies that are in the npm ecosystem, potentially reachable in your code, direct, and have normal scope.

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

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

Use the Projects filter to show only dependencies used by one or more selected projects. You can search by project name or tags, and click Add Filter.

For example, to view only dependencies used by a specific application, search by project name or tags

Filter by project

Use the Ecosystems filter to segment dependencies by package manager or language for targeted security policies, license compliance, or ecosystem-specific upgrade campaigns.

For example, to focus on Maven dependencies for a Java security assessment, use the Ecosystems in: Maven filter.

Filter by ecosystem

Use the Dependency Reachability filter to focus on dependencies that are reachable from your application code. Reachable dependencies are the ones that execute at runtime and increase your exposure to vulnerabilities. You can filter by Reachable, Potentially Reachable, or Unreachable dependency.

For example, to prioritize remediation of dependencies that may be used at runtime, use the Dependency Reachability: Potentially Reachable filter.

Filter by dependency reachability

Use the Dependency Scopes filter to separate production dependencies from those used only for testing or build-time tasks, so that you can target the right ones for policies and reports.

You can filter by:

  • Normal: Production dependencies consumed by the application at run time.
  • Test: Dependencies used only in test scope, such as test frameworks and test-only libraries.
  • Build: Dependencies used only at build or development time, such as compilers, build tools, or dev-only tools.

For example, to show only production dependencies, use the Dependency Scopes: Normal filter.

Filter by dependency scope

Use the Direct filter to distinguish between dependencies you declare explicitly in your manifests and those pulled in transitively.

For example, to view only direct dependencies, use the Direct: Yes filter.

Filter by direct

Use the Public filter to restrict results based on whether a dependency is resolved from a public package registry, such as npm, Maven Central, or PyPI, or from a private or internal source.

For example, to view only dependencies from public package sources, use the Public: Yes filter.

Filter by public

Use the Vendored filter to scope results by whether dependency artifacts are embedded in your repository, such as version-controlled source or shaded JARs, rather than resolved from a package registry.

For example, to exclude vendored artifacts from a license review, use the Vendored: No filter.

Filter by vendored

Use the Last Scanned filter to identify dependencies 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 dependencies scanned within the last 24 hours, use the Last Scanned: Last Day filter.

Filter by last scanned

Use the Released filter to focus on recently released dependency versions for upgrade planning or to track new releases. You can select from predefined time ranges or use the calendar to select a specific date.

For example, to find dependencies released in the last week, use the Released: Last Week filter.

Filter by release date

For complex queries, use the advanced filter syntax to combine multiple attributes and apply logical operators.

The following table lists the available attributes for dependency filters.

Title Key Description
Dependency Package Version Name meta.name Filters dependencies by the dependency package version name in the format ecosystem://package@version.
Parent UUID meta.parent_uuid Filters dependencies by the root package version UUID that declares or pulls in the dependency.
Importing Project UUID spec.importer_data.project_uuid Filters dependencies by the project that contains them. Use to list all dependencies for a given project.
Importing Package Version UUID spec.importer_data.package_version_uuid Filters dependencies by the root package version that declares or pulls in the dependency.
Importing Package Name spec.importer_data.package_name Filters dependencies by the qualified name of the importing package, without version.
Importing Package Version Name spec.importer_data.package_version_name Filters dependencies by the fully qualified name of the root package version.
Call Graph Available spec.importer_data.callgraph_available Filters by whether a call graph is available for the root package version.
Dependency Project UUID spec.dependency_data.project_uuid Filters by the project UUID to which the dependency package version belongs.
Dependency Package Version UUID spec.dependency_data.package_version_uuid Filters by the UUID of the dependency package version object.
Dependency Package Name spec.dependency_data.package_name Filters by the qualified dependency package name.
Ecosystem spec.dependency_data.ecosystem Filters by dependency ecosystem, such as npm, Maven, or PyPI.
Direct spec.dependency_data.direct Filters by whether the dependency is direct or transitive.
Reachability spec.dependency_data.reachable Filters by reachability status, such as reachable, potentially reachable, or unreachable.
Dependency Scope spec.dependency_data.scope Filters by dependency scope, such as Build, Normal, or Test.
Public spec.dependency_data.public Filters by whether the dependency is from a public or a private source.
Vendored spec.dependency_data.vendored Filters by whether the dependency is vendored or embedded in your repository.
Pinned spec.dependency_data.pinned Filters by whether the dependency version is pinned.
Patched spec.dependency_data.patched Filters by whether the dependency version has been patched.
End-of-Life spec.dependency_data.eol Filters by whether the dependency is end-of-life.
Last Commit spec.dependency_data.last_commit Filters by the date of the last commit or modification in the dependency version.
End-of-Life Timestamp spec.dependency_data.eol_timestamp Filters by the end-of-life timestamp of the dependency package version.
Namespace spec.dependency_data.namespace Filters by the namespace to which the dependency package version belongs.
Discovery Type spec.dependency_data.discovery_type Filters by how the dependency was discovered, such as manifest, phantom, or segment match.
Parent Count spec.dependency_data.parent_count Filters by the number of direct parents of the dependency in the dependency graph.

The following examples demonstrate how to combine these attributes for common security and compliance workflows.

Identify direct dependencies in a project

List only direct dependencies for a given project.

spec.importer_data.project_uuid==<project-uuid> and spec.dependency_data.direct==true
Find direct and reachable dependencies of a package version

Focus on direct dependencies of a root package version that are also reachable, for prioritization.

spec.importer_data.package_version_uuid==<package-version-uuid> and spec.dependency_data.direct==true and spec.dependency_data.reachable==REACHABILITY_TYPE_REACHABLE
Identify end-of-life dependencies in the namespace

Find dependencies that are end-of-life across the namespace for upgrade or replacement planning.

spec.dependency_data.eol==true
Find reachable npm dependencies in the namespace

Limit to npm dependencies that are reachable from application code, across the namespace.

spec.dependency_data.ecosystem==ECOSYSTEM_NPM and spec.dependency_data.reachable==REACHABILITY_TYPE_REACHABLE
Find non-vendored and public dependencies

Find all public and non-vendored dependencies across the namespace for license or supply-chain review.

spec.dependency_data.vendored==false and spec.dependency_data.public==true
Identify all patched dependencies in the namespace

Query across the namespace for dependencies that have a patch, without scoping by project.

spec.dependency_data.patched==true