SPDX Versus CycloneDX

## Two designs for the same picture Both formats answer *what is in this artifact and how are the pieces related*, but they put the answer in different places. **SPDX** makes the edge an object. Every element in the document has a document-local identifier, conventionally written with an `SPDXRef-` prefix, and a separate `relationships` array holds entries of the shape *source element, relationship type, target element*. The type vocabulary is large — containment, dependency in several flavours, generation, description, variance, static and dynamic linking, and more. The document also names its own subject with a DESCRIBES relationship, so the root of the graph is stated rather than inferred. **CycloneDX** splits the same information across two mechanisms. Structural containment is expressed by nesting: a component may carry its own `components` array, which is how an assembly, an installer or a chart says *these things are inside me*. Dependency is expressed separately in a flat `dependencies` array, where each entry has a `ref` naming one component's `bom-ref` and a `dependsOn` list of other `bom-ref` values. The subject of the whole document is `metadata.component`. ## Identifier scope Both `SPDXID` and `bom-ref` are **document-local**. They are unique inside one BOM and carry no meaning outside it. SPDX gives the document itself a namespace URI, which is what makes an element globally addressable when combined with its local id; CycloneDX gives the document a `serialNumber` plus a revision number for the same document-identity purpose. Assuming either local id is a stable global handle for a component is a common and consequential mistake, because it invites downstream systems to key their own records on a value the producer may regenerate at will. That leads to a subtle operational property: identifier **stability across releases** is a producer discipline, not a format guarantee. If one team's `bom-ref` values are derived from component coordinates and stay stable release to release, while another team's element ids are regenerated on every build, then diffing two consecutive BOMs from the second team is pure noise. Nobody can point at the diff and say which components actually changed, which is precisely the evidence you want when the question is whether a change was legitimate — an unwanted change introduced by someone with ordinary commit access hides best inside a diff that is noisy every time. ## What a round trip loses The honest answer to *is conversion lossless* is no, and the relationship layer is where the loss starts. - **Type collapse.** SPDX distinguishes *contains* from *depends on*; a naive conversion writes both as `dependsOn` edges. The resulting graph is still connected and still traversable, but the statement *this operator is bundled inside the chart* has become *this chart depends on the operator*, which is a weaker and different claim. - **Direction and inverse types.** SPDX offers both a relationship and its inverse. A converter that normalises one direction silently rewrites who the subject of the claim is. - **Nesting versus edges.** Going the other way, CycloneDX nesting must be re-expressed as explicit SPDX relationships; a converter that flattens the tree into a component list first loses the containment structure before it ever gets to the relationships array. - **Scope hints.** SPDX has dependency relationship types that distinguish development, test, optional and runtime dependencies; CycloneDX carries a per-component `scope`. These do not map cleanly onto each other, and dropping them turns a build-only tool into an apparent runtime component. ## Absent is not empty One CycloneDX detail is worth memorising because it is asked directly: a component that appears in `dependencies` with an empty `dependsOn` is asserted to have no dependencies, whereas a component that does not appear in `dependencies` at all has *unknown* dependencies. Treating the second as the first turns *we did not analyse this* into *there is nothing under here*, which is the same class of mistake as reading an unasserted SPDX field as a clean one. ## What the graph does not tell you Neither format's edge means *this code runs*. A dependency edge records a declared or resolved relationship. Whether the vulnerable code inside a dependency is actually called is reachability, and whether an attacker can drive execution to it is exploitability; an SBOM graph is input to those questions, not an answer to them. A candidate who says *the SBOM shows we depend on it, therefore we are affected* has skipped both. ## How to answer in an interview State the structural difference in one breath — typed edges in an array versus nesting plus a single untyped dependency edge — then immediately give one consequence: conversion flattens the type, and both identifier schemes are document-local. That combination shows you have read both formats rather than one, which is the actual thing being tested.