Keep the original SBOM file unchanged in object storage, and index a small set of fields in a database: document identity, supplier, product and release, received date, component identifiers, and processing state. That lets you answer "which products contain this component" in seconds without reparsing files.
Two stores, two jobs
The raw file is evidence. You may need to show exactly what a supplier sent and when. Do not edit it, rename components or reformat it. Store it with a content hash.
The index is for questions. It holds normalized fields extracted from the file so queries are fast and consistent across formats.
Fields to index
| Group | Fields | Why |
|---|---|---|
| Identity | Serial number or namespace, document version, content hash | Detect duplicates and revisions |
| Provenance | Supplier, contact, received date, channel, signature result | Know who said what and when |
| Product | Product name, release, environment, owner | Map to what you run |
| Component | purl or other identifier, name, version, ecosystem, scope | Search and match |
| Relationships | Parent component, depth, linked documents | Trace through products |
| State | Intake state, last matched date, quality flags | Operate the pipeline |
| Findings | Advisory ID, status, supplier statement, decision | Record outcomes |
Why purl first
CycloneDX lets a component assert identity by purl or CPE, and a purl names a package the same way across ecosystems. Indexing the purl string as a separate searchable field makes cross-product queries simple. Keep CPE and plain name as secondary fields for components that lack a purl.
Handle the two formats once
Map both formats into one internal shape at ingestion. CycloneDX has a serial number and version. SPDX has a document namespace unique per document version and a created timestamp. Store each in the same columns, and keep the original format flag so you can open the raw file correctly.
Retention
Keep superseded revisions as long as the product is in service, plus the period your records policy requires. Delete according to policy, not by accident. Record the retention class on each file.
Queries your index should answer
- Which products contain this component and version?
- Which suppliers have not sent an SBOM in the agreed period?
- Which SBOMs failed or were quarantined this month?
- What changed between two revisions?
- Which findings are open without a supplier statement?
If an index cannot answer one of these, add the field.
Try it yourself
Click through it at your own pace, or open it full screen.
Pick a component and ask which of the fields above you would need to answer where it is used.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning with asset discovery, giving you an inventory to search. The free scan is a quick way to see one.
Quick check
Should I store only parsed data?
No. Keep the original file as evidence, and keep the parsed index for speed.
Which field matters most for searching?
The component identifier, ideally a purl, because every impact query starts there.
Sources
- CycloneDX 1.6 JSON reference: purl and cpe fields, serial number, version.
- SPDX 2.3.1, document creation information: namespace and created field.
- Package-URL introduction: purl purpose.
Last reviewed: 19 October 2026.
