support to evaluate CEL expression with the right scanner

[ashwiniag]

Each scanner (e.g., Trivy, Snyk, Grype) produces reports in different JSON structures. A CEL expression written for one scanner might not work for another due to differences in field names.
Example

Trivy JSON Structure

	{
	  "ArtifactName": "nginx:latest",
	  "Results": [
	    {
	      "Target": "nginx:latest",
	      "Vulnerabilities": [
	        {
	          "VulnerabilityID": "CVE-2023-1234",
	          "Severity": "CRITICAL"
	        }
	      ]
	    }
	  ]
	}
	

CEL Expression (Valid for Trivy)

report.Results.exists(r, r.Vulnerabilities.exists(v, v.Severity == 'CRITICAL'))
	

Snyk JSON Structure

	{
	  "vulnerabilities": [
	    {
	      "id": "CVE-2023-1234",
	      "severity": "critical"
	    }
	  ]
	}
	

CEL Expression (Valid for Snyk)

report.vulnerabilities.exists(v, v.severity == 'critical')

If it tries to evaluate the Trivy CEL expression against a Snyk report, it will fail because Results and Vulnerabilities don’t exist in Snyk's JSON. So, before evaluating a CEL expression, check if it matches the structure expected for that scanner. And have it plugable/extendable support.

[ashwiniag]

Notes for future doc: how v, r etc these character are rendered in CEL expression we pass
example

report.Results.exists(r, r.Vulnerabilities.exists(v, v.Severity == 'CRITICAL'|| v.Severity == 'HIGH'))

r represents each element in the Results array, v represents each element in the Vulnerabilities array of JSON struct we have. In this case its top of JSON report

array_field.exists(var_name, condition)

• array_field → Must be an array in JSON.
• var_name → Implicitly assigned by CEL to each item in the array.
• condition → The condition being evaluated.
  CEL executes as follows:
• Loop over report.Results
  → r is assigned to each result.
• Inside Results, loop over r.Vulnerabilities
  → v is assigned to each vulnerability.
• Evaluate the condition v.Severity == 'CRITICAL' || v.Severity == 'HIGH'
  If any vulnerability matches, the expression returns true.

r and v are CEL-defined variables and there could be more based on JSON

[ashwiniag]

Why do we need an approach that checks if CEL expression matches the structure expected for that scanner?

As of now can't standardize the JSON structure because there are many or at-least going to be numerous scanners, and incorporating a standard structure by rendering all such scanner generated report isn't scalable in long run. And its redundant work too. Until we brainstorm with much better solution the most feasible and minimalistic approach is just that^ i.e- before evaluating a CEL expression, check if it matches the structure expected for that scanner.
Because

• Avoids Misinterpretation & Failures simply put Prevents Incorrect Evaluations
  ex: Without scanner-specific validation, a Trivy-based CEL expression applied to a Snyk report will fail. Not yielding to what a user would want a liner issue to be created for.
• Explicit & Meaningful Errors
  Instead of failing silently or giving vague errors, provide clear messages when an expression doesn’t match the expected scanner format. And in next roll out a possible document link for referencing and exemplary expression for each scanner for kick start
• Scalable & Supports Extendability
  avoids hardcoded logic per scanner.
• Allows customization to users on CEL expression to their wants

[ashwiniag]

con:
This might add processing time on server as this get evaluated everytime by notifier.

[scriptnull]

This might add processing time on server as this get evaluated everytime by notifier.

Ideally we should validate these CEL expressions when the policy gets created - way before the eval time. That should help us avoid the processing time everytime we notify.