GHSA-7xjm-g8f4-rp26 Giskard has Unsandboxed Jinja2 Template Rendering in ConformityCheck

• PyPI giskard-checks: < 1.0.2b1 → fixed in 1.0.2b1

Summary The `ConformityCheck` class in `giskard-checks` rendered the `rule` parameter through Jinja2's default `Template()` constructor. Because the `rule` string is silently interpreted as a Jinja2 template, a developer may not realize that template expressions embedded in rule definitions are evaluated at runtime. In a scenario where check definitions are loaded from an untrusted source (e.g. a shared project file or externally contributed configuration), this could lead to arbitrary code execution. `giskard-checks` is a local developer testing library with no network-facing service. Check definitions, including the `rule` parameter, are provided in application code or project configuration files and executed locally. Exploitation requires write access to a check definition and subsequent execution of the test suite by a developer. However, the implicit template evaluation of the `rule` parameter is not obvious from the API surface. This hidden behavior increases the likelihood of a developer inadvertently passing untrusted input to it when integrating the library into a larger system. Affected Component `conformity.py`, line 59: ```python from jinja2 import Template ... formatted_rule = Template(self.rule).render(trace=trace) ``` Affected Versions `giskard-checks` = 1.0.2b1 (template parsing removed from rule evaluation entirely) Remediation Upgrade to `giskard-checks` >= 1.0.2b1. The template rendering has been removed from rule evaluation. Credit Giskard-AI thanks @dhabaleshwar for identifying the unsandboxed template usage.