Bring the SBOM to the architecture review and ask what the design depends on, who maintains it, how it is updated, and where the risky pieces sit. The component list makes the discussion concrete: you review actual libraries and services, not a diagram of boxes.
What the SBOM adds to a diagram
Architecture diagrams show intent. An SBOM shows what was actually pulled in. CycloneDX describes its format as an inventory of components and services and the dependency relationships between them, which is exactly the view a reviewer needs to compare against the diagram. Differences between the two are findings.
Eight questions to ask
- Is every box in the diagram in the SBOM? If a database driver, queue client or auth library is missing, the SBOM may be incomplete or the diagram wrong.
- Is anything in the SBOM missing from the diagram? Unexpected components often mean undocumented integrations.
- Which components handle untrusted input? Parsers, template engines, image and archive libraries deserve attention first.
- Which components hold secrets or identity decisions? Authentication, session and crypto libraries are the ones you most need current.
- How many components are transitive only? A high ratio means you depend on choices you never made.
- Who maintains the critical ones? A single maintainer, an archived repository or no release in a long time is a design risk, not just a patch task.
- How do updates reach this system? Lockfile, automated pull requests, manual bumps, or nothing.
- What is the exit plan? For each critical library, how hard is replacement?
A one page review sheet
| Area | Evidence from SBOM | Reviewer note |
|---|---|---|
| Input handling | Parser and format libraries and versions | |
| Identity and secrets | Auth and crypto libraries | |
| Data stores | Drivers and clients | |
| Third party services | Listed services, if recorded | |
| Maintenance health | Release recency, archived status | |
| Update path | Lockfile and automation |
Fill the sheet during the meeting, and attach it to the design record. Our post on architecture decision records for security choices shows how to keep the outcome.
Limits
An SBOM does not show runtime behaviour, network paths or configuration. It also reflects one build, so match it to the environment under review. For a service design, record external services as well as libraries where your SBOM format supports it. The goal is a shared list of facts, which is a better starting point than memory.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings roll up by component and severity.
Safeguard's SBOM and dependency scanning, asset discovery and policies give reviewers the inventory to start from. You can run a free scan to see a component list.
Quick check
Should every design review include an SBOM?
For anything with meaningful dependencies, yes. Even an early SBOM from a prototype shows what the design will really rely on.
What if the SBOM and the diagram disagree?
Treat it as a finding. Find out which is wrong and fix the record.
Sources
Last reviewed: 19 October 2026.
