XBOM, compliance and reporting

XBOM: one inventory for software, cryptography and AI models

A finding tells you something is wrong. An inventory tells you what you ship. XBOM, short for Extended Bill of Materials, is the Plexicus inventory of three kinds of assets in your repositories. Like Plexicus Automation, it works alongside the Validate, Understand, Remediate loop.

Software (SBOM): libraries, packages and dependencies.
Cryptography (CBOM): algorithms, key sizes, primitives and where they are used.
AI Models (AIBOM): machine-learning models with their providers, datasets and licenses.

Open XBOM from the main sidebar. The page is titled “Asset Inventory (XBOM)” and has three tabs: Software (SBOM), Cryptography (CBOM) and AI Models (AIBOM). The selected tab is kept in the URL, so a reload or a shared link opens the same tab, though not your filters. XBOM is available depending on your plan.

Enabling the BOM tools

Each tab stays empty until its tool is enabled and a repository has been scanned, or until you import a supplier BOM with that kind of component. An empty tab names the tool to enable and offers a Go to Connectors button.

The CBOM tool detects cryptography in JavaScript and TypeScript, Go, Ruby, PHP, C and C++, Python and Java code.

What each inventory shows

Tab	Columns	Extra filters
Software (SBOM)	Component, Version, Repository, VEX status, Vulnerabilities, License, Actions	License category
Cryptography (CBOM)	Algorithm, Key size / Params, Primitive, Context / Source, Repository, Compliance risk	Quantum classification
AI Models (AIBOM)	Model, Type, Provider, Version, Datasets, Licenses, Repository, Security / Risk	Provider, Risk flag

Every tab also has a search box and a Repository filter. The SBOM Vulnerabilities column counts active findings whose library name and version match the component, by severity (C, H, M, L). The counts are not links; to see the findings, filter Findings by Library. Licenses fall into five categories: Permissive (such as MIT or Apache-2.0), Weak copyleft (such as LGPL or MPL-2.0), Strong copyleft (such as GPL or AGPL), Proprietary and Unknown.

Each CBOM asset gets a quantum classification:

Quantum Vulnerable: public-key cryptography a quantum computer could break, such as RSA, ECDSA, ECDH, DH and Ed25519.
Deprecated/Weak: broken or weak today, such as MD5, SHA-1, DES, 3DES and RC4.
Quantum Safe: NIST post-quantum standards such as ML-KEM and ML-DSA, plus symmetric and hash primitives that resist quantum attack.
Unknown: not enough information to classify.

AIBOM rows carry risk flags: Serialization Risk (model files such as .pkl or .pt), No Model Card, Unknown License, Restricted License (for example non-commercial or research-only terms), External API (a model called through a provider’s API), No Dataset Provenance and Unpinned Version (empty, “latest”, “main” and similar).

Click a row to open its Details panel: PURL, hashes, file paths, supplier and source tool for software, classification reasons for cryptography, datasets for AI models.

The executive overview

The Executive overview above the tabs shows five KPI cards: Total components, Repositories covered (split into SBOM, CBOM and AIBOM), Quantum readiness, AI models (with how many have risks) and License risk. Four charts follow: License categories, Quantum classification, Top vulnerable components and AI providers.

Two cards need care:

Quantum readiness is the share of all CBOM assets, Unknown included, classified Quantum Safe, scored out of 100 and noted against the NIST 2030/2035 deadlines. The card is green at 80 or above, yellow from 50 to 79 and red below 50. With no CBOM data the card reads 0/100, so confirm the CBOM tool is enabled before you read anything into it.
License risk counts components with strong copyleft, proprietary or unknown licenses. Weak copyleft such as LGPL is not counted. It tells you what to send for legal review; it is not a legal opinion.

A low quantum score is a planning signal. Suppose the CBOM shows RSA-2048 in your identity service (Quantum Vulnerable) and MD5 in a password-reset token generator (Deprecated/Weak). Fix the MD5 first, because it is weak today, and plan the RSA migration against the NIST deadlines.

VEX statements, watchlists and scan-to-scan diff

Your SBOM lists a component with a known CVE. That alone does not mean your product is exploitable. A VEX (Vulnerability Exploitability eXchange) statement records your assessment of one vulnerability in one component, so the next reviewer does not repeat the analysis.

Setting a VEX statement

