Data processing
These nodes clean up and combine SBOM data — the work that turns several inconsistent inputs into one dataset you can rely on.
Normalize Data
Canonicalizes SBOM components against the FossID Knowledge Base, with a structural fallback. Rewrites names, versions, licenses, and identifiers, preserves the originals, and annotates every change it makes.
This addresses the most common problem with real-world SBOMs: the same component described differently by different tools. Normalizing means every later step — verification, merging, compliance — works on consistent data.
This step is optional. Reader nodes already canonicalize the format and turn license strings into SPDX expressions when they parse a file, so a pipeline works without it — most of the built-in templates do not include it.
What this node adds is component-level canonicalization against the Knowledge Base: reconciling the names, versions, and identifiers themselves. Add it when your inputs come from several tools or suppliers and you need them to line up.
| Category | Normalization |
| Input | sbom |
| Output | sbom |
| Multiple inputs | Yes |
| Parameter | Type | Default | Description |
|---|---|---|---|
| Mode | structural-only, kb-then-structural, kb-only | kb-then-structural | kb-then-structural: the Knowledge Base wins, structural rules fill the gaps. kb-only: only rewrite components found in the KB. structural-only: no KB calls at all. |
| Normalize Fields | multi-select: name, version, license, purl, cpe, supplier | all six | Which component dimensions to canonicalize. |
| On KB Conflict | prefer-kb-annotate, keep-original-annotate, fail | prefer-kb-annotate | What to do when the KB and the SBOM disagree about a license. |
| Annotate Changes | boolean | true | Add a note to each element summarizing what was rewritten. |
| Fail On KB Error | boolean | false | Abort on KB transport, authentication, or server errors. A component that is simply not found always falls back to structural handling. |
| KB Connection | connection | — | The FossID Knowledge Base connection. Required for kb-then-structural and kb-only. |
Original values are always preserved, so normalization never destroys what the supplier actually sent — it records both what was received and what it was canonicalized to.
Merge Data
Combines the contents of several SBOMs into one.
Use this when a product is described by more than one SBOM — several suppliers, several build stages, or several scanners — and you need a single integrated view.
| Category | Consolidation |
| Input | sbom |
| Output | sbom |
| Multiple inputs | Yes — waits for every branch feeding it |
| Parameter | Type | Default | Description |
|---|---|---|---|
| Merge Structure | graph, flatten | graph | graph: one deduplicated entry per component, with hierarchy kept as relationships. flatten: discard the tiering and emit a flat deduplicated inventory (provenance is still kept). |
| Root Mode | single-root, multi-root | single-root | single-root: create a new top-level element representing the integrated product, with the inputs as its children. multi-root: keep the inputs as co-equal roots — a bundle rather than an assembly. |
| Root Name | string | workflow name | Name of the synthesized root element, when Root Mode is single-root. |
| Root Version | string | execution id | Version of the synthesized root element. |
| Dedup Key | purl, purl-and-hash, name-and-version, none | purl | How to decide two entries are the same component. purl-and-hash only collapses when identifiers and checksums match — the safest choice for security pipelines. name-and-version is a fallback for inputs without purls. none keeps every occurrence. |
| Conflict Policy | union-and-annotate, prefer-first, fail-on-conflict | union-and-annotate | union-and-annotate: combine what can be combined, choose deterministically where one value must win, and record conflicts as warnings. prefer-first: the first input wins. fail-on-conflict: stop at the first irreconcilable conflict. |
| Annotate Provenance | boolean | true | Record which source document each merged element came from. |
| KB Connection | connection | — | Optional FossID Knowledge Base connection. When set, components are canonicalized against the KB before deduplication. |
Leaving Annotate Provenance on is what lets the merged output answer "who shipped this component" — worth keeping unless you have a reason not to.
Related
- Nodes — how multiple inputs are gated.
- Connections — setting up Knowledge Base access.