What are action policies?

Learn about action policies in Endor Labs and how to use them.

An action policy defines the workflows that take place when a provided set of criteria is discovered.

Action policies are used to:

  1. To configure the behavior of scan in a CI/CD based environment.
  2. To set up custom ticketing workflows.
  3. To set up custom messaging workflows.

How to create an action policy from an Endor Labs template

You can create an action policy in Endor Labs to take recommended action when a rule is triggered.

  1. Sign in to Endor Labs, and select Policies from the left sidebar.

  2. Click Action Policies.

  3. Click Create Action Policy to create a new action policy.

  4. First, you must define a policy. Choose a policy template and define the criteria from which a policy action should occur. For more information, see Action policy templates.

  5. Next choose an action to take when the policy criteria are met.

    • Choose Enforce Policy to define the behavior of the Endor Labs CLI when a scan is run.

      • A Warn enforcement action will warn a user when a specific policy criteria is met by letting them know the specific findings that violate policy. Warn enforcement actions will only notify users of policy violations and will still return a 0 exit code in CI/CD environments, which will not fail a job.
      • A Break the Build enforcement action will return a non-zero (128) exit code for a CI/CD job and will fail the job. This action will inform a user about any findings that violate policy as part of the scan.
    • Choose Send Notification to create a ticket or send a custom message to an integrated notification system.

      • A notification target must be set to send a notification. Notification targets may be defined as a notification integration. For more information, see Endor Labs integrations.
      • Choose an Aggregation type for notifications. Choosing Project triggers a single notification for all findings, while choosing Dependency creates multiple notifications categorizing them based on dependencies. For more information, see Aggregation types for notifications.
  6. Choose a scope for which this action policy should apply. Scopes are defined by the tags assigned to a project after it has been successfully scanned.

    • In Inclusions, enter the tags of the projects that you want to scan.
    • In Exclusions, enter the tags of the projects that you do not want to scan. Exclusions take precedence over the inclusions, in case of a conflict.
    • Click the link to view the projects included in the finding policy.
  7. Name and describe your action policy.

    • Enter a human readable name for your action policy.
    • Enter a description to describe your action policy that can be used to easily understand what it does.
    • Enter any tags that you want to associate with your policy that can help you easily identify it.
  8. Optional: When you define a policy you do so for the current namespace the policy is created in. If you’d like to ensure that the policy is applied at the global level it must be created at the parent namespace of your tenant. To apply the policy to all child namespaces, click Advanced and select Propagate this policy to all child namespaces.

  9. Click Create Action Policy. The policy is created and is active by default.

Action policy templates

Endor Labs provides the following out-of-the-box finding policy templates that you can use to quickly create a policy.