On the component’s row, open XBOM Software (SBOM) Actions Set VEX . The VEX statement form has Component (prefilled), Vulnerability ID (for example CVE-2024-12345), Status, Justification and an optional Detail. Status starts at Under investigation. Click Save statement.

Status	Use it when	Justification
Affected	The vulnerable code is present and applies to your product, and you are working on it	Optional, but say what you are doing
Not affected	The component is present but the vulnerability does not apply, for example the vulnerable function is never called	Required by the form
Fixed	You upgraded or patched to a version without the vulnerability	Optional, but name the version
Under investigation	You have not finished the assessment	Optional, but say what is being checked

Example: your payments service pulls in a YAML library with a deserialization CVE in its unsafe loader. Your review, for example with Deep Code Analysis (module 5), shows that your code only ever calls the safe loader. Record Not affected with a justification such as “The unsafe loader is never called; every parse uses the safe loader, see the finding’s trace.”

The VEX status column shows the most recent statement for the component. If a component has statements for several vulnerabilities, the column shows only the newest one, whatever vulnerability it covers. A Not affected badge therefore does not clear every CVE in that component, so check its findings in Findings before you treat it as cleared. Saving a statement needs the same write permission as triaging findings.

VEX statements stay in Plexicus. The CycloneDX, SPDX, CSV and PDF exports do not include them, so show reviewers the VEX status in XBOM or record the assessment in your own VEX document.

Watchlists

A watchlist alerts you when a software component (SBOM) you care about shows up in a new scan. Cryptographic assets and AI models do not trigger watchlist alerts. Open XBOM Watchlists , enter a Pattern, choose a Type, leave Notify on match on and click Add watchlist.

Name matches any component whose name contains the pattern, ignoring case. The pattern “log4j” matches log4j-core and log4j-api.
PURL matches components whose package URL starts with the pattern, such as pkg
/lodash.

The Watch component row action on the SBOM tab is a shortcut: it creates a Name entry for that component with notifications on.

An alert fires only when a matching name and version was not present in earlier scans of that repository, so a long-standing component does not alert on every scan, while a new version of it does. Alerts arrive as in-app warning notifications that name the component, its version and the pattern it matched. Good candidates are libraries your team has banned, packages with a history of compromised releases and internal packages you want to trace across teams.

Changes vs previous scan

In the Repository filter, select exactly one repository. A Changes vs previous scan panel appears. It compares that repository’s two most recent scans and lists components as Added, Removed or Changed (the version differs). Check it after a merge to catch a dependency nobody discussed, or after an upgrade to confirm the old version is really gone.

Importing supplier BOMs and exporting

Importing a supplier BOM

Your product contains software you did not build. When a supplier sends a BOM, import it so its components sit next to your own: XBOM Import . The Import supplier SBOM form takes a CycloneDX or SPDX JSON file of up to 20 MB and a required Supplier name. A toast confirms how many components were imported.

In a CycloneDX file, cryptographic-asset components go to the CBOM inventory, machine-learning-model components go to AIBOM, and everything else goes to SBOM. When the same supplier sends an updated BOM, import it again under the same supplier name. Plexicus replaces that supplier’s previous imported snapshot instead of adding duplicates.

Export formats

Choose the tab first, then open Export.

Format	Works on	What you get
CycloneDX JSON	SBOM, CBOM, AIBOM	A CycloneDX 1.6 document
SPDX JSON	SBOM only	An SPDX 2.3 document
CSV	SBOM, CBOM, AIBOM	A spreadsheet of the inventory, downloaded at once
PDF attestation	SBOM, AIBOM (listed on CBOM too, but fails there)	An XBOM Attestation Report scored against a compliance profile

For CycloneDX, SPDX and PDF, a dialog asks for Product name (blank uses the name shown, such as the repository or organization) and Product version (blank uses the export date). For CycloneDX and SPDX, these fields name the root component of the document, so fill in both for anything that leaves your team. The PDF attestation does not print the product name or version. It names only your organization, so send it with the matching CycloneDX export and state the release in your cover note.

What an export covers:

The latest scan snapshot, not history.
The first repository selected in the filter, or the whole organization when none is selected.
For SBOM, one entry per PURL: a package found in several repositories appears once, with its file paths merged as evidence.

