Your CI worker image's SBOM lists OS packages but no Ruby gems - how do you diagnose it?

## Read the failure correctly The document is not corrupt and the tool did not error. It reported everything it had evidence for. Two analyzers ran; one found a package database full of entries, the other found nothing it recognised. **Absence of components and absence of evidence look identical in the output** — that is the whole lesson of this scenario, and it is why interviewers like it. ## Why the halves differ OS packages are easy: the distribution's package manager maintains a database at a well-known path, and every installed package has a row in it. It is a single, authoritative source. Language packages have no such registry. For Ruby, a generator looks for installed gem specifications (the `.gemspec` files a gem installation writes) or a resolved lockfile listing the pinned set. Both are conventions about *where files land*, and any of these break them: - **Vendored bundles.** Gems installed into a project-local vendor path may not sit anywhere the analyzer walks by default, especially if the scan was scoped to a subtree. - **Version managers.** A Ruby installed under a per-user version-manager tree puts its gems somewhere the tool has no reason to look. - **Multi-stage builds.** The `Gemfile.lock` and the gemspecs existed in the build stage; the final stage copied only the application directory, so the evidence never reached the image being scanned. - **Stripped images.** A cleanup step that removes documentation and specification directories to shrink layers takes the evidence with it. - **Wrong subject.** The SBOM was generated over the base image or an intermediate stage rather than the published one. ## A diagnosis order that works 1. **Confirm the subject.** Which digest was scanned? If the pipeline scanned a stage or a tag other than the artifact you ship, stop here — everything downstream is about the wrong thing. 2. **Look inside the image.** Start a shell in it and find where gems actually live and whether specification files survived. If they are gone, no generator will find them. 3. **Turn on the generator's verbose or debug output** and read which analyzers ran and what they matched. This distinguishes "analyzer never fired" from "analyzer fired and found nothing". 4. **Re-run scoped at the real path.** Point the generator at the filesystem directory that holds the bundle. If components appear, it is a path or scope problem; if not, the evidence is genuinely absent. 5. **Compare against a known-good count.** Whatever the application's resolved dependency set is, the SBOM should be in that neighbourhood. A count of zero for a Ruby application is a fault, not a result. ## Fix it where the evidence lives The durable fix is to generate the language half at the point where the manifest and lockfile exist, rather than trying to recover it from a stripped runtime image. That means generating during the build stage that installed the dependencies and carrying the document forward, and keeping the OS half generated over the final image. Merging the two views gives an inventory that matches what you ship. ## Make the silence loud The control that prevents a recurrence is a **completeness assertion**: after generation, fail the build unless each ecosystem you expect for this service yields at least a plausible number of components. A service you know is Ruby-based with an OS base should never publish a document with zero gems. This converts a silent gap into a red build, which is the only way a coverage regression gets noticed — nobody reads a passing SBOM. ## Why the asset matters here A CI worker image is not an ordinary workload. It holds the credentials that push artifacts and deploy them, so it is a high-value target for anyone who can influence the build. An inventory that quietly omits the entire application layer of that host means that when an advisory lands against one of those gems, your search across the estate returns nothing for the machine that can sign and deploy everything. The document was not merely incomplete; it was incomplete in exactly the place where being wrong costs the most. ## What a weak answer sounds like "The scanner is broken, try a different one." Swapping tools sometimes papers over the symptom because another generator happens to walk that path, but it leaves the underlying condition — evidence missing from the artifact — untouched, and the next ecosystem you add disappears the same way.