Define CI policy evaluation semantics

[meisterware-admin]

Problem

CI systems must deterministically decide whether a build passes or fails based on security findings produced by scanners.

Without standardized evaluation semantics, different tools may interpret findings differently in CI pipelines.
For example:

• some tools fail builds on any finding
• others fail only on specific severity levels
• others require custom scripting to enforce policies

This inconsistency prevents security findings from being reliably enforced across CI systems.

---

Proposed Change

Define CI policy evaluation semantics for OpenPAKT findings.

Policies should operate on the normalized finding structure defined by the OpenPAKT specification (taxonomy + severity).

CI policies should support rules such as:

• failing a build when findings exceed a severity threshold
• failing on specific finding types
• ignoring specific finding categories
• allowing vendor extensions without breaking evaluation logic

Evaluation should be deterministic and tool-independent, ensuring that any OpenPAKT-compatible tool produces the same CI result.

---

Examples

Example OpenPAKT finding:

type: prompt_injection
severity: high

Example CI policy:

fail-on: high
ignore:
  - informational

Example evaluation behavior:

Severity	Result
critical	fail build
high	fail build
medium	warning
low	informational
informational	ignored

---

Considerations

The policy model should:

• support deterministic CI gating
• integrate with existing CI systems (GitHub Actions, GitLab CI, Azure Pipelines)
• remain compatible with SARIF and other security reporting formats
• allow policy configuration without modifying scanner logic

---

Impact

Standardised CI policy semantics enable:

• deterministic security enforcement in CI pipelines
• consistent behavior across different scanners
• easier integration into DevSecOps workflows
• portable security policies across projects and organizations