Each policy template provides parameters to help you define under what conditions a policy action takes place.

  • Custom Finding Attributes - Allows you to define a custom action policy based on the attributes of the finding. The following parameters are supported:

    • Finding Category - Violate this policy only for a specific category of finding.
    • Include CI/CD findings - Select yes to violate this policy for CI/CD tools-related findings.
    • Finding Type - Violate this policy only for a specific type of finding. See Finding types
    • Severity - Violate this policy only for specific finding severities.
    • Fix Availability - Only violate this policy if a patch is available in the upstream dependency.
    • Dependency Reachability - Only violate this policy on findings where a vulnerable dependency is reachable.
    • Function Reachability - Only violate this policy on findings where the vulnerable function of a vulnerable dependency is reachable.
    • Exclude Test - Exclude test dependencies from this policy.
    • Source Code Ecosystem - Define a specific ecosystem for which an action policy should apply.
    • Finding Label - Only match findings with this label (set by the policy that created the finding)
    • Exclude if Dependency Name Contains - Allows you to define full or partial, case insensitive, dependency names for which an action policy should exclude. For example, you want to exclude a specific dependency from this policy.
    • Exclude if Package Name Contains - Allows you to define full or partial, case insensitive, package names for which an action policy should exclude. This is the resource that the finding is raised against. For example, the package indirectly or directly includes an unmaintained dependency.
    • Exclude findings for transitive dependencies via other projects? - Exclude findings for transitive dependencies that can only be reached via other projects. This helps your team to not take action when they do not have control of findings introduced by libraries your team developed.
  • Detected Secrets - Allows you to define the action taken when a leaked secret is detected based on the validation status of the secret.

  • Outdated Releases - Matches findings based on older versions of software or dependencies and are not actively updated. The following parameters are supported:

    • Dependency Reachability - Only violate this policy on findings where a vulnerable dependency is reachable.
    • Relationship - Allows you to define if a dependency should be exclude if it is a direct or transitive dependency.
    • Exclude if Dependency Name Contains - Allows you to define full or partial, case insensitive, dependency names for which an action policy should exclude. For example, you want to exclude a specific dependency from this policy.
    • Exclude if Package Name Contains - Allows you to define full or partial, case insensitive, package names for which an action policy should exclude. This is the resource that the finding is raised against. For example, the package indirectly or directly includes an unmaintained dependency.
    • Exclude findings for transitive dependencies via other projects? - Exclude findings for transitive dependencies that can only be reached via other projects. This helps your team to not take action when they do not have control of findings introduced by libraries your team developed.
    • Exclude Test - Exclude test dependencies from this policy.
    • Source Code Ecosystem - Define a specific ecosystem for which an action policy should apply.
  • Unmaintained dependencies - Matches findings based on dependencies that are no longer maintained or may have reached end-of-life. The following parameters are supported:

    • Dependency Reachability - Only violate this policy on findings where a vulnerable dependency is reachable.
    • Relationship - Allows you to define if a dependency should be excluded for direct or transitive dependencies.
    • Exclude if Dependency Name Contains - Allows you to define full or partial, case insensitive, dependency names for which an action policy should exclude. For example, you want to exclude a specific dependency from this policy.
    • Exclude if Package Name Contains - Allows you to define full or partial, case insensitive, package names for which an action policy should exclude. This is the resource that the finding is raised against. For example, the package indirectly or directly includes an unmaintained dependency.
    • Exclude findings for transitive dependencies via other projects? - Exclude findings for transitive dependencies that can only be reached via other projects. This helps your team to not take action when they do not have control of findings introduced by libraries your team developed.
    • Exclude Test - Exclude test dependencies from this policy.
    • Source Code Ecosystem - Define a specific ecosystem for which an action policy should apply.
  • Unpinned direct dependencies - Matches findings based on direct dependencies that do not have a version or a range of versions specified. Supported configuration parameters for this action policy template are:

    • Exclude if Dependency Name Contains - Allows you to define full or partial, case insensitive, dependency names for which an action policy should exclude. For example, you want to exclude a specific dependency from this policy.
    • Exclude if Package Name Contains - Allows you to define full or partial, case insensitive, package names for which an action policy should exclude. This is the resource that the finding is raised against. For example, the package indirectly or directly includes an unmaintained dependency.
    • Exclude findings for transitive dependencies via other projects? - Exclude findings for transitive dependencies that can only be reached via other projects. This helps your team to not take action when they do not have control of findings introduced by libraries your team developed.
    • Exclude Test - Exclude test dependencies from this policy.
    • Source Code Ecosystem - Define a specific ecosystem for which an action policy should apply
  • Unreachable direct dependencies - Matches findings based on dependencies that are not directly used or called within a project. Supported configuration parameters for this action policy template are:

    • Exclude if Dependency Name Contains - Allows you to define full or partial, case insensitive, dependency names for which an action policy should exclude. For example, you want to exclude a specific dependency from this policy.
    • Exclude if Package Name Contains - Allows you to define full or partial, case insensitive, package names for which an action policy should exclude. This is the resource that the finding is raised against. For example, the package indirectly or directly includes an unmaintained dependency.
    • Exclude findings for transitive dependencies via other projects? - Exclude findings for transitive dependencies that can only be reached via other projects. This helps your team to not take action when they do not have control of findings introduced by libraries your team developed.
    • Exclude Test - Exclude test dependencies from this policy.
    • Source Code Ecosystem - Define a specific ecosystem for which an action policy should apply
  • Vulnerabilities - Matches findings that are vulnerabilities that meet specific parameters. The following parameters are supported:

    • Dependency Reachability - Only violate this policy on findings where a vulnerable dependency is reachable.
    • Relationship - Allows you to define if a dependency should be exclude if it is a direct or transitive dependency.
    • Exclude if Dependency Name Contains - Allows you to define full or partial, case insensitive, dependency names for which an action policy should exclude. For example, you want to exclude a specific dependency from this policy.
    • Exclude if Package Name Contains - Allows you to define full or partial, case insensitive, package names for which an action policy should exclude. This is the resource that the finding is raised against.
    • Exclude findings for transitive dependencies via other projects? - Exclude findings for transitive dependencies that can only be reached via other projects. This helps your team to not take action when they do not have control of findings introduced by libraries your team developed.
    • Exclude Test - Exclude test dependencies from this policy.
    • Source Code Ecosystem - Define a specific ecosystem for which an action policy should apply.
    • Severity - Violate this policy only for specific finding severities.
    • Fix Availability - Only violate this policy if a patch is available in the upstream dependency
    • Function Reachability - Only violate this policy on findings where the vulnerable function of a vulnerable dependency is reachable.
    • EPSS Probability Threshold - Only match findings with an EPSS probability score equal to or higher than this threshold (0.00-1.00). The EPSS probability score represents the probability [0-1] of exploitation in the wild in the next 30 days following score publication.
    • EPSS Percentile Threshold - Only match findings with an EPSS percentile threshold equal to or higher than this threshold (0.00-100.00). The EPSS percentile threshold represents the percentile ranking among all vulnerabilities that a vulnerability will be exploited.

