An SBOM ticket should hold the customer's exact words, the product and version, the format, the recipient, the deadline, the access terms, and any promises already made. Engineering should answer back with the generation context, known gaps and a file hash. That keeps both sides honest.
Why a template saves time
When sales forwards "customer wants an SBOM" with nothing else, engineering loses a day asking basic questions. A fixed template turns the first message into a complete request. It also leaves a record you can read when the customer comes back six months later.
Fields for the requester
| Field | Example of what to enter |
|---|---|
| Customer and contact | Name, role, and who receives the file |
| Exact request text | Paste the email or questionnaire line |
| Product and version | The release the customer runs |
| Format | SPDX, CycloneDX or unknown |
| Purpose | Inventory, scanning, audit evidence, contract |
| Deadline | The date the customer stated |
| Terms | Public, NDA, or special agreement |
| Promises made | Anything said on a call or in writing |
Fields for engineering to fill in
The CISA 2026 minimum elements give a ready list of what to check before the file goes out. Engineering should confirm:
- The SBOM identifies the right component and version, and carries a new SBOM version if it replaces an earlier file.
- The author and timestamp are present. The CISA text says the timestamp should follow RFC 9557.
- The tool name and version are recorded.
- The generation context is stated, for example before build, from source, or after build, from binary analysis.
- Each component has a name, a producer, a version and at least one machine processable identifier.
- Unknown values are marked unknown or withheld, not guessed.
- A hash of the SBOM file itself is stored in the ticket, so a later question can be answered about exactly what was sent.
The last item is an internal practice rather than a CISA element, but it makes the record useful.
Add a review step
Before sending, a second person should open the file and read the first fifty lines. The point is to catch internal repository paths, private package names or credentials in URLs. Redaction is allowed. The CISA text says the author should state whether information is unknown or withheld, and should have a process for recipients to ask about redacted security related data.
Close the ticket properly
Close only after three things happen: the file is delivered through the agreed channel, the delivery is logged, and the customer confirms receipt. Add a note for any follow up, such as a revised file if a mistake is found. The CISA text says organizations should accommodate updates to SBOM data, including corrections.
Quick check
Do we need a ticket for every request?
Yes, even small ones. The record is what lets you answer the next question and fix a mistake later.
Should the ticket say which tool generated the file?
Yes. The 2026 elements list tool name and version as SBOM metadata, so record both.
For the first customer reply that feeds this ticket, see what sales should say first. Safeguard's SBOM and dependency scanning can help engineering produce and keep current the inventory these tickets rely on.
Sources
Last reviewed: 19 October 2026.
