SARIF Meets Sarif

Systems security is traditionally fractured. Developers spend their time resolving type errors and language-level compiler warnings. Security teams operate downstream, auditing codebases manually or running scanners (SAST, DAST, dependency checkers) long after code has been merged. These two worlds speak different languages: compilers emit plain-text diagnostics, while security platforms ingest structured formats to feed vulnerability databases and CI dashboards.

At NINJI, we believe this separation is a fundamental vulnerability. True systems safety requires a continuous, unified spectrum that runs from the compile-time type system to the production security assessment pipeline.

This publication outlines how we bridge this gap by connecting the Sarif compiler to NINJI’s security assessment workflow using standard interchange formats.

In this article, Sarif refers to NINJI’s systems language and compiler, while SARIF refers to the Static Analysis Results Interchange Format, the industry-standard JSON format for static analysis results.

The Traditional Disconnect

In standard systems programming, a memory safety warning or compile-time error is treated as a code quality defect, not a security finding. If a Rust or C++ compiler flags a potential lifetime mismatch or an unsafe reference, that diagnostic lives and dies in the terminal of the developer who wrote it.

When security teams run downstream audits, they rely on generic static analysis tools that lack deep semantic awareness of the language’s specific memory model. This leads to two critical failures:

1. High Triage Overhead: Analysts spend hours manually mapping compiler-level warnings to security risk categories (e.g., OWASP, CWE).
2. Delayed Remediation: Memory safety bugs that could have been resolved at compile time escape into production pipelines because the compiler lacked the capability to report them to security dashboards.

To solve this, we designed the Sarif compiler (sarifc) to emit assessment-grade diagnostics that can move through security review without losing semantic context.

Natively Emitting SARIF (Static Analysis Results Interchange Format)

By a coincidence of nomenclature, the Sarif systems language shares its name with the Static Analysis Results Interchange Format (SARIF), the OASIS standard for static analysis tool output. Rather than fighting this coincidence, we embraced it: sarifc natively supports SARIF JSON output.

In the Sarif compiler, diagnostic emission is a first-class feature. Using the command:

sarifc check main.sarif --format sarif

The compiler bypasses plain-text stderr rendering and outputs a standard SARIF JSON document. This payload captures compiler semantic diagnostics, mapping them directly to physical file locations, severity levels, and descriptive help instructions.

For example, when Sarif’s interprocedural escape analysis detects an arena-allocated reference escaping its structured with_arena { ... } block, it generates a standard SARIF JSON finding:

{
  "$schema": "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.5.json",
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "sarifc",
          "rules": []
        }
      },
      "results": [
        {
          "ruleId": "escape.analysis.required",
          "level": "error",
          "message": {
            "text": "function `build_tree` with `alloc` effect returns `Node` that may reference arena memory\n\nHelp: Stage-1 requires all returned values to be escape-safe. If the return value does not reference arena memory, remove the `alloc` effect."
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "src/main.sarif"
                },
                "region": {
                  "startLine": 12,
                  "startColumn": 1,
                  "endLine": 18,
                  "endColumn": 5
                }
              }
            }
          ]
        }
      ]
    }
  ]
}

By exporting compiler warnings directly to SARIF, language-level safety diagnostics immediately become ingestible security artifacts.

From Compiler Diagnostic to Assessment Evidence

A compiler diagnostic only becomes useful to an enterprise security team when it can be preserved, correlated, prioritized, and retested.

In NINJI assessments, Sarif projects can be evaluated as part of a broader software review. The assessment workflow preserves compiler context, normalizes findings into standard reporting formats, and gives analysts enough structure to connect language-level safety issues with operational risk.

This matters because most security programs fail at the handoff. A scanner finding may reach a dashboard, but the diagnostic often loses the compiler’s reason for raising it. A compiler warning may reach a developer, but it rarely enters the security evidence trail. SARIF gives both sides a common object to inspect.

The Impact: Continuous Security Feedback

This unified pipeline enforces systems safety at the earliest stage of the development lifecycle:

1. Gradual Strictness (Velocity vs. Safety): Developers can prototype quickly in the default Core profile, where escape analysis warnings act as helpful guidelines without halting compilation. When deploying to production or real-time environments, they switch to the RT profile, where these warnings are promoted to hard compile-time errors. This maintains developer velocity during exploration while enforcing compile-time memory safety in production.
2. Automated Enforcement: Under the RT profile, those escape errors block compilation. In CI/CD pipelines, these failures can be treated as blocking security issues rather than ordinary build noise.
3. Unified Evidence Trail: Systems architects and security analysts do not need to switch between compiler logs and scanner reports. A memory-safety diagnostic from Sarif’s interprocedural analysis can sit alongside other assessed findings with location, severity, and remediation context intact.
4. Retestable Remediation: The same diagnostic that identified the issue can be used to verify that the fix removes the unsafe behavior instead of merely suppressing a report.

Looking Forward

By integrating compiler-enforced safety with security assessment workflows, NINJI is laying the groundwork for a zero-trust systems development lifecycle. We are continuing to expand the depth of Sarif’s static checks and the rigor of our validation process.

Systems programming should not force developers to choose between compile-time velocity and post-deployment safety. The same evidence can serve both.

NINJI specializes in high-performance systems engineering and security analysis. We partner with organizations to design, audit, and harden critical infrastructure. Explore our services or contact our team to scope a project.