CycloneDX 1.5 is the most semantically dense SBOM format in production use. It defines typed components, multi-algorithm hashes, evidence arrays, VEX sections, ML-BOM extensions, lifecycle metadata, and a dependency graph that distinguishes runtime from build-time edges. The spec is the length of a short novel, and every field exists because somebody, at some point, needed to know that specific fact during an incident. The question I keep asking security teams evaluating AI tools is simple: does your tool actually read those fields, or does it pattern-match against a tokenized blob? Griffin AI does the former. Every Mythos-class tool I've tested does the latter. The output quality gap that follows is not subtle.
The CycloneDX surface that actually matters
A CycloneDX document is not just a list of components. It is, at minimum, a six-part structure: metadata (tooling, timestamps, supplier), components (with nested subcomponents, pedigree, and evidence), services (API surfaces and data flows), dependencies (typed edges), compositions (aggregates with completeness claims), and vulnerabilities or VEX statements. A well-formed document for a medium application will exercise all six. A Mythos-class tool reading this file flattens it into a token stream where the only signal it can reliably extract is the component names. Griffin AI's parser produces a typed object graph where each of those six sections is a first-class query surface. You can ask "show me every service with a data classification of PII" and get an answer. A token-based tool cannot, because "service" and "dataClassification" are not entities in its representation — they are just more words.
Why pedigree fields decide provenance questions
The pedigree section of a CycloneDX component records where the component came from — its ancestors, descendants, variants, commits, and patches. This field is how you distinguish a vendored fork from the upstream package, how you tell whether a component has been modified, and how you trace a supply chain back through rebuilds. Griffin AI uses pedigree as part of its provenance scoring: a component with no pedigree gets a lower confidence score than one with a full ancestor chain. A Mythos-class tool typically does not notice the pedigree section exists unless it happens to contain strings that look like CVE matches. When a supplier ships a component with a suspicious pedigree — ancestor URL pointing to a personal fork rather than the official repository — the structured parser flags it immediately. The token-based reader produces a summary that says "the component is present" and moves on.
Evidence arrays and why confidence scoring is impossible without them
CycloneDX 1.5 introduced the evidence array, which records which identity fields (name, version, purl, hash) were established by which method (filename match, manifest match, binary scan, source attestation). This is the single most useful addition to the spec from a triage perspective. A component detected by multiple scanners with hash confirmation is ground truth. A component detected only by a filename heuristic is a candidate. Griffin AI exposes the evidence array as a confidence property on every node in the component graph, so downstream reasoning can weight high-confidence detections above speculative ones. I have never seen a Mythos-class tool surface the evidence array in a user-facing output. The information is simply lost in ingestion, which means every finding that tool produces is treated as equally reliable, which is wrong.
The dependency graph is typed — Mythos reads it as a list
CycloneDX dependencies are edges with a dependsOn relationship, and 1.5 extended the spec to allow typed edges. Griffin AI's parser materializes these into a directed graph where you can ask questions like "show me every component that is a build-time-only dependency with no runtime reachability." A pure-LLM tool sees the dependency section as a list of object refs and, when asked about transitives, walks that list in its token representation — which works for shallow graphs and breaks for deep ones. Past a depth of four or five hops, the model loses track of which ref pointed where, and answers start to confabulate. The larger the graph, the worse the drift. Real enterprise applications have dependency graphs that go 12 to 20 hops deep. A token-based walk of such a graph is pure fiction.
VEX embedded in CycloneDX: a test case for structured reading
CycloneDX 1.5 allows VEX statements to be embedded directly in the SBOM's vulnerabilities section, with fields like state, justification, response, and detail. This is how a vendor tells you "yes, CVE-X is present, but we are not affected because of Y." Griffin AI reads these fields as structured annotations on the vulnerability nodes, so a CVE with a not_affected state and a valid vulnerable_code_not_in_execute_path justification is filtered out of the actionable list automatically. A Mythos-class tool reading the same file either ignores the VEX section entirely or summarizes it in prose that glosses over the justification specificity. The result is inflated finding counts and a signal-to-noise ratio that wastes engineer time.
The ML-BOM extension is where pure-LLM tools break entirely
CycloneDX 1.5 added support for machine learning components — models, datasets, training configurations, inference environments. This extension is how you describe an AI system's supply chain. Griffin AI ingests ML-BOM fields as typed AI components, which means it can answer "which of our products uses the Llama 3.1 70B model with quantization Q4" directly. Mythos-class tools, which are themselves LLMs, are structurally unable to maintain the distinction between the model they are running on and the model they are describing. In my tests, asking a Mythos-class system about an ML-BOM produced output that merged facts about the target model with facts about the tool's own training, which is a subtle but real hallucination vector. Structured parsing avoids this category of error entirely because the data is the data and the model is the reasoner.
License identifiers and SPDX normalization in CycloneDX
Every CycloneDX component can carry a license field populated either with an SPDX identifier or a free-text expression. Griffin AI normalizes these through the SPDX license list at ingestion, so downstream license-compliance queries run against a canonical set. A Mythos-class tool asked "list GPL-licensed components" relies on pattern-matching against whatever strings happen to appear in the license fields, which misses components that use variant spellings or carry SPDX expressions like GPL-2.0-or-later WITH Classpath-exception-2.0. Structured normalization is the reason Griffin can produce a clean license compliance report from a messy real-world SBOM. Token-based reading produces a list that is almost right.
Composition completeness and why auditors ask about it
The compositions section of CycloneDX records claims about how complete each part of the SBOM is — "complete," "incomplete_first_party_only," "unknown." This is the field an auditor cares about when asking whether your SBOM is defensible. Griffin AI surfaces composition claims as first-class metadata, so you can filter out components that live in an incomplete composition from compliance calculations. A Mythos-class tool does not distinguish between a confirmed component and a component from an incomplete composition. Every row looks the same. That flattening is fine until your auditor asks which findings are based on complete evidence and which are not. Then it's expensive.
The bottom line for CycloneDX consumers
The question is not whether your AI security tool can read a CycloneDX file. Every tool can read bytes. The question is whether it parses the spec into a typed graph where each field becomes a queryable property, or whether it treats the file as text. Griffin AI's CycloneDX support exists at the spec level. Mythos-class support exists at the substring level. Those are different products even if they look similar in a demo. Export a CycloneDX 1.5 SBOM with populated pedigree, evidence, VEX, and composition sections. Ask each tool to answer five questions that require those fields. The answers will not be close.