Figure 2: What the generator sees — and what lies outside its field of view.

Three rows, three levels, one sentence:

This is not an indictment of the tool. It does exactly what it was built for, and it does so reliably. The mistake lies in the expectation that a generator could issue a bill of materials for something outside its field of view.

From this follows the work order for the next chapter: whoever wants a complete bill of materials needs, for each level, a generator that sees it — and then one document instead of three. The first of these gaps can be closed, and it is the largest.

Making the SBOM Complete

Of the three gaps from the previous chapter, one can be closed, and it is the largest: the frontend. The path there is predictable — a second generator that sees what Maven does not — and it leads through four stumbling points, the first of which is the most unpleasant.

Two Generators, One Document

cyclonedx-maven-plugin 2.9.3 → 129 components
@cyclonedx/cyclonedx-npm 6.0.1 → 88 components
-------------------------------------------------------
Overlap of purls : 0
merged : 218 components, 219 edges

The overlap is zero, and that is no coincidence: the two generators describe separate worlds. Merged, they yield a document in which the Maven share is 59 percent — the other half of the application was previously invisible.

The merging is handled by a custom script, not an off-the-shelf tool.cyclonedx-cli would be the obvious choice, but it is an executable from a foreign language ecosystem that wants to be installed before every build. The custom tool is shorter than the instructions for installing it, refuses to work on mismatched spec versions and colliding identifiers — and derives the serial number from the inputs instead of rolling dice for it.

Stumbling Point 1: Without a Lock File, Nothing Is Reproducible

The second generator reads the installed package tree. This tree is created anew on every build from a manifest file that names only version ranges. Two build runs can thus describe different software without anything having changed in the project.

This is not a theoretical worry. Measured on the same application, without a single changed line of application code:

Thirty components of difference. The organically grown working tree carried along packages the project had long since stopped declaring — the package manager does not reliably clear away such leftovers. The higher number was not the more complete one, but the contaminated one.

With the lock file under version control, the finding is stable: two independent build runs from a fresh checkout both deliver 88 npm components, 218 in total, 219 edges, 500 packages in the tree. The document deliberately carriesno timestamp and a serial number derived from the inputs — only that makes two runs comparable at all.

Stumbling Point 2: The Order in the Build Process

The merge step does not belong where you would first suspect. The root of the multi-module project is builtfirst — the frontend does not exist there yet. The step therefore sits in the module that produces the delivery, and runs before packaging.

Stumbling Point 3: The Nameless Root

The npm generator prepends a root node to the tree — the project itself, which here is calledno-name because the manifest file is generated, not maintained. Adopt it unexamined, and a component without a license migrates into the document. The evaluation promptly reported it asUNLICENSED; the local check had found nothing. The node is removed during merging.

Stumbling Point 4: The Bundle Is Not the Tree

The fourth is the most fundamental, and it leads directly into the next chapter. The generator reads the dependencytree — what ships is abundle that a tool ties together from it, removing everything nobody calls.

How far that goes is shown by the same before-and-after comparison. The organically grown tree contained nine packages of a commercially licensed component collection, among them a charting library under its own license. All nine appeared in the document. In the shipped bundle, there wasno trace of them — only styling variables that the base design ships for all components anyway.

With the lock file, they are gone entirely, and the reason is sobering: they had long since ceased to belong to the project. On the Java side, they had been removed earlier; in the package tree, they lingered because the package manager had not cleared them away.

So the SBOM does not only undercount, it also overstates — and in the worst case in both directions at once. Both follow from the same sentence from chapter 3: it describes the dependency graph, not the delivery. A graph that is not maintained eventually no longer describes even the project.

Verifiability: Holding the SBOM Against the Artifact

The document is now complete enough to allow a question that would have been pointless before:Is it correct?

The question is not whether it is formally valid. The question is whether what it states matches what is actually shipped. And here the packaging does make a difference after all — not in the content of the bill of materials, but in the ability to verify it.

The Thin Distribution: File by File

The directory tree contains 127 individual archives. Each carries a name, each can be held against the local package repository it came from.

126 of the 127 are byte-identical. The one that differs is the application itself, which is rebuilt on every build. Every third-party component in the release can thus be matched to a line in the document, and vice versa.

That is the ideal case: the bill of materials is not just a claim about a build process but can be checked against the result.

The Fat JAR: Not at All

The same release as a single archive:17,904 entries, all on one level, none with an indication of origin. From the file alone, it is no longer possible to tell which component an entry came from — the boundaries between the dependencies disappeared during packaging.

You can check whether a class is present. You cannot check whether it came from the version the document names.

