Saltar al contenido principal

xBOM (Bill of Materials)

The xBOM dashboard provides a unified inventory of all components, cryptographic assets, and AI models discovered across your repositories. Track vulnerabilities, manage VEX statements, export compliance-ready bills of materials, and monitor component changes.

info

xBOM is available on Scale plan and above. It requires enabling plexicus-sbom, plexicus-cbom, or plexicus-aibom scanner bundles.

Source: /Users/jpalanco/Projects/platform/fastapi/routes/xbom.py:6, 34

Three Types of BOMs​

SBOM — Software Bill of Materials​

Generated by: Syft
Contains: All software dependencies across your codebase — libraries, packages, frameworks, and their versions.

What it tracks:

  • Component name and version
  • Software licenses (permissive, copyleft, proprietary, unknown)
  • Known vulnerabilities (CVE mapping)
  • File paths where component is used
  • Package manager (npm, pip, Maven, Go, Cargo, etc.)

Export formats: CycloneDX JSON, SPDX JSON, CSV, PDF attestation

Use cases:

  • Build compliance proofs for customers (e.g., "we use only permissively licensed software")
  • Identify license conflicts in merges
  • Track dependency drift between builds
  • Generate SBOMs for supply chain transparency (NTIA minimum elements)

Source: i18n xbom.yml:21, 73-88

CBOM — Cryptographic Bill of Materials​

Generated by: CycloneDX CBom + OpenGrep Crypto
Contains: All cryptographic algorithms, key sizes, and implementations in your codebase.

What it tracks:

  • Algorithm type (AES, RSA, ECDSA, MD5, SHA-1, etc.)
  • Key size / strength (256-bit, 4096-bit, etc.)
  • Primitive category (encryption, hashing, signing, etc.)
  • Quantum-readiness classification (NIST deadline assessment)
  • Usage context (database encryption, TLS, signing, etc.)

Risk assessment:

  • 🟢 Quantum-safe algorithms (post-quantum cryptography, modern RSA/ECC)
  • 🟡 Deprecated weak algorithms (MD5, SHA-1, RC4, DES)
  • 🔴 Known broken algorithms with deadline risk

Export formats: CycloneDX JSON, SPDX JSON, CSV, PDF attestation

Use cases:

  • Demonstrate quantum-readiness for compliance frameworks (NIST SP 800-131B)
  • Plan cryptographic migration (e.g., SHA-1 → SHA-256)
  • Track deprecated crypto usage across monorepos
  • Supply chain transparency for cryptographic supply chain risk (e.g., EU CRA BSI TR-03183-2)

Source: i18n xbom.yml:28-31, 42-46, shared/tool_bundle_params.py:23

AIBOM — AI Model Bill of Materials​

Generated by: CycloneDX MLBom
Contains: All machine learning models, training datasets, and AI components in your codebase or infrastructure.

What it tracks:

  • Model name and version
  • Model type (LLM, classifier, regression, etc.)
  • Training dataset provenance and lineage
  • Model card status (documentation completeness)
  • External dependencies (Hugging Face, OpenAI, Anthropic, etc.)
  • Security and safety assessment

Risk flags:

  • 🟡 Missing model card (undocumented training data or performance)
  • 🟡 No dataset provenance (unknown training source)
  • 🟡 External API dependency (supply chain risk)
  • 🔴 Unsafe serialization (model injection attacks)

Export formats: CycloneDX JSON, SPDX JSON, CSV, PDF attestation

Use cases:

  • Build AI supply chain transparency (EU AI Act compliance)
  • Identify models with insufficient documentation
  • Track AI model version dependencies (model drift)
  • Supply chain risk on third-party models (e.g., fine-tuned LLMs)

Source: i18n xbom.yml:33-35, shared/tool_bundle_params.py:22

Dashboard Overview​

The xBOM main view shows three tabs, each with an executive summary:

Overview KPIs:

  • Total components (SBOM count)
  • Repositories covered (which repos contribute to BOM)
  • Coverage detail (how many SBOM, CBOM, AIBOM records exist)
  • Quantum readiness (percentage of safe cryptography)
  • License risk (count of copyleft, proprietary, unknown licenses)
  • AI models (count of AI/ML components, risk breakdown)

