Run a mock review: one person plays the buyer's security reviewer, one answers as your company, and one takes notes. Spend 45 minutes on ten realistic SBOM questions, score each answer for specificity, and fix the weakest three before a real call.
Why rehearse
Most weak SBOM answers are not wrong, they are vague. "We scan regularly" survives until a reviewer asks "how often, with what, and who sees the result." Saying the real answer out loud, once, with a colleague pushing back, finds the gaps cheaply.
Roles
- Reviewer. Asks the questions and follows up once on anything vague.
- Respondent. Answers as your company, using only what is documented.
- Scribe. Records each answer and scores it.
Rotate roles in later sessions so engineering, sales and the founder each take a turn.
Agenda
| Minutes | Activity |
|---|---|
| 0 to 5 | Agree scope: which product and release is under review |
| 5 to 30 | Ten questions, about two and a half minutes each |
| 30 to 40 | Score and list the three weakest answers |
| 40 to 45 | Assign owners and dates for fixes |
Ten questions to use
- How do you generate your SBOM, and in which format?
- How often, and what triggers a new one?
- Does it include transitive dependencies?
- Can I have the one for the version I run?
- How do you handle components with unknown details?
- What happens when a new advisory affects a component?
- Do you sign your SBOMs?
- How do you handle copied or forked code?
- What is not covered by your SBOM?
- Who do I contact if I find a problem in it?
These track the areas CISA's 2026 minimum elements covers: coverage, frequency, distribution, handling of unknown data, and the author signature (see Sources).
Scoring
Give each answer 0 to 2.
- 0: Vague or untrue. No detail, or a claim you cannot support.
- 1: True but general. No owner, date or scope.
- 2: True and specific. Names a tool, trigger, scope or owner, and could be checked.
A total under 12 out of 20 means do not take the call yet. Fix first.
Common findings
- Nobody knows where past SBOMs are stored.
- The answer to "what is not covered" is "nothing," which is rarely true.
- Sales and engineering give different answers to the same question.
- No one has opened a recent SBOM and read it.
After the session
Write the best version of each answer into your shared SBOM folder so anyone can reuse it. Put the three fixes into your normal tracker with owners. Repeat the drill each quarter, or before a significant deal.
Where Safeguard fits
To prepare real material for the drill, Safeguard's SBOM and dependency scanning and compliance evidence automation can supply a current SBOM and a dated record of findings. Start with the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Use it during the drill as a prop, and see which findings your respondent can explain without help.
Quick check
Who should play the reviewer?
Someone who did not write the answers, ideally with a security or customer facing background, who will ask a natural follow up.
How often should we repeat it?
Quarterly is a reasonable rhythm, plus before any deal where security review is the gating step.
Sources
Last reviewed: 19 October 2026.
