Your build shades a JSON parser into your own namespace — how do you keep it visible in your SBOM?

## What shading does to identity Shading — also called relocation — takes a dependency's compiled classes, rewrites their package names into a namespace you control, and bundles the result inside your own artifact. It is done for a good reason: it lets you pin a version of a library without forcing that version on everybody who consumes you, which is the standard escape from diamond version conflicts. The security consequence is rarely considered at the same time. After shading, three things are true at once: 1. **The consumer's dependency graph does not contain the parser.** They depend on your artifact. Nothing in the coordinates they resolve mentions the library you embedded, so any inventory built from resolved dependencies — which is how most inventories are built — is simply blind to it. 2. **The bytes changed, so hashes do not help either.** Relocation rewrites the package name inside every class, which changes the file. A hash of the shipped class matches nothing the original publisher ever produced. The one identifier that is normally beyond argument has been invalidated by a routine build step. 3. **The vulnerable code is still there and still reachable.** Nothing about relocation removes a defect. If the parser mishandles deeply nested input, your artifact mishandles deeply nested input, under a different class name. That combination — present, exploitable, unnameable — is the worst shape a supply-chain problem can take. A false positive costs an engineer an hour. This costs you the knowledge that you have a problem at all. ## Where the information still exists The only moment at which the parser's identity is unambiguous is **inside the build, before or alongside relocation**. At that point the build has resolved the dependency, it knows the ecosystem, the coordinates and the version, and it can compute an exact purl. Every viable control follows from that: - **Generate the SBOM from the resolved dependency graph, not from the finished archive.** An inventory derived from the shipped artifact has already lost the data; one derived from the graph has it. - **Record the original coordinate of every relocated dependency**, and where the format supports it, record the relationship as well — CycloneDX has a `pedigree` structure for ancestry, variants and applied patches, and SPDX can express derivation through relationships. "This component is a relocated copy of that one" is a fact worth persisting. - **Ship the SBOM with the artifact**, attached to the published package rather than left in a build directory. Your consumers cannot recover this by scanning, so if you do not hand it over it does not exist for them. ## What a consumer can do without it Not much, and it is worth being able to say so plainly. Scanning a fat archive for embedded components relies on similarity heuristics: matching class or symbol layouts, embedded resource files, version constants left in string tables. These are genuinely useful and genuinely best-effort — they produce both misses and confident wrong answers, and they degrade further when relocation also strips metadata. A consumer's realistic options are to demand an SBOM from you, to treat your artifact as an opaque component supplied by you, or to reimplement your build. Only the first is reasonable. ## The obligation that comes with it The part candidates most often miss is the responsibility transfer. Once you shade a library into your artifact, **you are its supplier for every downstream consumer**. They cannot upgrade it; the version is welded into your release. When a defect is published against that library, they cannot act — only you can, by rebuilding and republishing. That has three practical consequences: - The embedded component must be in **your** watch list, with an owner, because nobody downstream is watching it on your behalf. - Your release cadence becomes their patch latency. If you ship quarterly, your consumers wait a quarter. - "We shade it, so we are not affected" is exactly backwards and is worth catching in review: shading changes the name, not the code. ## The same failure without shading The pattern repeats wherever a build changes a component's name. An internal fork of a module published under your own module path never matches upstream and never will, no matter how faithfully you rebase it. Vendored source copied into a repository has no coordinate at all. A statically linked native library disappears into an executable. In every case the answer has the same shape: capture identity at the moment the build still knows it, record the derivation explicitly, and accept that you are now the supplier of what you absorbed.