A mature SBOM program ingests SBOMs from a dozen sources: internal builds, vendor-supplied SBOMs, registry-attached SBOMs, third-party scanner outputs. Each source produces SBOMs in a slightly different shape even when they nominally use the same format. A CycloneDX 1.5 SBOM from one vendor and a CycloneDX 1.5 SBOM from another vendor can differ in which fields are populated, how component identifiers are constructed, and which license expressions are used. Normalising these into one queryable graph is where SBOM programs succeed or fail, and the capability separates Griffin AI-driven platforms from Mythos-class general-purpose tools that treat SBOMs as documents rather than as structured data.
What normalisation actually requires
Five capabilities:
- Format parsing across CycloneDX, SPDX, and native ecosystem formats (package-lock.json, go.sum, Cargo.lock).
- Identifier reconciliation. The same package appears as
pkg:npm/express@4.18.2,npm:express-4.18.2, andExpress 4.18.2in different SBOMs. Normalisation resolves these to a canonical identifier. - Version expression parsing. SemVer, PEP 440, Maven version ranges — each has its own syntax. Normalisation produces comparable version information.
- License expression parsing.
MIT AND Apache-2.0,MIT OR Apache-2.0,MIT, Apache-2.0can mean different things. Normalisation produces a canonical license expression. - Relationship reconciliation. Different SBOMs describe the same dependency tree with different edge semantics (direct vs transitive, runtime vs test). Normalisation produces a unified graph.
All five need to work for the downstream query layer to produce correct answers.
Where this matters for security programs
Three concrete use cases enabled by normalisation:
Cross-vendor CVE correlation. A new CVE affects log4j-core. The security team wants to know every product — internal and vendor-supplied — that contains it. With normalisation, this is one query. Without, it is a manual reconciliation project.
License rollup for legal review. The legal team wants to know the aggregate license exposure across the enterprise. Normalised license expressions produce this in seconds. Un-normalised expressions produce weeks of manual cleanup.
Vendor risk review. Compare a supplier's SBOM against the supplier's previous SBOM to identify new dependencies. Normalisation makes the diff meaningful.
How Griffin AI handles it
Three integrated capabilities:
Multi-format ingestion. Parsers for CycloneDX 1.4+, SPDX 2.3+, and all major native formats. Ingest preserves source-format metadata so the original SBOM can be retrieved for audit.
Canonical identifier resolution. The Package URL (purl) specification is the canonical identifier. Every component, regardless of source, is resolved to a purl. Ambiguous cases are surfaced for review rather than silently coerced.
Relationship graph construction. Components and their relationships are merged across SBOMs into a unified graph. Per-SBOM metadata (which SBOM contributed which edges) is preserved for traceability.
The output is a queryable SBOM graph that joins cleanly with the reachability, vulnerability, and license data Griffin AI maintains.
Where Mythos-class tools land
Pure-LLM tools can describe the contents of an individual SBOM well. Cross-SBOM reasoning is harder for a model operating on text representations of SBOMs. Asking "which of our vendors ships log4j-core?" requires structured data across all the ingested SBOMs, not prose reasoning about one SBOM at a time.
The failure mode is partial answers: the tool finds some vendors with the component, misses others due to identifier variance, and doesn't surface the gap.
A concrete example
A customer ingests SBOMs from 34 software vendors as part of their supply chain program. A new CVE is disclosed affecting spring-security-core at versions ≤ 6.3.2.
Without normalisation, the query is a manual review of each SBOM. The component might be listed as pkg:maven/org.springframework.security/spring-security-core@6.2.0, spring-security-core:6.2.0, or just "Spring Security" with the version in a description field. Reconciling these by hand takes days.
With Griffin AI's normalisation, the query is immediate: 11 vendors ship affected versions, with specific version numbers and upgrade paths surfaced. The security team contacts the 11 vendors in the first hour after disclosure rather than the first week.
What to evaluate
Three concrete checks:
- Show the platform ingesting SBOMs in CycloneDX from three vendors and SPDX from one. Query "all components with license MPL-2.0." Is the answer complete?
- Introduce a component identifier variance (same package, two different purl forms). Does the normalisation handle it?
- Diff two versions of a vendor's SBOM. Are the added components surfaced cleanly?
The answers determine whether the platform's SBOM capability is a tracked graph or a pile of documents.
How Safeguard Helps
Safeguard's SBOM ingestion normalises across CycloneDX, SPDX, and native formats into a canonical purl-based graph. Cross-vendor CVE correlation, license rollups, and SBOM diffing are first-class query capabilities. Griffin AI adds reasoning on top — for example, summarising the risk profile of a vendor's SBOM deltas for a TPRM review. For organisations whose SBOM program is graduating from "we collect them" to "we actually use them," normalisation is the architectural step that makes the transition possible.