Every security and quality tool has its own way of reporting what it found. One tool produces a JSON file. Another produces XML. A third produces a CSV. A fourth just prints to the terminal. The result, in most organizations, is a Tower of Babel problem: plenty of findings, no easy way to combine them, compare them over time, or feed them into the same dashboard.
SARIF was created to solve this problem. Understanding what SARIF is – and why it matters for AI agent governance – helps explain why Ethosure’s evidence is more useful than a pile of log files.
What SARIF is
SARIF stands for Static Analysis Results Interchange Format. It is an open standard (OASIS SARIF v2.1.0) that defines a single JSON schema for expressing the findings of any code-scanning, static analysis, or security checking tool.
Think of it as a standard shipping container for security findings. Just as ISO-standard containers let a ship from any country load cargo that any port crane can handle, SARIF lets a finding from any tool be displayed in any platform that understands SARIF – GitHub Advanced Security, Azure DevOps, Visual Studio Code, and many others.
A SARIF file contains:
- Rules: the checks that were run, each with an ID, name, and description.
- Results: the findings from those checks, each linked to a rule, a file location, a severity level, and a message.
- Metadata: which tool produced the findings, when, and under what configuration.
How coding-ethos uses SARIF
In the coding ethos project – Ethosure’s enforcement engine – SARIF is the primary format for enforcement findings. Every time the policy engine makes a decision that produces a finding (a BLOCK, a TRANSFORM with a note, an escalation record), the finding is emitted as a SARIF result.
Each SARIF result in coding-ethos carries richer metadata than a typical linter finding:
- Policy ID: the specific rule from the compiled policy bundle that fired.
- Principle IDs: the engineering principle(s) that own that policy (e.g., `security-by-design`, `one-path-for-critical-operations`).
- Skill ID: a pointer to the repair playbook relevant to this finding type.
- Source span: the exact file, line, and symbol where the finding applies, when available.
- Remediation payload: structured guidance on how to fix the issue.
- CEL/evaluator provenance: which evaluator produced the finding and how it was triggered.
- Fingerprint: a stable identifier that lets the same finding be recognized across different runs, enabling trend analysis.
This richness is what distinguishes a governance finding from a simple linter warning. The SARIF result is not just “something was wrong here.” It is a traceable record of which principle was violated, which policy enforced it, and what the repair path is.
SARIF in the CI pipeline
Because SARIF is a standard format, coding-ethos findings integrate naturally with CI/CD platforms. The project includes a dedicated workflow (`coding-ethos-sarif.yml`) that uploads SARIF results to GitHub’s code-scanning interface. This means:
- Findings appear inline in pull requests, with links to the relevant policies.
- Security teams can query findings across repositories through a single interface.
- Trend data accumulates automatically: which rules are firing more often, which files have persistent findings.
- The same findings feed both local developer feedback and CI-level enforcement.
For regulated organizations, this CI integration is significant. The code-scanning record is automatically created, versioned, and stored in the repository’s security tab – a persistent, queryable audit trail that does not require manual assembly.
SARIF and the MCP server
Agents interacting with Ethosure through the MCP server (the query interface for policy checks) can also consume SARIF. The MCP server exposes tools specifically for SARIF interpretation:
- `sarif_remediation_advice`: takes a SARIF result and returns structured repair guidance, linked to the relevant principle, policy, and skill.
- `sarif_risk_summary`: summarizes a set of SARIF findings into a triage view – which rules fired most, which files are most affected, what the next action should be.
- `sarif_trend_analysis`: compares two sets of SARIF results to identify which findings are new, which have been fixed, and which are persisting.
This means agents are not just subject to SARIF-based enforcement – they can also reason over SARIF evidence to guide their repair work, all through the same standardized format.
Why the standard matters for auditors
From an auditor’s perspective, SARIF evidence has two important properties that informal log files lack.
It is standard, not proprietary. An auditor or external reviewer does not need to understand Ethosure’s internal data model to read a SARIF file. The format is documented by an international standards body, understood by major CI platforms, and readable by standard tooling. The findings are portable.
It is structured, not narrative. Each finding has a rule ID, a severity, a location, and a message in a defined schema. That structure enables automated comparison, statistical reporting, and trend analysis across time. When a regulator asks “how many high-severity findings did your AI agents produce last quarter, and how many were remediated?” – a SARIF-backed system can answer that question programmatically.
The combination of SARIF findings, append-only JSONL events, and a queryable DuckDB store forms the evidence infrastructure that turns Ethosure from a runtime control into a compliance asset.
