Skip to content

Policy Action Paths

When creating a new policy or updating a previous one, there are action paths you can define when you add rules to the policy. Actions help you to define triggers and responses for findings under this rule.

Note

A policy without rules falls back to the default action. You can add rules to the policy to define customized rules with advanced filter conditions for findings.

These action paths for your policy include:

  • OpenSSF Score: This action checks for OpenSSF. OpenSSF Score is a collection of security health metrics for open source, allowing users to evaluate the security practices of an open source package in your codebase.
  • EPSS Score: This can be used to target EPSS in your code. EPSS (Exploit Prediction Scoring System) measures how likely a particular vulnerability will be exploited.
  • CVSS Score: CVSS generates a score from 0 to 10 based on the severity of a vulnerability.
  • Vulnerability ID: This action checks for the vulnerability via its id in your code.
  • Confidence: This action would check for scenarios where the confidence level of a vulnerability is high, medium, or low.

  • Severity: This action would check for severity of findings in Critical, Warning, or Minor states.

  • Access: This action checks the access control settings of your codebase, ensuring that only authorized users have access to sensitive areas of your project.

  • Application Composition: This action examines the composition of your application, including the use of third-party libraries and frameworks, to identify potential security risks.
  • Dependency Scope: This action reviews the scope of dependencies in your codebase, identifying any that are unnecessary or pose security risks.
  • Kubernetes Cluster: This action checks the configuration and security of your Kubernetes clusters, ensuring they are set up securely and following best practices.
  • Kubernetes Service: This action assesses the configuration and security of your Kubernetes services, ensuring they are properly configured and secured.
  • Label: This action checks for the presence of specific labels within your repositories, which can be used for categorization and policy enforcement.
  • Personal Information: This action scans for personal information within your codebase, ensuring that sensitive data is not inadvertently exposed.
  • Reachability: This action assesses the reachability of different parts of your codebase, identifying any exposed endpoints or services that should be secured.
  • Repository Flag: This action checks for specific flags within your repositories, which can indicate certain conditions or states that need to be addressed.
  • Repository Labels: This action reviews the labels assigned to your repositories, ensuring they are correctly labeled for policy enforcement and management.
  • Repository Languages: This action identifies the programming languages used within your repositories, helping to enforce language-specific security policies.
  • Repository Origin: This action checks the origin of your repositories, ensuring that they come from trusted sources and are not potentially compromised.
  • Repository Visibility: This action reviews the visibility settings of your repositories, ensuring they are appropriately set to public or private based on your security policies.
  • Scanner: This action identifies the scanners used to check your codebase for vulnerabilities, ensuring that appropriate scanning tools are in place and configured correctly.
  • States: This action reviews the various states of findings and vulnerabilities within your codebase, such as open, fixed, or ignored.
  • Transitive Vulnerabilities: This action checks for vulnerabilities that are inherited from dependencies of your dependencies, ensuring a thorough assessment of your codebase's security.
  • Vulnerability Identifiers: This action reviews specific identifiers associated with vulnerabilities in your codebase, ensuring that all known issues are tracked and addressed.