Safeguard
Supply Chain Security•

What to leave out of an SBOM, and how to redact without lying

CISA's 2025 draft says what an SBOM must cover and what it need not. Use it to decide what stays out of the file you send a customer, and how to mark the gaps honestly.

Safeguard Security Team
4 min read

CISA's August 2025 public comment draft of the SBOM minimum elements is mostly a list of things to include. Read closely, it also tells you what you may leave out, and how to say so. That second half matters when the file is going to a customer's procurement team and you do not want your internal build layout in it.

The draft is not final and creates no new federal requirement. It is still the clearest public statement of what a buyer will expect.

What's affected

Every SBOM you hand to someone outside your company. Generators are happy to record whatever they find, and what they find often includes things the recipient does not need.

What the draft says you may skip or must handle with care:

  • Non-code files. "An SBOM need not include non-code files; however, it may include security-relevant files such as configuration files."
  • A hash you cannot compute. If the author does not have the original component artifact, "the SBOM Author should not include a Component Hash."
  • Redacted dependencies. Distinguish what is unknown to you from what is "purposefully redacted," and have "a process for recipients to ask about any redacted, security-related information." The draft adds that organizations may consider an SBOM incomplete if essential dependencies are redacted.
  • Depth. There is no minimum depth. You cannot trim transitive dependencies to make the file smaller.

How to check if you're exposed

Generate the SBOM, then search it for details that describe your company rather than your software. Typical hits are internal registry hostnames, file system paths from the build agent, repository URLs for private code, and usernames embedded in URLs.

# adjust the patterns to your own naming
grep -n -i -E "corp|internal|/home/|/Users/|runner|token|password" sbom.cdx.json | head -50
jq -r '.components[].purl' sbom.cdx.json | grep -E "repository_url|@" | head

Anything that turns up is a candidate for removal or for a deliberate, labeled redaction.

What to do now

  1. Decide your redaction rule once, in writing: which fields you remove (internal paths, private hostnames), and which you never remove (name, version, identifier, relationship).
  2. Remove private details at generation time where the tool allows it, not by hand-editing the JSON afterward. Hand edits break the file and the timestamp.
  3. Never delete a dependency to hide it. Replace the detail, keep the component, and label it as redacted. Silent removal makes the SBOM wrong, and the draft says errors may count against you.
  4. For first-party private components, keep the component entry and relationship, and omit only the internal location.
  5. State unknowns plainly: unknown license, unknown producer, incomplete dependency list. The draft asks for "unknown" to be explicit rather than blank.
  6. Put a contact in the cover note for questions about redacted items.

How to avoid this trap

  • Do not strip transitive dependencies to look smaller. The draft expects the recipient to be able to conclude a new vulnerability does not affect them because the component is absent from the list.
  • Do not invent a hash for a component you only know by name.
  • Do not share the file through a public URL just because it is convenient. The draft says access controls can limit sharing with outside parties.

Why it matters

An SBOM is evidence. A file that hides things quietly is worse than one that says "redacted, ask us," because the first one fails the day a customer finds a component you did not list. Careful redaction keeps your internals private and your credibility intact.

Try it yourself

Generate an SBOM for one repository, run the search above, and write down every hit with a decision: remove, label or keep.

Click through it at your own pace, or open it full screen.

Quick check

You cannot access the original artifact for a component. Should the SBOM include a hash for it?

No. The draft says the author should not include a Component Hash in that case.

Can you delete a sensitive dependency from the SBOM before sending it?

Not silently. Mark it as redacted, keep a way for recipients to ask about it, and expect that essential redactions may make the SBOM count as incomplete.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.