Outputs

fstab-decode — 5,480 bytes of x86 ELF from a Linux distribution — exports as a SARIF log carrying 26 results. Twenty-three are CVEs — twenty-one against glibc, two against the minimum kernel ABI the binary declares in its .note.ABI-tag — and every one is marked floor_only: unconfirmable. Two are build-posture facts about the whole image. Exactly one names an address inside the program's own code.

{
  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
  "version": "2.1.0",
  "runs": [{
    "tool": { "driver": {
      "name": "openbinary",
      "informationUri": "https://openbinary.ai",
      "version": "0.11.0", "semanticVersion": "0.11.0",
      "rules": [ /* 26 entries — one per rule that fired, and nothing else */ ]
    }},
    "artifacts": [{
      "location": { "uri": "002556361f8e06ec…" },
      "roles": ["analysisTarget"],
      "hashes": { "sha-256": "002556361f8e06ec5ff0761777bbe5283030eaab4ccee4c5ea6994147ff765fe" }
    }],
    "results": [
      {
        "ruleId": "command-exec.execvp",
        "level": "warning",
        "message": { "text": "Calls execvp(): PATH-search exec with array args. Same PATH-traversal exposure as execlp(); attacker control of PATH yields code execution." },
        "locations": [{ "physicalLocation": {
          "address": { "absoluteAddress": 1232, "kind": "function", "fullyQualifiedName": "sub_540" },
          "artifactLocation": { "uri": "002556361f8e06ec…" }
        }}],
        "properties": { "cwe_id": 78, "confidence": "medium",
                        "detector": "static-rule", "reachable_from_main": false }
      },
      {
        "ruleId": "CVE-2025-8058",
        "level": "warning",
        "message": { "text": "The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. …" },
        "locations": [{
          "logicalLocations": [{ "kind": "module", "name": "glibc 2.3.4" }],
          "physicalLocation": { "artifactLocation": { "uri": "002556361f8e06ec…" } }
        }],
        "properties": {
          "match_confidence": "floor_only", "kev": false,
          "cvss": { "version": "4.0", "base_score": 5.900000095367432,
                    "vector": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:H/SC:L/SI:L/SA:H" }
        }
      }
    ],
    "properties": { "tool_version": "0.11.0", "schema": "2.1.0", "arch": "x86" }
  }]
}

absoluteAddress is 1232 — 0x4d0 — while fullyQualifiedName is sub_540. They are unrelated addresses: 0x4d0 sits below .text, the PLT stub for execvp and the call target this detector family records, while sub_540 is the function that made the call, rendered sub_<hex> because it carries no symbol. A consumer that reads the name as a label for the address will mis-anchor, and what the address field means differs per family. glibc 2.3.4 is not the glibc this binary ran against either; it is the symbol-version floor recovered from the ELF's version requirements, and every CVE hanging off it is named-as-affected, not confirmed-as-vulnerable.

Every output is a projection of the stored analysis through one of three surfaces: a REST API, 48 MCP tools, and a SARIF 2.1.0 log. That analysis is not one row: the binary record, the CWE-findings slot, the threat assessment, the strings sidecar, and the functions and call-graph blobs are separate per-sha stores, fused at read time by whichever surface is asking.

The SARIF document

Every export is a single run with a single tool.driver named openbinary, whose version and semanticVersion are the exporter's own build — 0.11.0 above, the same string that stamps run.properties.tool_version, not the version of the engine that produced the analysis. The engine version sits on the stored record and is emitted nowhere in the log, so a binary analysed two engine releases ago still exports 0.11.0. SARIF 2.1.0 is what GitHub code scanning and DefectDojo already ingest, so an export lands in an existing queue rather than a new dashboard.

The analysed binary is a run.artifacts entry, never a result. The driver.rules catalog is derived from the results that survived, not from the rule set that could have fired, so every ruleId in the document resolves to a rule and no orphan rule is shipped.

Finding families and anchors

Five finding families project into that one run, each anchoring to a different kind of location:

Rule id collisions

Rules dedup on the pair (family, rule id), not on the id alone. A CWE rule literally named threat/something therefore does not silently merge into the threat namespace: whichever of the two colliding keys is emitted second takes a suffix naming its own family — #cwe here — and every result referencing it is rewritten to match. Inputs with no collision emit no suffix at all.

Severity levels

Each family maps onto SARIF's four levels — none, note, warning, error — differently:

Capabilities take note unconditionally: they record what the code can do, and grading them by severity would launder a capability into a verdict.

ATT&CK taxonomy

MITRE ATT&CK rides as a single run.taxonomies component, built from the union of techniques the surviving results referenced, so every result.taxa reference resolves. When nothing referenced a technique the component is omitted rather than emitted empty — the state of every log whose findings are all CWE and CVE, since neither family emits result.taxa even where the CWE registry entry has an ATT&CK mapping.

Result locations

Every result carries an artifactLocation.uri, because GitHub code scanning drops any result without one and a virtual address is not a path.

Synthetic uris for binary results

Every binary-anchored result on the per-binary route carries the sha256 as its uri, for every format. The builder prefers the basename — stripped of any / or \ prefix and percent-encoded down to a single RFC 3986 path segment, because a control byte or a CJK character in a display name fails the schema's uri-reference check and gets the whole log rejected — then falls back to the sha256, then to the literal binary. The name seed never resolves here: the record the exporter reads carries no top-level name, size, or format, all three nested under the fingerprint.

That same absence is why the log above has such a thin artifacts entry and run.properties:

The basename-and-percent-encode path does run on the two surfaces whose uris are real paths: source findings and package member paths.

What the address field means

absoluteAddress carries whatever value the producing detector recorded, and that is not one kind of thing:

A tool that maps absoluteAddress through a section table mis-places every secret result, because a byte offset and a VA differ by the section's load bias; the only in-band signal is that the secret family omits kind: "function" on the address object. On a stripped binary with no recovered call graph, a CWE result's fullyQualifiedName falls through to the callee primitive — the name reads strcpy or system, neither the enclosing function nor a function defined in this binary.

Source file paths

Source findings carry the real relative path plus a region, treated as strictly repo-relative because that path arrives from a symbol table or an archive entry name, both attacker-controlled. Every .., ., and empty segment is dropped and each survivor percent-encoded.

Taint witnesses

A finding carrying a taint witness also emits codeFlows — one threadFlow whose locations are the proven Source → Propagate → Sink steps in order, each an address with the step's role and symbol in its message. The primary location stays the sink. That is the same shape CodeQL and Semgrep ship, so a compliance buyer can diff them.

The witness is not SARIF-only: the same ordered address / role / symbol chain rides the finding on GET /binary/{sha} and the findings tool, so a consumer that never exports SARIF still gets the proof. Only taint detectors that retain a source anchor populate it — interprocedural summary detectors prove parameter-index reachability without recording a per-operation witness, and static-rule findings carry none at all.

Threat-ledger evidence

A threat-ledger row's detail text and matched-string evidence ride the free-text message and properties fields only — never a uri or helpUri — because they are baked from bytes the adversary chose. From such a row only the numeric virtual address, and a symbol name if one resolved, is lifted into a location.

Limits and truncation

Six limits bound an export, and each records separately what it dropped:

GitHub's twenty-runs-per-file limit is satisfied by construction — every export is exactly one run. The result cap is GitHub's too, and it is enforced continuously rather than at the end: the accumulator is a bounded keep-top-N heap holding at most 25,000 results at any moment, evicting the current worst on every push past the cap. Peak memory is a function of the cap, not of how many findings the binary produced. The eviction order is total and therefore reproducible — level descending, then rule id ascending, then insertion sequence — so two exports of the same analysis truncate to byte-identical documents.

A firmware image exports as one merged run with one artifacts entry per member and a global keep-top-N rather than a per-member share, so results compete on severity across the whole image instead of being rationed. Member results carry artifactLocation.index, the SARIF-standard disambiguator, so two members sharing an in-image path stay attributable; the single-binary path never sets it, which keeps its output byte-identical.

Selection into the 1,024 cap is a weaker guarantee than the eviction that follows it. Members are ranked on cheap signals only — the stored verdict label and the CVE rollup, no findings read — because reading every member's findings to decide which members to read is the cost the cap exists to avoid. A member with a quiet verdict and no CVEs but a large findings array is cut before its findings are ever looked at.

A package log's run.properties names both axes: package (sha256, name, kind), members_total, members_analyzed, members_projected, members_unanalyzed, members_omitted, members_failed, members_oversized, truncated_members. Members omitted by the 1,024 cap never fold into omitted_results, which counts evicted results only; truncated and omitted_results appear only when truncation actually happened.

Result confidence

Every CVE result carries its match_confidence, and the five tiers are ranked:

floor_only is not a defect being hidden — it is the alternative to fabricating a range_matched from a minimum. It is also the majority case for a distro ELF: 23 of fstab-decode's 26 results are floor_only, all inherited from a glibc 2.3.4 floor that the real deployed glibc almost certainly exceeds.

Reachability flags, capabilities, and threat rows each carry their own convention for what a missing or ungraded value means:

Threat-ledger rows fail low, not high: defaulting an ungraded row upward would rank unproven evidence above a recognised-but-weak band.

Output surfaces

The same analysis leaves through three surfaces, and every named output is a projection of the stored analysis record through one of them, not a route of its own:

The SARIF projector runs no analysis, opens no binary, and computes nothing new. It reads already-resolved, already-gated JSON.

Access control

The projector performs zero access control of its own; gating is inherited by composing the same read facades every other surface uses. Each route denies differently:

Static audit is grant-only: no plan tier clears it, Pro included. It sits with raw binary download, whole-binary reconstruction, corpus-wide statistics, and curator annotation in the set reachable only through a per-user grant an operator issues by hand. Two of the five SARIF families — CWE findings and secrets — are therefore absent from a paying Pro customer's log by default, and the CWE result opening this brief is reachable only by a grant-holding caller. One carve-out: on a deployment with no auth provider configured, the operator running the binary is the data owner, so every grant-only feature is on.

Projector dependencies

The projector depends on serde, serde_json, and thiserror — no analysis code, no storage, no typed finding model — and that last omission is load-bearing. The identifying fields of every finding family, rule ids and summaries and ATT&CK id lists, are interned strings that serialize out but round-trip back to empty through the analysis types. Re-reading the JSON through those types would silently blank every rule id in the export. Having no access to them makes that mistake unavailable.

The source SARIF route

/api/v1/source/{sha256}/sarif collapses every denial into one 404, a missing static-audit grant included, because on that route the gate result is itself the existence signal. Since shas are content-addressable, an attacker computes them from files they already hold; a 200-with-empty-log would answer "was this exact file uploaded and scanned by someone" at one request per candidate — a corpus-wide file-membership oracle. The uniform 404 closes it.

The query DSL

The corpus answers a compositional DSL whose identifiers are a hand-maintained subset of the indexed fields, not the display fields and not the index itself.

Those last nine are real indexed fields — most counted by the corpus-statistics endpoint, named_bp a sortable numeric, verdict additionally filterable through the search endpoint's own verdict parameter. They are absent because the DSL's field table is a separate hand-maintained list, not a view of the schema.

The queryable field set is versioned — schema 12 today — and the version is a wipe boundary, not a migration: adding a field bumps it and every existing index must be rebuilt before the new identifier answers anything.

Each field kind fixes its legal operators:

file_size > 100000 and platform == "FreeBSD"          → 67 binaries

The same expression rides the search endpoint's filter= parameter.

Per-binary outputs

One analysed binary yields the fields below. api marks a REST endpoint, mcp an MCP tool; an entry carrying neither is computed and consumed internally.

Identity and status

Description and provenance

Structure

System access

Network and libraries

Functions

Strings

Threats

Vulnerabilities

Lineage

Operations and lookups

Fields computed but never serialized

These products are computed during analysis and reach no surface:

Per-container outputs

A firmware image, package, or archive is a distinct record family: it is never one binary, and its outputs describe a tree.

Package detail

Firmware readout

One readout is computed over the unpack result and carried whole by the package-description tool. See Unpacking.

Extraction ledgers

Every extraction decision is recorded, including the negative ones.

The per-entry confidence scores and probe internals behind the identified-only ledger are collapsed into reason labels, and the full per-file extraction trace beyond the written and skip ledgers stays inside the unpack pipeline.

Curated packages and comparison

Corpus-wide outputs

Seven outputs operate over the whole corpus or a fleet rather than one artifact.

Reference

• SARIF 2.1.0 — the OASIS specification.
• SARIF support for code scanning — GitHub's ingest rules and the hard limits enforced above.
• Model Context Protocol — the tool-calling protocol behind the MCP surface.
• CycloneDX and SPDX — the two SBOM formats exported.