When a client asks what you shipped, let the SBOM answer

Picture the final week before go-live. The pipeline is built, the agent runs well on the client’s real data, and then their security team sends a one-line email: “What exactly is in what you’re delivering?”

The temptation is to answer by pasting requirements.txt or package.json into the body of a reply. It is quick and looks complete. But DevGuard’s documentation points out that transitive packages do not appear in top-level declaration files like these; the dependency tree stays hidden unless you deliberately open it up.

The skill here is not running a command that produces a file. It is understanding what the client is really asking, delivering an inventory their tools can read, and knowing where your inventory is blind before the client finds out.

The question is really about relationships

NTIA’s 2021 report defines an SBOM as a formal record containing the details and supply chain relationships of the components used to build software.

The word “relationships” sits inside the definition; it is not an afterthought. The dependency relationship field in NTIA’s minimum elements describes how an upstream component is included in the software.

On depth, according to FOSSA’s summary, an NTIA-compliant SBOM must include every top-level component and all transitive dependencies, or provide enough information to trace them. A manifest pasted into an email meets only the first half.

The second half is where the risk lives. DevGuard, a security tooling vendor, argues that the vast majority of vulnerable packages in a typical application are transitive. That is a vendor’s claim, not independent research, but anyone who has printed out a dependency tree knows the packages they chose themselves are only the tip.

The inventory must also say where it came from

CISA’s 2025 minimum elements build on NTIA 2021 and stress machine-processable formats so that SBOMs can be integrated into tooling at scale. According to Sonatype’s summary, the 2025 version adds four fields: Component Hash, License Information, Tool Name and Generation Context. Each maps to a question clients tend to ask alongside the first one.

Field added by CISA in 2025	What the client is really asking
Component Hash	Is this file the same file you checked?
License Information	Are we allowed to use, modify and redistribute it?
Tool Name	Which tool produced this inventory, and can we trust it?
Generation Context	In what context was it generated: from source or from the build?

The practical consequence: do not send a document meant only for human eyes. Ask the client’s security team which tool they load SBOMs into and in what format, then deliver exactly that. One question at kickoff saves a last-minute round of format conversion.

Walking through a delivery line by line

Suppose you deliver a container holding an internal RAG service. The service directly declares a PDF parsing library, which in turn pulls in an image processing library you have never mentioned. The package names below are hypothetical:

rag-service 1.0.0
└── example-pdf-parser 2.4.1      (direct)
    └── example-image-lib 0.9.2   (transitive)  ← has a published vulnerability

If the inventory is a flat list, both packages are present but nobody can tell which pulls in which. SafeDep argues that a flat SBOM hides which direct dependency upgrade would remove a vulnerable transitive package, which drags out incident response.

With relationships recorded, the answer is immediate: upgrade example-pdf-parser to a version that no longer pulls in example-image-lib 0.9.2.

Vulnerabilities are not the whole story. SafeDep also says this blind spot is where malware, outdated libraries and licensing problems tend to hide. Imagine example-image-lib carries a copyleft licence while the contract states the client will repackage the delivery for a subsidiary: a manifest will never show you that conflict.

Your job at that point is not to make a legal ruling yourself. Flag the component, find an alternative if there is one, and tell the person handling legal on your side before the file reaches the client. Found by you, it is a line in a technical note; found first by the client, it casts doubt on the whole delivery.

The CRA sets a floor, not a ceiling

For clients selling products into the EU, the Cyber Resilience Act is the reason this question will come. According to FOSSA, Annex I of the CRA requires an SBOM to cover at least the top-level dependencies. “At least” is a legal floor, not a complete inventory.

Guidance TR-03183-2 from the BSI, Germany’s cybersecurity agency, goes further, although it is not binding and is not EU law: dependencies must be resolved recursively on every branch, at least to the first component outside the scope of delivery.

For an FDE this is the more practical yardstick, because it asks what the delivery contains rather than only what you chose.

So even if the client asks only for the CRA minimum, generate the full tree. If a vulnerability three layers down is published after go-live, the person who has to find a way to remove it is still you.

Five steps before you send the file

1. At kickoff, ask the client which tool and format they use to ingest SBOMs.
2. Generate the SBOM at build time from the exact artifact you will deliver, not from a developer machine, and record the tool name and generation context.
3. Check the depth: the inventory includes transitive dependencies and the relationships between them, and every component has a version, hash and licence.
4. Review the transitive packages separately for vulnerabilities, outdated versions and licences that conflict with how the client intends to use the software.
5. Write a short scope note stating how deep the inventory goes, what it does not cover and when it was generated; after every patch, start again from step 2.

Mistakes that make an inventory backfire

The most common mistake is delivering an SBOM once and treating the job as done. Sonatype warns that a poor-quality SBOM is one that is incomplete, inaccurate or out of date. Every time you patch a dependency on the client’s site without regenerating it, the old inventory becomes all three and creates a false sense of security.

The next is listing only direct dependencies because the CRA says “at least top-level”. That is the minimum needed to stay compliant, while the client’s real risk sits in transitive packages and the relationships between them. A top-layer-only inventory is lawful but does not answer the question the client is actually asking.

The third is having every package but dropping the relationships, which gives you a flat SBOM. When an incident happens, the client’s team has to rebuild the tree themselves to work out what to upgrade, just when they have the least time.

One small thing worth getting right from the start: record licences with standard identifiers rather than free text such as “Apache license v2”. Free text is hard for the client’s tools to parse and pushes the checking back onto people, which runs against the machine-processable spirit CISA emphasises.

A skill worth putting on your CV

When reading FDE job ads, watch for this: the more a description mentions security reviews, client procurement processes or on-prem deployment, the more you should prepare for the “what’s in the delivery” question. That is an inference from the nature of the work, not a rule, so ask the hiring manager directly at interview.

On your CV, do not write a vague “interested in security”. Write one concrete line: generated and maintained an SBOM with full transitive dependencies and relationships for a delivery, and caught a licence conflict before the client’s review.

A personal project with an SBOM covering the full dependency tree, plus a scope note, is easier evidence to verify than any self-description.

Next time that one-line email arrives, you will not paste requirements.txt. You will send a file the client’s tools can load straight away, with a line stating how deep the inventory goes and what it does not cover.