Finding types

Findings are classified into the following types when the packages scanned include:

  • Custom - Custom findings defined in custom policies.
  • Dependency With Low Activity Score - Low Endor activity score.
  • Dependency With Low Popularity Score - Low Endor popularity score.
  • Dependency With Low Quality Score - Low Endor quality score.
  • Dependency With Multiple Low Scores - More than one Low Endor Score.
  • Dependency With Very Low Activity Scores - Very low Endor activity score.
  • Dependency With Very Low Popularity Score - Very low Endor popularity score.
  • Dependency With Very Low Quality Score - Very low Endor quality score.
  • License Risk - Missing, unknown, restricted, or problematic licenses.
  • Malware Dependency - Known malicious dependencies reported by Open Source Vulnerabilities (OSV).
  • Malware OSS Review - Potentially suspicious code that need review.
  • Missing Source Code - Associated source code is not auditable.
  • Outdated Dependency - Outdated code with older versions of the released dependencies.
  • Typosquatted Dependency - Dependencies with intentionally similar names to popular packages.
  • Unmaintained Dependency - Unmaintained dependencies introducing vulnerabilities.
  • Unpinned Dependency - Variable version specifications of dependencies.
  • Unused Dependency - Unused dependencies in the code.

Aggregation types for notifications

Aggregation types for notifications streamline the organization and management of findings for efficient workflow. By default, all project findings are included in a single notification. With the option to select aggregation types, notifications can be tailored to specific criteria based on dependencies. This customization simplifies developer actions and enhances productivity.

Endor Labs enables you to choose the following notification aggregation types, each offering distinct benefits:

  • Project - (Default) Select Project to create a single notification for all project findings.

  • Dependency - Select Dependency to create separate notifications for each dependency in a project.

    Example: For Jira integration notifications, a parent ticket is created with the selected issue type, either Task or Bug. The parent ticket includes the project name. Each identified dependency is grouped under a dedicated sub-ticket. The sub-ticket includes both the project name and dependency name. Findings without any dependency are grouped in a separate sub-ticket. During future scans, the existing sub-ticket status is updated or resolved. If a new dependency is found, a new sub-ticket is created.

How to manage action policies

You can view, enable, clone disable, edit, or delete your Endor Labs action policies.

  • Sign in to Endor Labs and select Policies from the left sidebar.
  • Use the search bar to search for a policy.
  • Enable or disable a policy by using the toggle.
  • Select Hide Disabled to hide policies that are not enabled.
  • Use Finding Level to filter policies by Critical, High, Medium, or Low.
  • To delete a policy, click the vertical three dots and select Delete Policy.
  • To edit a policy, click on the vertical three dots and select Edit Policy.