Skip to content

Rule engine

Sometimes the result of a scanner doesn't fit to the product's needs. Either the severity or the status need to be adjusted. To avoid having to do many manual assessments regularly, a built-in rule engine can adjust severity and/or status directly with the import of observations.

This can remove a lot of noise, for example by setting observations to False positive, in case the ruleset of the scanner can not be adjusted appropriately.

General rules vs. product rules

Rules

Rules can be managed in two ways:

  • General rules will be applied for all products. A product can be excluded from general rules in its settings.
  • Product rules are only valid for one product or for all products of a product group.

A rule itself can be defined in two ways:

Field rules

The fields New severity and New status set amended values in the observation.

The other fields are used to decide if a rule shall be applied for an observation:

  • Parser (optional): The observation has been imported with this parser.

  • Scanner prefix (optional): The observation has been generated by a scanner which name starts with this prefix. A prefix is used here because the scanner field in the observation often contains the version of the scanner as well, which is typically irrelevant for the rule.

    Either Parser or Scanner prefix need to be set.

  • Observation title (optional): Regular expression to match the observation's title

  • Component name:version (optional): Regular expression to match the component name:version
  • Docker image name:tag (optional): Regular expression to match the docker image name:tag
  • Endpoint URL (optional): Regular expression to match the endpoint URL
  • Service name (optional): Regular expression to match the service name
  • Source file (optional): Regular expression to match the source file
  • Cloud qualified resource (optional): Regular expression to match the cloud qualified resource, which is the concatenation of account (AWS) or subscription (Azure) or project (GCP) with the resource
  • Kubernetes qualified resource (optional): Regular expression to match the Kubernetes qualified resource, which is the concatenation of cluster, namespace and resource name.

If an observation matches all fields containing a value, than the new severity and/or new status is set in the observation and the rule's description is stored as a comment in the Observation Log.

Rego rules

Rego rules use the OPA policy language Rego to specify the content of the rule.

The rule gets the whole Observation as input and can set these values, to be changed in the Observation:

  • severity
  • status
  • priority
  • vex_justification

An example for a Rego rule looks like this:

package rule

# Status check using set membership
has_open_or_in_review_status if input.current_status in ["Open", "In review"]

# Helper for EPSS check (handles both missing and < 95)
low_epss if input.epss_percentile < 95
low_epss if not input.epss_percentile

# Common base conditions
valid_vulnerability if {
    has_open_or_in_review_status
    input.vulnerability_id
}

# Priority 4: Critical severity, low EPSS, no CVE found
priority := 4 if {
    valid_vulnerability
    input.current_severity == "Critical"
    low_epss
    not input.cve_found_in
}

# Priority 3: PoC on GitHub, low EPSS
priority := 3 if {
    valid_vulnerability
    low_epss
    input.cve_found_in == "PoC GitHub"
}

# Priority 2: High EPSS but no known exploits
priority := 2 if {
    valid_vulnerability
    input.epss_percentile >= 95
    not contains(input.cve_found_in, "Exploit-DB")
    not contains(input.cve_found_in, "Metasploit")
    not contains(input.cve_found_in, "Nuclei")
    not contains(input.cve_found_in, "VulnCheck KEV")
}

# Priority 1: Known exploits in major databases
exploit_sources := ["Exploit-DB", "Metasploit", "Nuclei", "VulnCheck KEV"]

priority := 1 if {
    valid_vulnerability
    some source in exploit_sources
    contains(input.cve_found_in, source)
}

# Status update
status := "In review" if {
    valid_vulnerability
    priority <= 4
}

Simulation

Rules can be simulated from the list of rules or when showing a single rule. The simulation produces a list of up to a 100 observations with their current values, that would be altered by the rule.

Approvals

With the default settings of the product, the rule will be activated right away if enabled. If more control is needed, an approval can be configured:

  • For General rules the feature General rules need approval can be set in the Settings.
  • For Product rules the setting Rules need approval can be set while creating or editing a product. The setting is also available for product groups. If it is set for a product group, it will be inherited by all products in that group.

If the approval is required, the dialog showing the rule will show a button to either approve or reject the assessment:

Show rule

Be aware, that the user who has created or edited the rule is not allowed to approve or reject it. The approval must be done by another user.

Rule approval