A cover note should state the product and version, how and when the SBOM was generated, what it covers, what is unknown or withheld, how to ask questions and how corrections will be delivered. It takes five minutes to write and prevents most follow up emails.
Why the note matters
An SBOM file is dense data. A reader opening it cold cannot tell whether a missing component is an error, a gap or a deliberate choice. The CISA 2026 minimum elements say that when required information is not provided, the author should state whether it is unknown or withheld, and should have a process for recipients to ask about redacted security related information. The cover note is the natural place to say this in plain words.
The seven lines
Write each of these in one or two sentences.
- What it describes. Product name and exact version.
- How it was made. The generation context, such as built from source before build, or from the compiled artifact after build. The CISA text gives both as examples.
- When. The date, and the SBOM version if this replaces an earlier file.
- What it covers. For example, all components including transitive dependencies, excluding non code files. The CISA text allows excluding non code files.
- What is unknown or withheld. Name the fields, such as hashes missing for some components, and say whether the gap is unknown to you or held back.
- How to ask. A named contact and a way to raise questions about redactions or errors.
- How updates arrive. Whether a revised file will be sent, and how the customer will know.
A short example
This SBOM describes Product X version 4.2. It was generated from source before build on 19 October 2026 using our standard tooling. It lists all direct and transitive dependencies. License data is unknown for a small number of components and is marked as such. Hashes are not included for components we did not receive as artifacts. Questions go to the contact below. If we find an error we will issue a revised file with a new SBOM version and tell you directly.
Notice what it avoids: no claim of completeness, no percentages you have not measured, no promise to send on every release unless you have agreed to it.
What to leave out
- Marketing language about how secure the product is.
- Predictions about which findings a scanner will report.
- Internal tool names or paths that are not part of the file.
- Any statement of a certification or regulatory status you cannot back with a document.
Keep the note with the file
Store the note next to the file and in the ticket. If the customer asks a year later what you sent, you can show both. The CISA text says each software version or update should have an associated SBOM, so a clean naming rule for note and file helps. See how to name and store an SBOM for every release.
Quick check
Is a cover note required?
No source requires one. It is a practical way to meet the CISA guidance on explaining unknown or withheld information.
Should the note mention vulnerabilities?
Only to say how you will answer questions about them. An SBOM lists components and does not carry exploit status.
Safeguard's SBOM and dependency scanning can give engineering the component list and context that goes into a note like this, and the free scan lets you preview it.
Sources
Last reviewed: 19 October 2026.
