Define SARIF Mapping for OpenPAKT Findings

[meisterware-admin]

Overview

Define how OpenPAKT findings can be mapped to SARIF (Static Analysis Results Interchange Format).

SARIF is a widely adopted standard used by security and static analysis tools for reporting findings in CI systems and developer security dashboards.

This proposal explores how OpenPAKT findings can be represented in SARIF so that OpenPAKT-compatible scanners and tools can integrate with existing DevSecOps ecosystems.

The goal is to enable OpenPAKT findings to appear in standard code scanning dashboards without losing OpenPAKT semantics.

---

Motivation

Many CI platforms and security tools already support SARIF as the primary format for ingesting security findings.

Examples include:

• GitHub Code Scanning
• GitHub Advanced Security
• Azure DevOps security dashboards
• GitLab security reports
• various SAST/DAST tools

Without a SARIF mapping, OpenPAKT findings cannot easily integrate with these systems.

Providing a SARIF mapping enables:

• visualization of OpenPAKT findings in existing security dashboards
• integration with existing DevSecOps workflows
• easier adoption by organizations already using SARIF-based pipelines
• interoperability with security analysis tooling ecosystems

This capability becomes especially important as OpenPAKT scanners such as Detektor begin to integrate with CI pipelines.

The current OpenPAKT v0.1 specification explicitly leaves SARIF interoperability out of scope for the core model.

Therefore this mapping is proposed as part of Milestone v0.2 – Ecosystem Integration.

---

Proposed Approach

Define an informational specification section describing how OpenPAKT reports can be translated into SARIF.

The mapping would define how the following OpenPAKT elements correspond to SARIF structures.

Example conceptual mapping

OpenPAKT field	SARIF field
finding.id	result.ruleId
finding.type	rule.id or result.ruleId
finding.severity	result.level
finding.description	result.message.text
finding.component	result.locations
finding.evidence	result.codeFlows or result.relatedLocations

Example simplified mapping:

OpenPAKT finding
 ↓
SARIF result

Example SARIF result sketch

{
  "ruleId": "prompt_injection",
  "level": "error",
  "message": {
    "text": "Untrusted input was inserted directly into a privileged agent prompt."
  },
  "locations": [
    {
      "physicalLocation": {
        "artifactLocation": {
          "uri": "ci/agent-review-workflow.yaml"
        },
        "region": {
          "startLine": 42
        }
      }
    }
  ]
}

Severity mapping guidance may also be defined.

Example:

OpenPAKT	SARIF
critical	error
high	error
medium	warning
low	note
informational	note

The specification should clarify that:

• SARIF export is derived output, not the canonical OpenPAKT representation.
• OpenPAKT reports remain the source-of-truth security artifact.

---

Alternatives Considered

Do nothing

Tools could independently implement SARIF export without a standard mapping.

However, this risks fragmentation and inconsistent interpretations of OpenPAKT findings.

---

Make SARIF the primary report format

OpenPAKT could theoretically use SARIF directly.

However SARIF is designed for general static analysis, whereas OpenPAKT models AI agent security findings and scenarios.

Keeping OpenPAKT as the canonical format preserves domain-specific semantics.

---

Provide vendor-specific SARIF exporters

Individual scanners could implement their own SARIF exporters.

This approach still benefits from a shared mapping guideline to preserve interoperability.

---

Risks and Trade-offs

Mapping fidelity loss

Some OpenPAKT concepts may not map perfectly to SARIF structures.

Care must be taken to preserve semantics when possible.

---

Ecosystem expectations

Once a SARIF mapping exists, users may expect full compatibility with all SARIF tooling.

This may require ongoing compatibility validation.

---

Specification complexity

Adding mapping documentation increases specification scope.

To mitigate this, the SARIF mapping should remain informational guidance, not a normative requirement.

---

Open Questions

• Should SARIF mapping be part of the OpenPAKT specification or a separate companion document?
• Should SARIF export be considered normative or informational?
• Should the mapping define mandatory severity conversion rules?
• Should SARIF mapping include scenario execution results in addition to findings?

---

Examples

Example OpenPAKT finding:

{
  "id": "OPKT-2026-0001",
  "type": "prompt_injection",
  "severity": "high",
  "component": "steps.review_prompt",
  "description": "Untrusted task content is inserted directly into the agent prompt."
}

Example OpenPAKT report snippet:

Example SARIF equivalent:

{
  "ruleId": "prompt_injection",
  "level": "error",
  "message": {
    "text": "Untrusted task content is inserted directly into the agent prompt."
  }
}

---

Next Steps

If this proposal gains support:

1. Draft the SARIF mapping specification section.
2. Define canonical OpenPAKT → SARIF field mappings.
3. Provide example SARIF exports.
4. Validate compatibility with common SARIF tooling.
5. Optionally prototype SARIF export in the Detektor CLI.