CEL Expression Reference for VEX Rules#

A VEX rule matches vulnerabilities using CEL (Common Expression Language). An expression must evaluate to a boolean: true means the rule applies to that vulnerability. This page documents everything the expression environment provides.

The environment at a glance#

The environment is deliberately small:

• exactly one variable: vuln
• three DevGuard-specific functions: matchesPattern, matchesPurl, and now — only the first two return a boolean on their own
• the standard CEL operators: ==, !=, <, <=, >, >=, &&, ||, !, in, ?:
• CEL's built-in date/time support: timestamp(string), duration(string), and arithmetic/comparison between the two — see Working with timestamps below

The editor checks two things as you type. First, that the expression parses. Second, that it evaluates to a boolean — a bare field access like vuln.cveId is a string and is rejected with Expression must evaluate to a bool, e.g. via ==, !=, matchesPattern(...) or matchesPurl(...). Wrap it in a comparison.

Lines beginning with // are comments and are skipped. Every other line is checked as an expression in its own right, which is why the rules DevGuard pre-fills for you put their explanatory comment on a separate line above the expression.

The vuln variable#

vuln is the dependency vulnerability being evaluated. The editor's autocomplete offers these fields — type vuln. to see them:

CVE details: vuln.cve#

Type vuln.cve. for these:

Risk metrics: vuln.cve.risk#

Type vuln.cve.risk. for these:

matchesPattern(vuln, pattern)#

Matches the vulnerability's dependency path. This is the function you want whenever the decision depends on how a package enters your product rather than which package it is.

The first argument is always vuln itself (the function reads vulnerabilityPath and artifactPurls from it). The second is a list of strings, each being either a purl or one of two special tokens.

Matching semantics#

By default a pattern is matched as a suffix of the dependency path. The pattern ["pkg:npm/a@1.0.0", "pkg:npm/b@2.0.0"] matches any path that ends with a → b, regardless of what comes before.

If the pattern's first element identifies one of the repository's artifacts, that element is consumed and the remainder is matched anchored from the start of the path instead. This is what lets DevGuard's own CSAF and CycloneDX exports round-trip cleanly back into rules.

Individual elements match by exact purl string first; failing that, the pattern element's version is interpreted as a semver constraint (see the caveat below).

matchesPurl(purl, constraint)#

Matches a purl against a version constraint — for dismissing a whole version range rather than one exact version.

The type, namespace and name must be exactly equal. Only the version part is treated as a constraint, using Masterminds semver syntax:

Working with timestamps#

Timestamp fields such as vuln.lastStateChange are exposed as RFC3339 strings, not CEL's native timestamp type. Wrap a field in timestamp(...) to compare it, and use now() to get the current time:

Subtracting one timestamp from another yields a duration, which is what makes the age check above possible. Timestamps and durations also support <, <=, >, >=, == directly against each other, and +/- between a timestamp and a duration.

Cookbook#

Dismiss one advisory everywhere#

Dismiss one exact component version#

Use this form — not matchesPurl — for Debian, Alpine and other non-semver ecosystems:

Dismiss a version range#

Dismiss one advisory only along one dependency path#

The most precise form, and the one the path graph generates for you:

The leading "*" is here only for readability — it makes the pattern read as "any ancestors, then this path". Since matching is suffix-based by default, omitting it matches exactly the same vulnerabilities.

Dismiss an advisory only when it arrives through a direct dependency#

Accept everything below a CVSS threshold#

Accept low-severity findings that are also unlikely to be exploited#

Accept risk and False positive rules only re-evaluate against open vulnerabilities. A rule like this dismisses a finding once, but it will not reopen it later if the EPSS score subsequently rises above the threshold — you'd need a matching Reopen rule for that (see below) and is why "accept" rules are less common than "dismiss" rules.

Reopen once a fix is available#

A Reopen rule is the mirror image: it only re-evaluates against vulnerabilities currently accepted as a known risk, twice a day, and reopens the ones it matches. Combine it with the fixed-version fields to reopen a risk you accepted only because there was nothing to fix yet:

componentFixedVersion and directDependencyFixedVersion are populated by the same analysis behind the finding's Quickfix suggestion — see Transitive Vulnerability Path Analysis: The Quickfix Algorithm for how DevGuard resolves them.

See Reopen a VEX Rule for how to create one.

Scope a rule to one branch#

Dismiss any of several advisories in the same component#

Reopen a finding accepted more than 30 days ago#

See Reopen a stale accepted risk for how to turn this into a Reopen rule.

Related Documentation#

• Create & Manage VEX Rules — where these expressions are used
• Choose a Mechanical Justification — the decision that accompanies the match
• Transitive Dependencies — how DevGuard builds the dependency paths that matchesPattern matches
• Vulnerability Matching — how purls are normalized before matching
• Risk Assessment Methodology — what the risk and priority fields mean
• Transitive Vulnerability Path Analysis: The Quickfix Algorithm — how componentFixedVersion and directDependencyFixedVersion are resolved