Both formats name your product as the root and carry a creation timestamp and your organization. CycloneDX adds a unique serial number and lists your organization as supplier; SPDX uses a unique document namespace instead. Dependency relationships appear only where they were resolved, and the CycloneDX document declares the component list complete but the transitive dependency graph incomplete. That is an accurate statement a reviewer can rely on.

PDF attestation and compliance profiles

Profile	BOM type	Per-component fields checked
EU CRA (BSI TR-03183-2)	SBOM	Name, version, PURL, licenses, hashes, supplier, file paths
CISA 2025	SBOM	Name, version, PURL, licenses, hashes, supplier, source tool
PCI DSS 6.3.2	SBOM	Name, version, repository, source tool
EU AI Act	AIBOM	Name, version, provider, licenses, datasets, model card

The report states the BOM type, organization, generation time and a SHA-256 hash of the BOM content. A Summary section follows, then a completeness score out of 100 for the chosen profile, with a Present, Missing and Coverage table per field and regulatory notes. The score averages field coverage with document checks: root component, spec version, serial number, timestamp, creator, no duplicates, a dependency graph and resolvable dependency references.

The hash covers a CycloneDX rendering made at export time, so it will not match a CycloneDX file you download separately. Do not present it as a way to verify another file.

The completeness score rates the document, not your compliance. The Missing column shows how many components lack each required field. The document checks are folded into the score but not listed, so if every field reads 100% and the score is still lower, the gap is at document level, most often a missing or partial dependency graph. Review the gaps before you send the attestation, and tell the recipient about any you cannot close.

The Compliance view

Choose your frameworks first

The Compliance view only shows the frameworks your organization tracks. Pick them in Settings Organization Regulations : click Edit, select frameworks from the catalog, then click Save changes. Both Configure frameworks buttons on the Compliance tab lead there. Until you select at least one, the tab shows “No compliance frameworks configured”.

The catalog holds 50 frameworks, including NIS2, DORA, CRA, GDPR, PCI DSS v4.0.1, ISO 27001

, SOC 2, NIST CSF, NIST 800-53r5, HIPAA, ENS and ISA/IEC 62443. Some frameworks depend on your plan: they carry a badge naming the plan they require, and selecting one opens an upgrade prompt. Frameworks outside the catalog are added by contacting Plexicus.

How findings are mapped

Mapping happens when Plexicus enriches a finding with AI. Each framework is evaluated, but a framework is attached only when a strict control exists, meaning one that could prevent the vulnerability. Controls that only help detect or respond are left out, and at most one control per framework is recorded. A SQL injection in a login handler can map to an input-validation or secure-development control. It is not mapped to a logging control merely because logging might have noticed the attack.

The result is stored on the finding as Regulation, Control and Control category. Open a finding and scroll to its Compliance & OWASP section, which lists each regulation with its control, control category and a short description. When nothing applies, it reads “This security finding does not activate any applicable compliance policies.” In Findings, All filters lets you filter by Regulation, Control and Control category, and the Regulation filter offers only the frameworks you enabled.

The mapping is AI-generated. Treat it as a strong starting point that a person confirms, especially for any control you plan to cite in an audit.

Reading the Compliance tab

Open Dashboard Compliance . The older Compliance page address redirects here. The filter bar has Repository, Asset type (All assets, Code, Cloud, SCM), Severity and Framework, plus Configure frameworks and Refresh. The tab and some frameworks are available depending on your plan.

Widget	What it shows
Framework cards	Open findings, Critical / High, Fixed, Affected assets and a controls count for each framework
Risk Dashboard	A flow from Total Findings to Fixed and Remaining, then severity, asset group (Code, Cloud, SCM) and framework
Compliance Findings	A heatmap of open findings per repository and framework for your busiest repositories
Findings Trend	Weekly new findings per framework over Last 30 days, Last 90 days (the default), Last 6 months or Last year
Framework Risk Quadrant	Open findings plotted against how many repositories each framework affects
Top Violated Controls	Control, Framework, Category, Severity, Findings and Assets, with the most findings first

Most widgets drill down to Findings with filters applied. A framework card or framework node filters to that regulation, a severity node to that severity, a heatmap cell to the framework and repository, and a Top Violated Controls row to the framework and control. The tab’s Repository and Severity filters carry over. Asset type does not carry over, and drill-downs open the Repo tab of Findings, so switch to the Cloud or SCM tab for those findings. A card that reads “No findings · mapping pending” has no mapped findings yet.