The Parallel That Holds Everything Together

Exactly the same thing happens one level further down, and there hardly anyone notices it:

There, too, hundreds of individual packages are fused into a few files. There, too, the boundaries disappear in the process. There, too, it is impossible to say afterwards which package contributed which line — and, as chapter 5 has shown, some packages do not end up in the result at all.

Both fusions have the same good reason: fewer files, faster delivery. And both have the same price.

What This Means in Practice

The price is not that you would have to forgo one format or the other. It is that verifiability has to be establishedat build time, because it cannot be established afterwards.

Two means suffice for that, and both are cheap:

A checksum of the artifact in the document. This records which file the bill of materials speaks about — not some result of some run.

An attestation that binds the two together with a signature. This additionally records who is responsible for the build process.

Without this link, even the most complete bill of materials remains a document next to the delivery. For the thin distribution, the comparison can be caught up on if need be; for the fat JAR and for the frontend bundle, the moment is irretrievably gone.

Putting the SBOM into the Release — and into the Platform

The document is complete, reproducible, and verifiable against the artifact. It sits in the build directory.

There it answers not a single question. The asking happens not on the machine where the build ran, but on the one where the application runs — weeks later, by someone who never saw the build process.

The First Place: Next to the Delivery

The bill of materials belongs in the release, for the same reason a package insert belongs in the package and not in the manufacturer’s archive.

The objection is obvious: this makes the delivery larger. How much larger can be calculated:

sbom.json, uncompressed : 511,851 B
sbom.json, inside archive : 75,841 B
Thin Distribution total : 25,935,935 B
----------------
Share : 2.9 per mille

Three per mille. That settles the objection — it was never an argument, but an assumption that nobody had bothered to calculate.

That the document sits in both delivery formats is no coincidence: the step that generates it runs before packaging, and both packagings pick it up.

The Second Place: Where the Searching Happens

A document next to the artifact helps whoever has the artifact. It does not help whoever wants to knowwhich of the shipped versions contained a particular component — a question that spans multiple releases and that no single release answers.

For that, you need a place that holds versions side by side. The submission sensibly happensfrom within the build process, not through a user interface — what is generated automatically should also be filed automatically:

POST /api/v1/boms/inventory/bom/upload
multipart: file=@sbom.json
params={"inventorydisplayname": "…", "inventoryversion": "…"}
201 validation_status: valid sbom_format: cyclonedx spec_version: 1.6
total_components: 218

What the Confirmation Is Worth

The number218 already appeared earlier in this article — calculated on my own, from two merged documents. Now it stands in a second, independent place that has read the document in and found it valid.

That is the real gain: a private calculation becomes a traceable finding. And the cross-check comes for free — had the merging from chapter 5 produced a formally broken document, it would have surfaced here instead of at the recipient’s.

Two Versions Side by Side

The version with the lock file was submitted. The previous one remained, and only that makes visible what the work of the last chapters achieved:

None of these three numbers dropped because less is being shipped. They dropped because the document stopped reporting things that no longer belong to the project.

With that, the inventory is recorded — complete, reproducible, next to the artifact, and confirmed in a second place. What can be answered with it is the subject of part 2.

What Follows From All This

Four formats, one application, one document. What remains of this for the decision that stands at the beginning of a project?

The Trade-Off on the Bill-of-Materials Axis

The column that surprises is the middle one.Completeness and verifiability are two different properties, and the packaging decides only the second. The fat JAR and the thin distribution carry the same bill of materials; only for one of the two can it be held against the result.

Whoever has the choice and values demonstrability takes the thin distribution. Whoever prefers the fat JAR for good reasons — one file, one step — has to establish the link between document and artifact at build time, because it cannot be established later.

Three Sentences That Carry This Article

The SBOM describes the dependency graph, not the delivery. Two artifacts whose file counts differ by a factor of 43 produce the same document.

An SBOM covers what its generator can see. Three gaps on three levels, one cause. The largest of them — the frontend, half the application — can be closed with a second generator.

A bill of materials that cannot be reproduced proves nothing. Without a lock file, two runs of the same project described 118 and 88 components. The higher number was not the more complete one, but the contaminated one.

What This Part Has Not Answered

The inventory is recorded, complete enough, and reproducible. With that, the groundwork is finished — and not a single one of the questions it is collected for has been answered.

Whether one of the 218 components carries a known vulnerability is not in it. Whether one of the licenses conflicts with the planned distribution is not in it either. Where the code comes from, least of all.

A bill of materials is a list. It only becomes an answer when someone queries it — and that is the subject of part 2.