Skip to content

Policy Rule Categories

When creating a new policy or updating a previous one, there are rule categories 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 categories 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.
  • Internet Reachability: Checks whether a component or resource is reachable from the internet. It's value is represented as Reachable.
  • Code Exposes: This action examines the composition of your application code, whether it exposes key components such as APIs, or the use of risky third-party libraries that may cause security breaches.
  • Dev Dependency: This action determines if a dependency is only used during development. It's corresponding values are Yes, Runtime, or Unknown.
  • 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.
  • Vulnerability Class: Checks for the class or category of a vulnerability, helping group and apply rules based on the nature of the security issue (e.g., XSS, Injection, etc.).
  • Personal Information: This action scans for personal information within your codebase, ensuring that sensitive data is not inadvertently exposed.
  • Vulnerable Code Reached: This action checks whether the vulnerable portion of the code is actually reachable at runtime.
  • 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.
  • Root Access: This action identifies cases where code, scripts, or containers are running with root-level permissions, which could introduce serious security risks if not controlled.
  • Forked Repo: This action determines whether a repository is a fork of another, which may impact trust level or review processes.
  • 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.
  • Data Access Reachability - This action evaluates whether sensitive data in your system is accessible based on code flow analysis. It helps identify potential pathways that might expose confidential information to unauthorized access.
  • Scanner: This action identifies the scanners used to check your codebase for vulnerabilities, ensuring that appropriate scanning tools are in place and configured correctly.
  • Secret Type: This action specifies the type of secret the rule checks for.
  • Secret Validity: This action checks for the validity of a secret if it is Valid, Invalid, or Unknown.
  • 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.
  • Priviledged User: This action targets findings associated with users or service accounts that have elevated privileges. It enables policy checks on access control risks or improper permission assignments.

Note

The Vulnerability ID and Vulnerability Identifiers attributes serve the same purpose (identifying vulnerabilities) but are tied to different data points in findings. It’s advised to consolidate usage where possible.