Review software inventory changes between two deliveries.
Free tool: results are indicative and are not a certification. Use is subject to the Terms of service and the Privacy policy.
What is the SBOM Version Diff?
For release engineers and security reviewers comparing previous and current supplier deliveries.
A version change needs a unique package identity on each side. Missing or duplicate identities stay ambiguous. Local bom-ref values and names alone are never used as proof of identity.
| Accepted input | CycloneDX JSON 1.4, 1.5, 1.6 · SPDX 2.3 JSON |
|---|
| Enforced limits | 5 MB per file · 20 MB per request including upload framing · 20,000 total components · JSON depth 64 · Exactly two files: Previous and Current · Reliable component matching currently requires a valid PURL and supplier context · No vulnerability database queried; no claim of new CVE detection · Metadata array reordering may require review |
|---|
| Processing | Explicit upload to EmbedHarbor · temporary processing · no account required |
|---|
| Not included | Technical document analysis only. No signatures, supplier authenticity, legal compliance or current vulnerability exposure are verified. |
|---|
How it works
- Choose inputs. Select JSON SBOMs or download the synthetic examples. Review the file limits and upload notice.
- Upload & Analyze. The existing EmbedHarbor API validates the request and runs the internal offline analysis engine.
- Review the result. A version change needs a unique package identity on each side. Missing or duplicate identities stay ambiguous. Local bom-ref values and names alone are never used as proof of identity.
- Download your report. Keep the report and engine versions with the delivery. Processing does not create a SaaS product or version.
What it checks
- Both input schemas through sbom-utility
- Upstream structured JSON diff and a separate semantic component comparison
- Added, removed, version and metadata changes
- Resolvable dependency changes and unknown or ambiguous identities
Common errors and fixes
The file is not supported
Use a supported JSON SBOM version; archives, XML and tag-value files are rejected.
Analysis is unavailable or timed out
Retry later or reduce the input size. A failed analysis is never displayed as a clean result.
The result needs review
Inspect the structured findings. An unevaluated check does not mean it passed.
Example output
The result is a structured report. This is the shape of the output you can export; the example reports show the full engine output for a synthetic firmware SBOM.
engine: sbom-utility + EmbedHarbor semantic diff
changes: added, removed, version, metadata, dependency_added, dependency_removed, ambiguous
summary: previousComponents, currentComponents, changes
Privacy and data handling
Clicking Upload & Analyze sends the selected SBOMs to EmbedHarbor for this request. Temporary files are deleted after processing; reports remain in your browser until you leave. No third-party analysis service receives the files. Do not upload secrets.
Frequently asked questions
Why are some components ambiguous?
Names and document-local references do not identify packages across deliveries. Missing PURLs or multiple candidates are shown for review instead of forcing a potentially incorrect match.
Are files sent to third-party analysis platforms?
No. Analysis runs within EmbedHarbor using bundled open-source engines and schemas. External SBOM links are not fetched.