The counts exclude duplicates, sub-findings, false positives and deleted findings, and “open” means not yet solved. Triage quality shows up directly here: a false positive left open inflates a framework’s numbers, and solved findings move to Fixed.

Reports and evidence

Auditors, customers and your own leadership ask for evidence in different shapes. Plexicus gives you three report types beyond the XBOM exports.

The Findings Intelligence Report

In Findings, pick the tab (Repo, SCM, Cloud, Registry or App Pentest), set your filters, then click Findings Download PDF . The report is built in the background. A “Report being generated” toast tells you that you will get an email when it is ready. You then receive an email and an in-app Report Ready notification with a Download report button. Both open a download page in Plexicus that requires you to sign in. If the report is still generating or the link has expired, the page says so, and you can generate it again.

Things to know before you rely on it:

Your organization can request at most 5 reports per hour, shared across all users. Beyond that you see “Rate limit reached”. Each request, including a refused one, restarts the hour, so wait instead of retrying.
The report is written in the organization’s Scan & Report Language, set in Settings Platform . Finding titles and code stay in their source language.
PDF reports are available depending on your plan.

The report opens with a cover page (organization, generation date, total findings, repositories scanned, marked CONFIDENTIAL) and an Executive Summary with total, Critical, High, Medium, Low, Resolved, In Progress and repository counts. Charts include Severity Distribution, the top 5 findings by EPSS, Remediation Status, Findings by Repository and Findings by Language. A Findings Detail table (Severity, Title, Repository, Tool, EPSS, Status) lists up to 500 findings, worst first, while counters and charts still cover every finding in scope. Up to 10 critical findings get a detail section with AI remediation guidance.

Filter before you click. “Critical and High, payments repository, Regulation NIS2” is a report a reviewer can act on. An unfiltered export of a large backlog cuts the table off at 500 rows.

SARIF and CSV exports

Findings Download JSON downloads findings.json, a SARIF 2.1.0 document scoped to the current tab and filters. By default it includes only findings whose status is AI-Analysed. Findings that have moved on to Ready to Fix, Fix Submitted, Issued or Fixed are left out, so use the PDF report when you need to show remediation progress. Use the SARIF file to hand results to another tool that reads SARIF.
Download report on one finding’s detail view gives you a SARIF file for that one finding, handy for a ticket or a code review.
In Assets Repo Scan , the table’s download button exports the filtered repositories as repositories.csv, a ready-made asset list for an auditor.

Findings exports are recorded in the audit log (module 10). AI Pentest reports are covered in module 6.

Supporting regulatory conversations

Conversation	Evidence you can bring from Plexicus
NIS2, on vulnerability handling and supply-chain security	The Compliance tab filtered to NIS2, a Findings Intelligence Report filtered by the NIS2 regulation, the Findings Trend and an SBOM export
DORA Art. 28, on ICT third-party risk	Imported supplier BOMs, SBOM exports, VEX statements on third-party components recorded in XBOM (shown in the app, not in exports) and the Compliance tab filtered to DORA
EU CRA	An SBOM in CycloneDX or SPDX, a PDF attestation with the EU CRA profile and the VEX statements you recorded in XBOM
EU AI Act	The AIBOM with providers, datasets and risk flags, and a PDF attestation with the EU AI Act profile

Key takeaways

XBOM is one inventory with three tabs, Software (SBOM), Cryptography (CBOM) and AI Models (AIBOM), filled by enabling Plexicus SBOM, CBOM and AIBOM on the Connectors page and scanning.
VEX statements record per component and per vulnerability whether you are Affected, Not affected (justification required), Fixed or Under investigation. They do not change finding status, so triage findings separately.
Watchlists alert on newly appearing software components by name or PURL, and the diff compares a repository’s last two scans.
Exports cover the latest snapshot: CycloneDX 1.6 for every tab, SPDX 2.3 for SBOM, CSV, and a PDF attestation whose profile must fit the BOM type.
The Compliance tab shows only the frameworks chosen in Settings, Organization, Regulations, maps findings only to controls that could prevent them, and drills down to the findings mapped to a framework or control.
Findings Intelligence Reports, SARIF and repository CSVs are evidence for NIS2, DORA, CRA and EU AI Act conversations. Plexicus produces the evidence; your auditors judge compliance.