Which capabilities solve which problems?
| Area | Operational job | Buyer evidence |
|---|---|---|
| Generation | Describe actual source/build/container/binary artifacts | Reference-corpus results by ecosystem and artifact type. |
| Ingestion | Receive supplier inventories safely | Exact formats/versions, validation, release mapping and loss reports. |
| Normalization | Resolve identity without erasing uncertainty | Original values, resolver rules, overrides and graph preservation. |
| Management | Retain products, releases and revisions | Historical queries and traceable correction workflows. |
| Security analysis | Investigate candidate vulnerabilities | Feed coverage, refresh, applicability decisions and VEX use. |
| Reporting and exchange | Share and export usable evidence | Raw/normalized data, APIs and reproducible reports. |
| Enterprise operation | Control access, scale and recover | SSO, permissions, logs, limits, restore and support tests. |
Test each function independently. An excellent generator may have no supplier intake. A consumption platform may rely on other tools for generation. A licensing module may record useful evidence without determining your legal obligations.
When existing tooling is sufficient
Retain existing tooling when it produces acceptable artifacts, supports the required receiving workflows and provides accountable release mapping, retention, response and export. Write down the owner of each integration and its maintenance cost.
A standalone platform is easier to justify when many suppliers, product teams, formats or supported release histories need a shared registry and governance. The decision is about operating scale and gaps, not whether “SBOM” appears in the product name.
Deployment and architecture decisions
| Choice | Question to settle |
|---|---|
| Hosted service | What inventory/code leaves your environment, and where is it stored? |
| Self-managed | Who patches, backs up, scales and supports the service? |
| Hybrid generation | Where do scanners run, and which results are transmitted? |
| Evidence store | Can originals be retained independently of platform indexing? |
| Integrations | Which system owns assets, findings, applicability and tickets? |
| Sharing | Can suppliers/customers receive only the data they are authorized to access? |
Use your own security and operating constraints. Self-hosting does not remove implementation or maintenance effort. A hosted service does not automatically provide the confidentiality or export commitments your organization needs.
An example operating model
Engineering generates release-bound inventories in CI/CD. A receiving service validates them and retains originals. Supplier management handles third-party delivery and corrections. A central registry normalizes data and relates it to products and deployed releases. Security analysts investigate matches and product owners implement responses.
A small team may combine those roles. A large organization should still keep clear responsibilities and an escalation path. Compare vendors against this workflow rather than accepting the vendor’s dashboard as the definition of success.
Vendor landscape: the evidence needed before comparison
This initial edition includes documented open-source tool examples in the generator guide. It does not publish commercial vendor rankings or profiles. A procurement-grade commercial comparison requires a separate verification pass over exact version support, generation versus ingestion, deployment, APIs, pricing and limitations.
The comparison model is ready in the downloadable requirement matrix: each capability can be linked to a documentation URL, review date, tested product version, evidence type and limitation. Unknown means unknown, not a negative score. Product documentation and observed pilot evidence should take precedence over broad marketing claims.
See documented tool examples and the vendor-response matrix.
A buyer journey with decision gates
- Assess obligations, scope and current tooling gaps.
- Define required functions and realistic usage volumes.
- Run a controlled demonstration and a representative pilot.
- Normalize quotes to identical scenarios.
- Negotiate deliverables, data rights, service and exit.
- Accept implementation against tested outcomes.
Primary sources
- Syft · Official project documentationTool documentation
- cdxgen · Official project documentationTool documentation
- OWASP Dependency-Track · Official projectTool documentation