Most buyers need a summary first and the full list only if they have a specific reason. A tiered approach works well: answer in words, then share an aggregate, then a full inventory under NDA when the buyer can explain how they will use it. This protects your stack and still shows control.
What the buyer wants to learn
The reviewer is trying to answer a few questions: do you know what is in your software, can you tell when something in it is vulnerable, and can you respond fast. None of those strictly need a file with every package name. A full list helps if the buyer will check advisories against it. Otherwise it is more detail than the question needs.
Three tiers
| Tier | What you share | When |
|---|---|---|
| 1. Statement | "We maintain an inventory generated from lockfiles for every release and scan it daily" | First questionnaire |
| 2. Aggregate | Counts by ecosystem, license mix, number of open high findings, age of oldest exception | Follow up questions |
| 3. Full inventory | Complete SBOM for a named release | After NDA and a stated purpose |
Move up a tier only when asked and when the answer justifies it.
What to include in the aggregate
An aggregate can be useful without exposing details. Consider:
- Number of production repositories covered by scanning.
- Ecosystems in use, for example three languages.
- Open findings by severity, with how many have exception records.
- Share of dependencies on supported versions.
- Date of the last full scan.
Make sure each figure comes from your own system on the day you send it. Never round numbers up for a better impression.
Ask the purpose
When a buyer requests the full list, ask what it is for. Typical answers are advisory response ("tell us when a flaw lands that affects us") and baseline diligence. For advisory response, offer a process: you will tell them if a major advisory affects your product. For diligence, offer a walkthrough with an engineer plus the full list under NDA.
The CISA 2026 minimum elements guidance treats the SBOM as a baseline for software transparency, and notes that some types of software, such as software as a service, may need extra elements. So when you do share a full list, say which baseline it follows.
Risks of oversharing
A full list tells an attacker which components and versions you run. It may also reveal internal package names, vendor relationships and unreleased work. Share it through a controlled channel, to named people, with a record of who has it. For your public trust page, stick to tier 1. Our guide on NDA gated versus public trust center documents covers what belongs where.
Make it repeatable
Generate all three tiers from the same data so they never disagree. If tier 1 says you scan daily, tier 2 should show recent scan dates. Contradictions between tiers are what make a reviewer dig.
Safeguard produces the SBOM and dependency inventory that all three tiers draw from. You can generate a first one with a free scan.
Quick check
Is it suspicious to refuse the full list?
Not if you offer a clear alternative: an aggregate now and the full list under NDA with a stated purpose.
Should the public trust page show dependency counts?
Usually not. Keep the public page to statements about process and link to evidence on request.
Sources
Last reviewed: 19 October 2026.
