Create. Inspect. Compare. Edit. Validate. Sign.
BOM Workbench is a universal, browser-based engineering workbench for Software Bill of Materials (SBOMs). It seamlessly unifies CycloneDX 1.7, SPDX 2.3 JSON, and SPDX 3.0.1 JSON-LD into a single normalized analysis and visualization engine without fragmenting user experience.
Getting Started
Choose the workflow that matches what you want to achieve.
📂 Inspect Any BOM
Click Open BOM to auto-detect and load any CycloneDX 1.x, SPDX 2.3, or SPDX 3.0 document. Or select ⚡ Samples to immediately explore reference BOMs.
🛠 Create BOM from Source
Click Create BOM to scan a local repository once and generate CycloneDX 1.7, SPDX 2.3, or SPDX 3.0 JSON-LD.
⚖ 3-Way Cross-Format Compare
Click Compare BOMs to compute deep structural and metadata deltas between releases or across differing standards (e.g. CycloneDX ↔ SPDX 2.3 ↔ SPDX 3.0).
🔏 Axiom Quantum-Safe Signing
Click Axiom Sign to sign the active BOM with Post-Quantum ML-DSA-65 (FIPS 204) and generate coordinated NIST OSCAL assessment evidence.
BOM Formats & Standards Support
BOM Workbench provides comprehensive, native support for modern SBOM standards, treating each specification as a first-class citizen:
CycloneDX (1.4 – 1.7)
Ecosystem: OWASP / ECMA-424 standard.
Structure: Hierarchical component tree, metadata, purls, hashes, licenses, evidence, dependencies, external references.
Export: Native CycloneDX 1.7 JSON.
SPDX 2.3 JSON
Ecosystem: Linux Foundation / ISO/IEC 5962:2021.
Structure: Flat package elements, document describes, purl externalRefs, checksums, extracted/declared licenses, spdxElementId relationship graph.
Export: Native SPDX 2.3 JSON.
SPDX 3.0.1 (Core + Software)
Ecosystem: SPDX 3.x modular semantic graph.
Structure: JSON-LD @graph structure, SpdxDocument, Element, SoftwareArtifact, Package, externalIdentifier (PURL/CPE), relationship objects.
Export: Native SPDX 3.0.1 JSON-LD.
Universal Normalization Architecture
CycloneDX 1.7 ──────┐
│
SPDX 2.3 JSON ──────┼──► [ Format Adapters ] ──► [ Normalized BOM Model ] ──► [ BOM Workbench ]
│ │ ├─ Overview & Metrics
SPDX 3.0 JSON-LD ───┘ │ ├─ Component Inventory
│ ├─ 4 Graph Visualizations
Project Folder ──► [ Multi-Lang Analyzer ] ──────────────┘ ├─ 3-Way Cross-Format Compare
│ ├─ Inspector & Live Edits
└──► [ Multi-Format Generators ] └─ Axiom ML-DSA-65 Signing
├─ CycloneDX 1.7
├─ SPDX 2.3
└─ SPDX 3.0 JSON-LD
Format Auto-Detection
When you open a file using Open BOM or drag-and-drop, the Workbench automatically determines the exact document type without requiring manual format selection:
- SPDX 3.0 JSON-LD: Detects JSON documents containing @graph with @context referencing SPDX 3.0 namespaces or typed SPDX 3.0 elements (e.g. SpdxDocument, software_Package).
- SPDX 2.3 JSON: Detects top-level spdxVersion starting with "SPDX-2." and SPDXID identifiers.
- CycloneDX 1.x: Detects top-level "bomFormat": "CycloneDX" or specVersion (1.4, 1.5, 1.6, 1.7).
Interface Map
The application uses an ergonomic 3-pane engineering layout optimized for high-density dependency analysis.
GLOBAL HEADER (Brand • Theme • Open • Samples Dropdown • Create • Axiom Sign • Save As • Validate) ↓ NAVIGATOR (Left) | MAIN WORKSPACE (Center) | INSPECTOR (Right) ↓ STATUS BAR (Active Spec • Component Counts • Working State • Integrity Indicator)
Global Header Controls
| Control | Purpose & Behavior |
|---|---|
| Brand & Format Badge | Displays BOM Workbench identity and the actively loaded format (e.g. CycloneDX 1.7, SPDX 2.3, or SPDX 3.0). |
| Active Document Indicator | Shows the loaded file name, icon, and an amber Modified pill when in-memory edits exist. |
| ☀️ Light / 🌙 Dark | Switches the application theme with instant CSS token updates across all panes and graphs. |
| 📂 Open BOM | Prompts file picker and auto-detects CycloneDX 1.x, SPDX 2.3 JSON, or SPDX 3.0 JSON-LD. |
| ⚡ Samples Dropdown | Consolidated menu offering instant loading of reference BOMs:
|
| 🛠️ Create BOM | Opens the source repository analysis engine for multi-language detection and tri-format generation. |
| 🔏 Axiom Sign | Opens the post-quantum signing workflow to cryptographically sign the active BOM and produce OSCAL assessment evidence. |
| 💾 Save As | Downloads the current in-memory BOM in its active format (CycloneDX, SPDX 2.3, or SPDX 3.0). |
| ✓ Validate | Runs structural schema, taxonomy, and graph resolution diagnostics. |
Navigator Views
- Overview — high-level health metrics, license distribution, hash coverage, and document metadata.
- Components — searchable, filterable table of all discovered software components and packages.
- Relationships — 4-mode visual dependency graph and sortable tabular relationship matrix.
- Raw JSON — syntax-highlighted editor displaying the exact source representation of the active BOM.
- Create BOM — multi-language source scanning and multi-format BOM generation.
- Compare BOMs — 3-way cross-format and release-to-release delta comparison workspace.
Opening and Exploring a BOM
Empty State
When no BOM is currently loaded, the workbench presents immediate action cards (Open BOM, Samples, Create BOM, Compare BOMs) and an interactive drop zone supporting file drag-and-drop.
Overview Tab
The Overview tab delivers an instant quality audit: specification version, component counts, dependency counts, root application package, licensing coverage, cryptographic hash completeness, supplier information, and authoring tools.
Components Tab
Search and filter packages by name, ecosystem, group, or Package URL (PURL). Selecting any component opens it in the right-side Inspector.
Relationships Tab
Displays resolved dependencies via 4 specialized graph layout algorithms or a detailed tabular matrix. Direct and transitive links are resolved uniformly whether parsed from CycloneDX dependencies, SPDX 2.3 relationships, or SPDX 3.0 Relationship objects.
Dependency Visualizations (4 Modes)
BOM Workbench provides four purpose-built visualization modes that project the canonical dependency graph into different analytical perspectives:
| Mode | Core Analytical Purpose | Interactive Controls |
|---|---|---|
| 1. Dependency Layers | Topological hierarchy and dependency depth using smooth cubic Bézier DAG splines. | Orientation toggle (↔ L-to-R / ↕ T-to-B), Zoom, Pan, Fit, Upstream (amber) and Downstream (cyan) path highlighting. |
| 2. Focus / Neighborhood | Targeted subgraph isolation around a specific component without canvas clutter. | Hop depth (1, 2, 3, All), Direction (Both, Dependencies ↓, Dependents ↑), ← Back navigation, 🎯 Focus Root. |
| 3. Grouped Dependencies | Architectural clustering for large BOMs by branch, scope, or namespace. | Group by Dependency Branch, Direct / Transitive Scope, or Namespace / Scope; Expand/Collapse cards; drill-down. |
| 4. Physics / Force-Directed | Exploratory network clustering driven by real-time force simulation. | Presets (Balanced, Compact, Spread, Clusters), Scope (Full Graph / Neighborhood), ❄ Freeze, ♨ Reheat, Node Pinning (📌). |
Component Enrichment, Provenance, & Editing
BOM Workbench provides a disciplined, high-assurance metadata enrichment and human editing lifecycle. It operates under one strict engineering rule:
1. Discovery First Engine (⚡ Enrich from Local Evidence)
Before presenting an attribute as missing, BOM Workbench scans available authoritative project evidence files to derive accurate metadata without guessing:
Authoritative Project Files Supported
• package.json & package-lock.json (npm/yarn/pnpm manifests, lockfile packages, integrity hashes)
• Cargo.toml & Cargo.lock (Rust crates, authors, licenses)
• pom.xml (Maven groupId, artifactId, versions, licenses)
• LICENSE, COPYING, LICENSE.txt (Exact SPDX identifier matching and copyright notices)
Strict Guard Rail (Zero Hallucination)
When authoritative evidence is missing, fields remain explicitly Not specified or unknown. The workbench never guesses, assumes, or extrapolates unverified package coordinates.
2. Five-Origin Field Provenance System
Every standard component attribute tracks its origin, evidence source, confidence score, and modification history:
| Provenance Origin | Badge Indicator | Description & Evidence Chain |
|---|---|---|
| Imported | 📦 Imported | Loaded directly from the original CycloneDX or SPDX bill of materials file. |
| Discovered | ⚡ Discovered | Authoritatively matched and derived from local project manifests (e.g. package.json, LICENSE). |
| Manually Asserted | ✏️ Asserted | Entered or overridden by a human operator, accompanied by documented source evidence and governance notes. |
| Derived | 🔗 Derived | Deterministically computed by workbench algorithms (e.g. standard PURL derived from verified package coordinates). |
| Unknown | ❓ Unknown | No authoritative evidence or human assertion present; field remains explicitly unspecified. |
Hovering any provenance badge in the Component Inspector reveals a detailed inspection tooltip displaying the exact origin, source document, confidence rating, file/field evidence, timestamp, and count of prior revisions.
3. Component Edit Modal (✏️ Edit)
Clicking the ✏️ Edit button in the Inspector header opens the dedicated Component Metadata Modal:
⚠️ Identity-Sensitive Coordinate Alerts
Altering core identity coordinates (Name, Version, PURL, or CPE) displays a real-time warning alerting the user that identity shifts impact downstream correlation, Merkle tree verification, and existing cryptographic signatures.
Strict Decoupling: Manufacturer !== Supplier
Maintains distinct separation between the Manufacturer (creator / author entity) and the Supplier (distributor / vendor entity).
License Governance: Declared vs Concluded
Distinguishes the upstream declared license (licenseDeclared) from human legal decisions (licenseConcluded). Includes one-click quick chips (MIT, Apache-2.0, BSD-3-Clause, GPL-3.0, Proprietary).
🛡️ Protected Cryptographic Evidence Layer
Cryptographic checksums (SHA-256, SHA-512) are enforced as read-only verifiable evidence. They cannot be forged or typed as arbitrary plain text in the edit interface.
4. Table Filtering & Enrichment Indicators
In the Components Tab, packages feature real-time status indicators and a dedicated enrichment filter:
- Enrichment Filter Dropdown: Filter between All Components, Needs Enrichment (missing version, license, description, or hashes), and Complete.
- Status / Enrichment Column: Highlights ✓ Complete or specific missing attributes (e.g. ⚠ Missing license, desc).
- Dedicated Manufacturer Column: Displays the component author/creator distinctly from the distributor.
Cross-Format Export Engine
BOM Workbench allows exporting the active normalized configuration model into any standard specification format, preserving all enriched attributes, human assertions, and provenance metadata.
CycloneDX 1.7 (ECMA-424)
Full schema projection with distinct manufacturer & supplier objects, declared licenses, hashes, and round-trip provenance recorded under properties (bom-workbench:provenance).
SPDX 2.3 JSON (ISO/IEC 5962)
Generates standard packages with packageSupplier, originator, licenseDeclared, licenseConcluded, copyrightText, checksums, and package manager external refs.
SPDX 3.0 JSON-LD
Produces a modern JSON-LD semantic graph with SoftwarePackage nodes, verifiedUsing hashes, originatedBy, suppliedBy, and declared/concluded license links.
Create BOM from Project Folder (Tri-Format)
The Create BOM engine analyzes local source repositories, identifies language manifests and source references, builds an evidence-backed dependency model, and generates valid SBOMs in your format of choice.
Single-Pass Discovery Architecture
The repository is analyzed exactly once. The normalized discovery model can then be exported into any supported standard without rescanning:
CycloneDX 1.7
Generates an OWASP CycloneDX 1.7 JSON document with complete metadata.component, components list, hashes, and resolved dependencies graph.
SPDX 2.3
Generates a Linux Foundation SPDX 2.3 JSON document with DESCRIBES and DEPENDS_ON relationship declarations.
SPDX 3.0.1 JSON-LD
Generates an SPDX 3.0.1 JSON-LD semantic graph containing SpdxDocument, software_Package elements, and explicit Relationship objects.
Workflow Steps
- 📁 Select Project Folder: Choose any local source repository directory.
- ⚡ Load Sample Mixed Project: Instant multi-language demonstration project.
- Choose Output Format: Select CycloneDX 1.7, SPDX 2.3, or SPDX 3.0 via the Output Format radio control.
- 🛡️ Generate BOM: Compiles the discovery model into the chosen specification.
- 🚀 Open in Workbench: Loads the generated BOM directly into the inspector and visualizer for instant analysis.
- 💾 Save JSON: Downloads the generated BOM file directly to disk.
Compare BOMs — 3-Way Cross-Format Deltas
Compare BOMs enables deep structural diffing between two documents. It supports both release-to-release version comparison and cross-format migration auditing (e.g. CycloneDX ↔ SPDX 2.3 ↔ SPDX 3.0).
Supported Comparison Matrix
| Baseline (A) | Target (B) | Primary Use Case |
|---|---|---|
| CycloneDX 1.x | CycloneDX 1.7 | Release version diffing and dependency upgrade verification. |
| CycloneDX 1.7 | SPDX 2.3 | Cross-standard fidelity check and translation auditing. |
| CycloneDX 1.7 | SPDX 3.0 | Next-gen format transition and software profile evaluation. |
| SPDX 2.3 | SPDX 3.0 | SPDX 2.x to 3.x migration verification with 100% component equivalence. |
Comparison Deltas & Visual Indicators
| Delta Status | Meaning | Visual Theme |
|---|---|---|
| ADDED | Package or relationship present in Target (B), absent in Baseline (A). | Emerald Green |
| REMOVED | Package or relationship present in Baseline (A), absent in Target (B). | Crimson Red |
| CHANGED | Matched component with modified version, hash, license, or dependencies. | Amber / Gold |
| UNCHANGED | Identical component identity and properties across both documents. | Neutral Gray |
Comparison Views
- Components Diff: Field-level differences for versions, licenses, PURLs, and checksums.
- Relationships Diff: Visual delta graph showing green added edges, red removed edges, and modified dependency sub-trees.
- Metadata Diff: Document-level comparisons including timestamps, toolchains, suppliers, and format specifications.
- Raw Diff: Side-by-side formatted JSON comparison.
- 📊 Metrics & Analytics: Executive KPI metric tiles (Stability Ratio, Volatility Index, Net Growth, Mutation Density, Transitive Bloat Factor), vendored Chart.js visual graphics (Component Churn, SemVer Upgrade Severity, License Compliance Shifts, Identity Resolution Confidence), and interactive drilldown tables for 🚨 Silent Hash Drift (unversioned tampering) and ⚠️ Breaking Changes.
- Export Comparison Report: Downloads a comprehensive CSV or Markdown change audit report including all executive KPI metrics.
Axiom Sign & Post-Quantum Assessment Evidence
The Axiom Sign capability equips BOM Workbench with quantum-safe cryptographic signing and compliance evidence generation directly in the browser.
Coordinated Evidence Bundle
When you sign a BOM (CycloneDX, SPDX 2.3, or SPDX 3.0), Axiom performs SHA-256 canonical hashing, generates an ML-DSA-65 keypair, executes digital signing, verifies the signature, and exports three coordinated compliance artifacts:
1. Active BOM Document
The exact source BOM file in its native format (.cyclonedx.json, .spdx.json, or .spdx3.json) representing the canonical subject of assessment.
2. Axiom Signature Envelope
signature.json containing the ML-DSA-65 public key, SHA-256 document digest, cryptographic signature, and verification parameters.
3. NIST OSCAL Assessment Results
oscal.assessment-results.json formatted according to NIST OSCAL 1.1.0 standards, linking the signature to security controls and compliance findings.
Validation & Merkle Tree Cryptographic Verification
Clicking ✓ Validate opens the dual-pane Validation & Verification Modal, providing both in-depth structural linting and cryptographic disk verification:
Tab 1: Schema & Structural Diagnostics
- Specification Compliance: Schema integrity check for CycloneDX 1.x, SPDX 2.3, or SPDX 3.0.
- Identifier Uniqueness: Verifies unique bom-ref, SPDXID, and @id definitions across all nodes.
- Graph Resolution: Detects dangling dependency references and unresolved package links.
- Cryptographic & License Hygiene: Checks hash algorithm validity, checksum formats, and valid SPDX license identifiers.
Tab 2: Local Folder & Merkle Tree Verification
Verify that physical files on your local filesystem match the cryptographic hashes recorded inside your Software Bill of Materials:
- Directory Scanning: Select a local folder using the Native File System Access API or click ⚡ Use Loaded Project to test against the in-memory scanned project.
- SHA-256 Digest Verification: Computes real-time SHA-256 hashes for all disk files and compares them against declared component hashes.
- Tamper & Missing File Detection: Flags files as MATCH ✓, MISMATCH ✕ (Tampered), MISSING ⚠, or UNTRACKED ℹ.
- Canonical Binary Merkle Tree: Constructs a deterministic binary Merkle Tree from canonically sorted leaf hashes (
SHA-256(canonicalPath + ":" + fileSha256)) and computes a 256-bit Merkle Root for high-assurance supply chain attestation. - One-Click Root Export: Copy the Merkle root hash directly to your clipboard to cross-reference with CI/CD attestation logs, transparency logs, or release notes.
Progress, Status & Feedback
The workbench provides comprehensive visual indicators during all asynchronous operations:
Top Progress Bar
Determinate and indeterminate progress bar directly below the global header.
Floating Progress Toast
Detailed step-by-step modal showing active phase, scanned file count, and completion percentage.
Status Bar Activity
Persistent bottom bar showing active format, component counts, working spinner, and validation status.
Modified Pill
Amber indicator indicating unsaved in-memory edits awaiting export or signing.
Visual Language & Design Tokens
BOM Workbench is styled with a refined, token-based design system supporting automatic dark/light theme switching with zero external CSS dependencies.
| Design Token | Primary Semantic Meaning |
|---|---|
| Primary Blue | Navigation, active selections, brand accents, primary buttons. |
| Emerald Green | Valid status, added components/links, high confidence, verified signatures. |
| Amber / Gold | Modified state, changed components, warnings, upstream dependents. |
| Crimson Red | Removed elements, validation errors, invalid signatures, failing checks. |
| Purple | Cross-format comparison, delta analysis, format transition workflows. |
| Cyan | Downstream dependencies, post-quantum ML-DSA-65 cryptography, quantum evidence. |
Suggested Engineering Workflow
| Step | Phase | Recommended Actions |
|---|---|---|
| 1 | Ingest / Create | Open an existing BOM (CycloneDX / SPDX), load a sample, or run Create BOM on a project folder. |
| 2 | Explore & Inspect | Check quality audit metrics in Overview, query components by enrichment status, and explore hierarchy across 4 graph layouts. |
| 3 | Enrich & Assert | Run Enrich from Local Evidence to discover missing metadata authoritatively. Use Edit to fill human evidence gaps, assert licenses, and record governance provenance. |
| 4 | Validate | Run structural validation and physical directory Merkle tree verification to detect file tampering. |
| 5 | Compare | Open Compare BOMs to audit changes across releases, analyze visual KPI charts, and detect silent hash drift. |
| 6 | Sign & Export | Sign with Axiom Sign (ML-DSA-65) for verifiable OSCAL evidence, then export to CycloneDX 1.7, SPDX 2.3, or SPDX 3.0 with full model preservation. |
About This Help System
This documentation is fully self-contained within BOM Workbench. It operates completely offline with zero external network requests, CDNs, or servers, ensuring strict privacy and compliance for isolated enterprise environments.