Charts:

  • License categories (pie: permissive, copyleft, proprietary, unknown)
  • Quantum classification (pie: quantum-safe, quantum-vulnerable, weak/deprecated, unknown)
  • Top vulnerable components (bar: packages with most CVEs)
  • AI providers (bar: count of models per provider — OpenAI, Anthropic, Hugging Face, etc.)

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:1-19

Software Components (SBOM) Tab​

Browsing Components​

  1. Navigate to xBOM → Software (SBOM) tab

  2. Filter by:

    • Repository — Narrow to specific repos
    • License category — Permissive, copyleft, proprietary, unknown
    • Language — Python, JavaScript, Java, etc.
    • Has vulnerabilities — Show only components with known CVEs
    • Risk flags — Restricted license, external API, unpinned version, etc.

  3. Search by component name or Package URL (PURL)

Component Details​

Click a component to see:

  • PURL (Package URL) — Standardized component identifier
  • Hashes — SHA-256, SHA-1 for integrity verification
  • File paths — Where in repositories this component appears
  • Supplier — Package maintainer or organization
  • Source tool — Which scanner discovered it (Syft, Grype, etc.)

VEX (Vulnerability Exploitability Exchange)​

Mark how your organization handles specific vulnerabilities in specific components. This proves to auditors that you've assessed and decided on remediation.

VEX Statement Statuses:

  • Affected — You use the vulnerable component and are working on a fix
  • Fixed — You've patched to a non-vulnerable version
  • Not Affected — Component doesn't use the vulnerable code path
  • Under Investigation — You're still assessing impact

Example: CVE-2024-12345 in log4j → Status: "Not Affected" + Justification: "We only use specific appenders that aren't vulnerable"

To set a VEX statement:

  1. Filter to the component and CVE
  2. Click Set VEX
  3. Select status and enter justification (required for "Not Affected")
  4. Save — statement is recorded in your xBOM and compliance tracking

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:101-118, fastapi/routes/xbom.py:46-54

Watchlists​

Monitor components of interest. Get notified when matching components appear in future scans.

Create a watchlist:

  1. Go to xBOM → Watchlists (or click Watch component from component detail)
  2. Enter pattern (component name or PURL, e.g., "log4j" or "pkg:npm/lodash")
  3. Choose type: Name (substring match) or PURL (exact Package URL match)
  4. Check Notify to receive alerts when component is discovered in new scans
  5. Save

Use cases:

  • Monitor deprecated libraries (e.g., "node-uuid" → renamed to "uuid")
  • Track supply chain risks (e.g., "xz-utils" — watch for compromised versions)
  • Maintain inventory of first-party components (e.g., "acme-internal-*")

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:119-135

Cryptographic Assets (CBOM) Tab​

Browsing Algorithms​

  1. Navigate to xBOM → Cryptographic Assets (CBOM) tab

  2. Filter by:

    • Primitive type — Encryption, hashing, signing, key agreement, etc.
    • Algorithm name — AES, RSA, ECDSA, MD5, SHA-1, etc.
    • Key size — Search by strength (256-bit, 4096-bit, etc.)
    • Quantum classification — Safe, vulnerable, unknown
    • Repository — Narrow by repo

  3. See "Classification Reasons" explaining why algorithm is rated quantum-safe or vulnerable

Risk Assessment​

Quantum-Safe (🟢):

  • Post-quantum cryptography (Kyber, Dilithium, Sphincs+)
  • Modern RSA with sufficient key size (≥2048-bit)
  • ECC P-256, P-384, P-521
  • SHA-256, SHA-384, SHA-512

Quantum-Vulnerable (🔴) — NIST Deadline:

  • RSA < 2048-bit
  • ECC curves < P-256
  • Any reliance on discrete log assumptions

Weak/Deprecated (🟡):

  • MD5 (broken since ~2005; do not use for security)
  • SHA-1 (deprecated for signatures; sunset 2025+)
  • RC4, DES, 3DES
  • Unsupported TLS versions (< 1.2)

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:42-46

