Check the supplier, component name, external reference, file path and tool metadata fields before sending an SBOM. Those are the places where private package names, internal registry URLs, build host paths and employee names tend to appear. Review each one, then fix the source rather than editing the output by hand.
Why review at all
An SBOM is generated by a tool reading your repository or build. Tools record what they find. If a private package is named after an internal project, or a lockfile points to an internal registry, that text can land in the file. The NTIA minimum elements report says the author field names the source of the SBOM data, which may be the supplier or a third party tool, and the timestamp records when the data was assembled. Those fields, along with the component data, deserve a human read.
Field by field
| Field area | What can leak | What to do |
|---|---|---|
| Component name and supplier | Private package names, internal team names | Use a public identity for the supplier, keep private packages only if the customer needs them |
| Other unique identifiers | Internal registry hosts inside package URLs | Check each identifier for hostnames |
| External references | Repository URLs, issue trackers, build pipelines | Remove internal links or replace with public ones |
| File paths and evidence | Home directories, build agent paths, usernames | Configure the generator to omit paths |
| Author and tool metadata | Employee names, emails, tool versions | Use a team or role address |
| Hashes | Usually harmless | Keep, they help matching |
A five minute review routine
- Search the file for your internal domain names. Any hit is a candidate for removal.
- Search for the text of your build paths, such as a home directory or CI workspace prefix.
- List every component whose supplier is blank or marked unknown. The NTIA report says the dependency data should distinguish between a component with no dependencies and one whose dependencies are unknown, so use the format's explicit values instead of guessing.
- Read the author and tool fields.
- Re-run the generator after you change its settings, then diff the new file against the old.
Fix the source, not the output
Hand editing a generated SBOM breaks hashes, signatures and the link to the build. Better to change the generator's configuration, the registry settings or the package naming, then regenerate. If you must remove something, record that the SBOM was filtered. Honest SBOMs state their limits. A related post covers whether you can redact an SBOM before sharing.
Try it yourself
Open the demo and look at what each component row contains. Ask which of those values would be fine for a customer to read, and which you would want to review first.
Click through it at your own pace, or open it full screen.
Quick check
Is a package name really sensitive?
Public package names are not. Names of private packages can reveal project names or architecture, so decide per package whether the customer needs it.
Should we delete private components from the SBOM entirely?
Only if you note that the SBOM is partial. Silently dropping components makes the file misleading, and the NTIA report asks authors to be explicit about what is not enumerated.
Safeguard's SBOM and dependency scanning works from your repository, and the free scan lets you see a generated component list before anyone else does.
Sources
Last reviewed: 19 October 2026.
