The first time I saw a Mythos-class tool "analyze" an SBOM I thought the demo had glitched. A 14MB CycloneDX file went into the context window, the assistant produced a calm two-paragraph summary, and the findings list at the bottom had three entries. Three. The same SBOM, routed through Griffin AI, returned 412 components indexed by package URL, 1,847 transitive edges resolved, 34 components flagged against the vulnerability corpus, and a dependency depth histogram I could query interactively. Same input. Radically different epistemology. The difference wasn't intelligence. It was that one system ingested the SBOM as structured data and the other treated it as a long essay.
Why SBOM ingestion is not a reading comprehension task
An SBOM is a machine-readable inventory. Its value is in the edges, the hashes, the purls, the license identifiers, and the supplier metadata — fields designed for deterministic lookup, not narrative interpretation. When a pure-LLM tool reads an SBOM, it tokenizes the JSON or XML into a flat stream, and the model pattern-matches against that stream. It can tell you log4j-core appears in the document. It cannot tell you that log4j-core sits four hops below your service entrypoint through a chain that crosses two vendor boundaries, because that chain is an edge set, not a string. Griffin AI's ingestion pipeline parses the SBOM into a graph. Components become nodes keyed by purl. Dependencies become typed edges. License fields are normalized through the SPDX identifier table. Supplier entries are resolved against known vendor profiles. The LLM that sits above this structure is no longer reasoning about text — it's reasoning about a queryable inventory.
The ingestion boundary is where accuracy is decided
Every downstream claim a security tool makes rests on what it did at ingestion. If the ingestion step loses the distinction between a direct and a transitive dependency, no amount of downstream prose can recover it. If the ingestion step fails to deduplicate components that appear under two different supplier names, the vulnerability match rate drops silently. Mythos-class systems are forced to re-derive these facts every time a question is asked, because nothing persists between prompts except the raw text of the SBOM. Griffin AI persists the parsed graph. Ask it the same question an hour later and it walks the same edges. Ask it about a second SBOM and it joins both graphs along shared components, so a CVE that appears in one product surfaces automatically in every other product that shares the vulnerable transitive. That join is trivially hard for a graph engine and effectively impossible for a token stream.
What pure-LLM SBOM reading actually produces
I ran a controlled comparison last quarter. A 9MB CycloneDX SBOM for a Node.js monorepo, 1,203 components, 7 known-vulnerable transitives. Mythos was asked: "List the vulnerable components and their fix versions." The response was confident, cleanly formatted, and named six components. One was a hallucination — a package name that existed in the ecosystem but not in the SBOM. Two were real components but the fix versions were wrong by a minor release. One was a real component but Mythos flagged it against a CVE that had been withdrawn. Griffin AI, querying the same SBOM after structured ingestion, returned exactly seven components. Every purl matched a row in the SBOM. Every fix version matched the upstream advisory database. The response was less eloquent. It was also correct. The Mythos output would have passed a human skim test. It would have failed any automated downstream consumer.
Prose findings cannot feed automation
A security platform is not valuable because it writes good sentences. It is valuable because its findings can be consumed by a policy gate, a Jira ticket generator, a SARIF exporter, a compliance report. Griffin AI's SBOM ingestion produces structured findings — objects with severity, purl, CVE ID, fix version, reachability flag, and a citation back to the SBOM line. These objects feed into Safeguard's policy engine without a translation step. A Mythos-class output is a paragraph. To feed it into automation you need a second LLM pass to extract fields, and that second pass introduces its own error rate. Two stochastic steps stacked on top of each other degrade geometrically. Formal inventory in, formal findings out. Prose in, prose out. The architecture determines the ceiling.
The CycloneDX and SPDX field coverage gap
CycloneDX 1.5 and SPDX 2.3 define dozens of fields that a compliant parser must understand: hashes in multiple algorithms, external references, component scope, evidence arrays, VEX sections, lifecycle indicators, dependency relationships typed by kind. Griffin's parser exercises every one of these fields because each becomes a distinct property on the component node. A Mythos-class system does not have a parser — it has tokens — so it notices the fields that appear repeatedly and under-uses the ones that appear sparsely. The evidence array, which records which scanner found which component, is typically ignored entirely by prose-oriented tools. Griffin uses it to score confidence per component, so you can filter out components that were detected only by a single low-confidence scanner. That filter is impossible without structured ingestion.
How ingestion quality compounds over time
A single SBOM is a snapshot. The interesting question is how a platform handles a thousand SBOMs across two years. Griffin's ingested graph grows. Components that appear in multiple products become high-value nodes. Version-to-version diffs produce a time series. The engine can answer "which products added log4j-core between Q1 and Q3 of last year?" in a single graph traversal. A pure-LLM system cannot answer that question at all without re-reading every historical SBOM into context, which is prohibitive past a handful of files. The compounding value of structured ingestion is not visible on the first day of use. It is enormous by month six.
The measurable ceiling for Mythos-class SBOM reading
Benchmarks we ran against anonymized customer SBOMs show Mythos-class systems identifying between 31% and 58% of vulnerable components on first pass, with a hallucination rate of 4% to 11% depending on SBOM size. Griffin AI's structured ingestion pipeline returns the deterministic set — every component with a matching advisory is returned, zero fabricated components, subject only to the coverage of the underlying advisory database. These are not close numbers. They are architectural outcomes. You cannot prompt-engineer a pure-LLM tool into deterministic extraction of a 10,000-row graph, because the tool has no graph.
What to ask your current tool on Monday
Export a CycloneDX SBOM from your build. Ask your tool to return the full list of vulnerable components as JSON, with purl, CVE ID, and fix version per row. Count the rows. Validate each purl against the SBOM. Validate each CVE against NVD. Count the hallucinations. Count the missed components by comparing against grype or trivy run against the same SBOM. The delta between that ground truth and the tool's output is your honest accuracy number. Run it twice — once against Griffin, once against whatever Mythos-class product you're evaluating. The numbers will tell you which architecture deserves a place in your pipeline.
The takeaway
SBOM ingestion is a parser problem, not a language problem. Griffin AI treats it that way. Pure-LLM tools treat it as reading comprehension and accept the accuracy ceiling that choice imposes. When the audit clock starts, the question your team will face is not "did the tool sound smart?" but "can we point to a row in the SBOM that produced this finding?" Only one of these architectures can answer yes. Choose accordingly.