AI Models (AIBOM) Tab​

Browsing AI Models​

  1. Navigate to xBOM → AI Models (AIBOM) tab
  2. Filter by:
    • Provider — OpenAI, Anthropic, Hugging Face, local models, etc.
    • Model type — LLM, classifier, embedder, etc.
    • Risk flags — Missing model card, no dataset provenance, external API, unsafe serialization

Model Details​

Click a model to see:

  • Model name & version — Full identifier
  • Provider — Vendor or organization
  • Training datasets — Lineage and provenance
  • Model card — Documentation status
  • Dependencies — External APIs or model dependencies
  • Compliance risk — Security/safety assessment

Export Bill of Materials​

Generate shareable BOMs for audits, customer requests, or supply chain transparency.

Export Formats​

  1. Go to xBOM → Export

  2. Choose format:

    • CycloneDX JSON — Industry standard (NTIA minimum elements, recommended)
    • SPDX JSON — Linux Foundation standard (ISO/IEC 5230 certified)
    • CSV — Spreadsheet-friendly inventory
    • PDF Attestation — Human-readable compliance report with signature

  3. For PDF attestations, select Compliance Profile:

    • EU CRA (BSI TR-03183-2) — EU Cyber Resilience Act proof of cryptography review
    • CISA 2025 — US government supply chain requirements
    • PCI DSS 6.3.2 — Payment card security
    • EU AI Act — AI governance and risk

  4. Click Download

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:73-89

CycloneDX vs SPDX​

AspectCycloneDXSPDX
FocusSupply chain security & vulnerability trackingLicense and dependency disclosure
MetadataRich (VEX, crypto, vulnerabilities, ML models)Comprehensive (licenses, file hashes)
AdoptionNTIA minimum element standard; recommended by CISALinux Foundation standard; preferred by open-source projects
ComplianceEU CRA, PCI DSS, FedRAMPSBOM Act (US), ISO/IEC 5230
Best forVendors proving security posture to enterprisesOpen-source projects licensing transparency

Import Supplier SBOM​

Ingest BOMs from third-party vendors or dependencies to build a comprehensive supply chain map.

  1. Go to xBOM → Import
  2. Upload a CycloneDX or SPDX JSON file
  3. Enter supplier name (e.g., "Acme Corp", "AWS SDK")
  4. Click Import

Results appear in the SBOM tab with supplier attribution. Enables:

  • Transitive dependency tracking (dependencies of your dependencies)
  • Supplier vulnerability correlation
  • End-to-end supply chain visibility

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:90-101

Scan History & Diff​

View how components changed between scans:

  1. Go to xBOM main view
  2. Look for Changes vs previous scan section
  3. See:
    • Added — New components discovered
    • Removed — Components no longer present
    • Changed — Version bumps, license updates, etc.

This helps you:

  • Spot unexpected dependencies added by merges
  • Confirm dependency cleanup worked
  • Track cryptographic upgrade progress

Source: /Users/jpalanco/Projects/platform/frontend/i18n/locales/en/xbom.yml:137-142

Compliance Integration​

xBOM data flows into the Compliance Dashboard:

  • License risk maps to compliance controls (GPL disclosure, proprietary terms)
  • Quantum readiness maps to cryptographic compliance (NIST, EU CRA)
  • VEX statements reduce audit risk by proving assessment of vulnerabilities
  • SBOM exports satisfy customer security questionnaires and audits

Troubleshooting​

"No components yet"
Enable at least one BOM scanner (plexicus-sbom, plexicus-cbom, or plexicus-aibom) on your application and run a scan.

"Missing model card" warning on AIBOM
Your AI models lack documentation. Provide Hugging Face model cards, OpenAI model IDs, or internal model descriptions.

"Unpinned version" on dependencies
Some dependencies don't have locked versions. Use lock files (package-lock.json, poetry.lock, Gemfile.lock) to pin versions and improve reproducibility.

"External API" risk flag
Your code uses external APIs (e.g., OpenAI API, third-party LLM services). Ensure you've assessed vendor security and data handling practices.

See Also​