XBOM, Compliance und Reporting

XBOM: ein Inventar für Software, Kryptografie und KI-Modelle

Ein Befund sagt dir, dass etwas nicht stimmt. Ein Inventar sagt dir, was du auslieferst. XBOM, kurz für Extended Bill of Materials, ist das Plexicus-Inventar für drei Arten von Assets in deinen Repositories. Wie Plexicus Automation arbeitet XBOM neben dem Kreislauf aus Validieren, Verstehen und Beheben.

Software (SBOM): Bibliotheken, Pakete und Abhängigkeiten.
Cryptography (CBOM): Algorithmen, Schlüssellängen, Primitive und die Stellen, an denen sie verwendet werden.
AI Models (AIBOM): Machine-Learning-Modelle mit ihren Anbietern, Datensätzen und Lizenzen.

Öffne XBOM in der Hauptseitenleiste. Die Seite heißt „Asset Inventory (XBOM)“ und hat drei Tabs: Software (SBOM), Cryptography (CBOM) und AI Models (AIBOM). Der ausgewählte Tab wird in der URL gespeichert. Ein Neuladen oder ein geteilter Link öffnet also denselben Tab, deine Filter allerdings nicht. Ob XBOM verfügbar ist, hängt von deinem Plan ab.

Die BOM-Tools aktivieren

Jeder Tab bleibt leer, bis sein Tool aktiviert und ein Repository gescannt wurde oder bis du eine Lieferanten-BOM mit dieser Art von Komponenten importierst. Ein leerer Tab nennt das Tool, das du aktivieren musst, und bietet einen Button Go to Connectors an.

Das CBOM-Tool erkennt Kryptografie im Code folgender Sprachen: JavaScript und TypeScript, Go, Ruby, PHP, C und C++, Python und Java.

Was jedes Inventar zeigt

Tab	Spalten	Zusätzliche Filter
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

Jeder Tab hat außerdem ein Suchfeld und einen Filter Repository. Die SBOM-Spalte Vulnerabilities zählt aktive Befunde, deren Bibliotheksname und Version zur Komponente passen, nach Schweregrad (C, H, M, L). Die Zahlen sind keine Links; um die Befunde zu sehen, filterst du Findings nach Library. Lizenzen fallen in fünf Kategorien: Permissive (etwa MIT oder Apache-2.0), Weak copyleft (etwa LGPL oder MPL-2.0), Strong copyleft (etwa GPL oder AGPL), Proprietary und Unknown.

Jedes CBOM-Asset erhält eine Quantenklassifizierung:

Quantum Vulnerable: Public-Key-Kryptografie, die ein Quantencomputer brechen könnte, etwa RSA, ECDSA, ECDH, DH und Ed25519.
Deprecated/Weak: schon heute gebrochen oder schwach, etwa MD5, SHA-1, DES, 3DES und RC4.
Quantum Safe: Post-Quanten-Standards des NIST wie ML-KEM und ML-DSA sowie symmetrische und Hash-Primitive, die Quantenangriffen standhalten.
Unknown: zu wenig Informationen für eine Klassifizierung.

AIBOM-Zeilen tragen Risiko-Flags: Serialization Risk (Modelldateien wie .pkl oder .pt), No Model Card, Unknown License, Restricted License (zum Beispiel Bedingungen nur für nichtkommerzielle Nutzung oder nur für die Forschung), External API (ein Modell, das über die API eines Anbieters aufgerufen wird), No Dataset Provenance und Unpinned Version (leer, „latest“, „main“ und Ähnliches).

Klick auf eine Zeile, um ihr Panel Details zu öffnen: PURL, Hashes, Dateipfade, Lieferant und Quell-Tool bei Software, Gründe für die Klassifizierung bei Kryptografie, Datensätze bei KI-Modellen.

Die Executive overview

Die Executive overview über den Tabs zeigt fünf KPI-Karten: Total components, Repositories covered (aufgeteilt in SBOM, CBOM und AIBOM), Quantum readiness, AI models (mit der Angabe, wie viele davon Risiken haben) und License risk. Darauf folgen vier Diagramme: License categories, Quantum classification, Top vulnerable components und AI providers.

Bei zwei Karten ist Vorsicht geboten:

Quantum readiness ist der Anteil aller CBOM-Assets, Unknown eingeschlossen, die als Quantum Safe klassifiziert sind, bewertet auf einer Skala bis 100 und mit Bezug auf die NIST-Fristen 2030/2035. Die Karte ist ab 80 grün, von 50 bis 79 gelb und unter 50 rot. Ohne CBOM-Daten zeigt die Karte 0/100. Prüf also, ob das CBOM-Tool aktiviert ist, bevor du etwas in den Wert hineinliest.
License risk zählt Komponenten mit starkem Copyleft, proprietären oder unbekannten Lizenzen. Schwaches Copyleft wie LGPL zählt nicht mit. Die Karte zeigt dir, was du zur rechtlichen Prüfung geben solltest; ein Rechtsgutachten ist sie nicht.

Ein niedriger Quantenwert ist ein Planungssignal. Angenommen, die CBOM zeigt RSA-2048 in deinem Identity-Service (Quantum Vulnerable) und MD5 in einem Token-Generator für das Zurücksetzen von Passwörtern (Deprecated/Weak). Behebe zuerst MD5, weil es schon heute schwach ist, und plane die RSA-Migration entlang der NIST-Fristen.

VEX-Statements, Watchlists und Scan-zu-Scan-Vergleich

Deine SBOM listet eine Komponente mit einer bekannten CVE. Das allein heißt noch nicht, dass dein Produkt ausnutzbar ist. Ein VEX-Statement (Vulnerability Exploitability eXchange) hält deine Bewertung einer Schwachstelle in einer Komponente fest, damit der nächste Reviewer die Analyse nicht wiederholen muss.

Ein VEX-Statement setzen

Öffne in der Zeile der Komponente XBOM Software (SBOM) Actions Set VEX . Das Formular VEX statement enthält Component (vorausgefüllt), Vulnerability ID (zum Beispiel CVE-2024-12345), Status, Justification und ein optionales Detail. Status steht anfangs auf Under investigation. Klick auf Save statement.

Status	Wann du ihn nutzt	Justification
Affected	Der verwundbare Code ist vorhanden, betrifft dein Produkt, und du arbeitest daran	Optional, aber beschreib, was du unternimmst
Not affected	Die Komponente ist vorhanden, aber die Schwachstelle greift nicht, zum Beispiel weil die verwundbare Funktion nie aufgerufen wird	Pflichtfeld im Formular
Fixed	Du hast per Upgrade oder Patch auf eine Version ohne die Schwachstelle gewechselt	Optional, aber nenn die Version
Under investigation	Du hast die Bewertung noch nicht abgeschlossen	Optional, aber beschreib, was gerade geprüft wird

Beispiel: Dein Zahlungsservice bindet eine YAML-Bibliothek ein, deren unsicherer Loader eine Deserialisierungs-CVE hat. Deine Prüfung, zum Beispiel mit Deep Code Analysis (Modul 5), zeigt, dass dein Code ausschließlich den sicheren Loader aufruft. Halte Not affected mit einer Begründung fest wie „Der unsichere Loader wird nie aufgerufen; jedes Parsen nutzt den sicheren Loader, siehe Trace des Befunds.“

Die Spalte VEX status zeigt das jüngste Statement zur Komponente. Hat eine Komponente Statements zu mehreren Schwachstellen, zeigt die Spalte nur das neueste, egal welche Schwachstelle es betrifft. Ein Badge Not affected heißt deshalb nicht, dass jede CVE in dieser Komponente ausgeräumt ist. Prüf ihre Befunde unter Findings, bevor du sie als erledigt behandelst. Zum Speichern eines Statements brauchst du dieselbe Schreibberechtigung wie für die Triage von Befunden.

VEX-Statements bleiben in Plexicus. Die Exporte als CycloneDX, SPDX, CSV und PDF enthalten sie nicht. Zeig Reviewern daher den VEX status in XBOM oder halte die Bewertung in deinem eigenen VEX-Dokument fest.

Watchlists

Eine Watchlist alarmiert dich, wenn eine Softwarekomponente (SBOM), die dir wichtig ist, in einem neuen Scan auftaucht. Kryptografische Assets und KI-Modelle lösen keine Watchlist-Alerts aus. Öffne XBOM Watchlists , gib ein Pattern ein, wähle einen Type, lass Notify on match eingeschaltet und klick auf Add watchlist.

Name erfasst jede Komponente, deren Name das Pattern enthält, ohne Rücksicht auf Groß- und Kleinschreibung. Das Pattern „log4j“ erfasst log4j-core und log4j-api.
PURL erfasst Komponenten, deren Package-URL mit dem Pattern beginnt, etwa pkg
/lodash.

Die Zeilenaktion Watch component im Tab SBOM ist eine Abkürzung: Sie legt für diese Komponente einen Eintrag vom Typ Name mit eingeschalteten Benachrichtigungen an.

Ein Alert wird nur ausgelöst, wenn eine passende Kombination aus Name und Version in früheren Scans dieses Repositorys nicht vorhanden war. Eine seit Langem vorhandene Komponente meldet sich also nicht bei jedem Scan, eine neue Version davon aber schon. Alerts kommen als In-App-Warnmeldungen, die die Komponente, ihre Version und das passende Pattern nennen. Gute Kandidaten sind Bibliotheken, die dein Team verboten hat, Pakete mit einer Vorgeschichte kompromittierter Releases und interne Pakete, die du teamübergreifend nachverfolgen willst.

Changes vs previous scan

Wähle im Filter Repository genau ein Repository aus. Daraufhin erscheint ein Panel Changes vs previous scan. Es vergleicht die beiden letzten Scans dieses Repositorys und listet Komponenten als Added, Removed oder Changed (die Version weicht ab). Prüf es nach einem Merge, um eine Abhängigkeit zu entdecken, über die niemand gesprochen hat, oder nach einem Upgrade, um zu bestätigen, dass die alte Version wirklich verschwunden ist.

Lieferanten-BOMs importieren und exportieren

Eine Lieferanten-BOM importieren

Dein Produkt enthält Software, die du nicht selbst gebaut hast. Wenn ein Lieferant dir eine BOM schickt, importiere sie, damit ihre Komponenten neben deinen eigenen stehen: XBOM Import . Das Formular Import supplier SBOM nimmt eine CycloneDX- oder SPDX-JSON-Datei mit bis zu 20 MB und einen verpflichtenden Supplier name entgegen. Eine Toast-Meldung bestätigt, wie viele Komponenten importiert wurden.

In einer CycloneDX-Datei landen Komponenten vom Typ kryptografisches Asset im CBOM-Inventar, Komponenten vom Typ Machine-Learning-Modell in der AIBOM und alles andere in der SBOM. Schickt derselbe Lieferant eine aktualisierte BOM, importiere sie erneut unter demselben Lieferantennamen. Plexicus ersetzt dann den zuvor importierten Snapshot dieses Lieferanten, statt Duplikate anzulegen.

Exportformate

Wähle zuerst den Tab und öffne dann Export.

Format	Funktioniert in	Was du bekommst
CycloneDX JSON	SBOM, CBOM, AIBOM	Ein CycloneDX-1.6-Dokument
SPDX JSON	Nur SBOM	Ein SPDX-2.3-Dokument
CSV	SBOM, CBOM, AIBOM	Eine Tabelle des Inventars, die sofort heruntergeladen wird
PDF attestation	SBOM, AIBOM (auch bei CBOM aufgeführt, schlägt dort aber fehl)	Ein XBOM Attestation Report, bewertet gegen ein Compliance-Profil

Bei CycloneDX, SPDX und PDF fragt ein Dialog nach Product name (leer gelassen, wird der angezeigte Name verwendet, etwa der des Repositorys oder der Organisation) und Product version (leer gelassen, wird das Exportdatum verwendet). Bei CycloneDX und SPDX benennen diese Felder die Root-Komponente des Dokuments; füll also beide aus, wenn etwas dein Team verlässt. Die PDF-Attestierung druckt weder Produktname noch Version. Sie nennt nur deine Organisation. Schick sie daher zusammen mit dem passenden CycloneDX-Export und nenn das Release in deinem Begleitschreiben.

Was ein Export abdeckt:

Den neuesten Scan-Snapshot, keine Historie.
Das erste im Filter ausgewählte Repository oder die gesamte Organisation, wenn keines ausgewählt ist.
Bei SBOM einen Eintrag pro PURL: Ein Paket, das in mehreren Repositories vorkommt, erscheint einmal, und seine Dateipfade werden als Nachweis zusammengeführt.

Beide Formate nennen dein Produkt als Root und enthalten einen Erstellungszeitstempel und deine Organisation. CycloneDX ergänzt eine eindeutige Seriennummer und führt deine Organisation als Lieferant; SPDX nutzt stattdessen einen eindeutigen Document Namespace. Abhängigkeitsbeziehungen erscheinen nur dort, wo sie aufgelöst wurden, und das CycloneDX-Dokument erklärt die Komponentenliste für vollständig, den transitiven Abhängigkeitsgraphen aber für unvollständig. Das ist eine zutreffende Aussage, auf die sich ein Reviewer verlassen kann.

PDF-Attestierung und Compliance-Profile

Profil	BOM-Typ	Geprüfte Felder pro Komponente
EU CRA (BSI TR-03183-2)	SBOM	Name, Version, PURL, Lizenzen, Hashes, Lieferant, Dateipfade
CISA 2025	SBOM	Name, Version, PURL, Lizenzen, Hashes, Lieferant, Quell-Tool
PCI DSS 6.3.2	SBOM	Name, Version, Repository, Quell-Tool
EU AI Act	AIBOM	Name, Version, Anbieter, Lizenzen, Datensätze, Model Card

Der Bericht nennt den BOM-Typ, die Organisation, den Erstellungszeitpunkt und einen SHA-256-Hash des BOM-Inhalts. Darauf folgen ein Abschnitt Summary und ein Vollständigkeitswert auf einer Skala bis 100 für das gewählte Profil, mit einer Tabelle aus Present, Missing und Coverage pro Feld sowie regulatorischen Hinweisen. Der Wert mittelt die Feldabdeckung mit Dokumentprüfungen: Root-Komponente, Spec-Version, Seriennummer, Zeitstempel, Ersteller, keine Duplikate, ein Abhängigkeitsgraph und auflösbare Abhängigkeitsreferenzen.

Der Hash bezieht sich auf eine CycloneDX-Darstellung, die beim Export erzeugt wird. Er stimmt daher nicht mit einer CycloneDX-Datei überein, die du separat herunterlädst. Präsentiere ihn nicht als Möglichkeit, eine andere Datei zu verifizieren.

Der Vollständigkeitswert bewertet das Dokument, nicht deine Compliance. Die Spalte Missing zeigt, wie vielen Komponenten das jeweilige Pflichtfeld fehlt. Die Dokumentprüfungen fließen in den Wert ein, werden aber nicht aufgelistet. Steht also jedes Feld auf 100 % und der Wert ist trotzdem niedriger, liegt die Lücke auf Dokumentebene, meist ein fehlender oder unvollständiger Abhängigkeitsgraph. Prüf die Lücken, bevor du die Attestierung verschickst, und informiere den Empfänger über alle, die du nicht schließen kannst.

Die Compliance-Ansicht

Wähle zuerst deine Frameworks

Die Compliance-Ansicht zeigt nur die Frameworks, die deine Organisation verfolgt. Wähle sie unter Settings Organization Regulations aus: Klick auf Edit, wähle Frameworks aus dem Katalog und klick dann auf Save changes. Beide Buttons Configure frameworks im Tab Compliance führen dorthin. Solange du keines ausgewählt hast, zeigt der Tab „No compliance frameworks configured“.

Der Katalog umfasst 50 Frameworks, darunter NIS2, DORA, CRA, GDPR, PCI DSS v4.0.1, ISO 27001

, SOC 2, NIST CSF, NIST 800-53r5, HIPAA, ENS und ISA/IEC 62443. Einige Frameworks hängen von deinem Plan ab: Sie tragen ein Badge mit dem Plan, den sie voraussetzen, und ihre Auswahl öffnet einen Upgrade-Hinweis. Für Frameworks außerhalb des Katalogs wendest du dich an Plexicus.

Wie Befunde zugeordnet werden

Die Zuordnung erfolgt, wenn Plexicus einen Befund mit KI anreichert. Jedes Framework wird bewertet, aber nur dann zugeordnet, wenn es eine strikte Kontrolle gibt, also eine, die die Schwachstelle verhindern könnte. Kontrollen, die nur beim Erkennen oder Reagieren helfen, bleiben außen vor, und pro Framework wird höchstens eine Kontrolle festgehalten. Eine SQL-Injection in einem Login-Handler kann einer Kontrolle für Eingabevalidierung oder sichere Entwicklung zugeordnet werden. Einer Logging-Kontrolle wird sie nicht zugeordnet, nur weil Logging den Angriff hätte bemerken können.

Das Ergebnis wird am Befund als Regulation, Control und Control category gespeichert. Öffne einen Befund und scroll zum Abschnitt Compliance & OWASP, der jede Regulierung mit ihrer Kontrolle, der Kategorie der Kontrolle und einer kurzen Beschreibung auflistet. Trifft nichts zu, steht dort „This security finding does not activate any applicable compliance policies.“ Unter Findings kannst du über All filters nach Regulation, Control und Control category filtern, und der Filter Regulation bietet nur die Frameworks an, die du aktiviert hast.

Die Zuordnung ist KI-generiert. Betrachte sie als soliden Ausgangspunkt, den ein Mensch bestätigt, besonders bei jeder Kontrolle, die du in einem Audit anführen willst.

Den Tab Compliance lesen

Öffne Dashboard Compliance . Die ältere Adresse der Compliance-Seite leitet hierher weiter. Die Filterleiste enthält Repository, Asset type (All assets, Code, Cloud, SCM), Severity und Framework sowie Configure frameworks und Refresh. Der Tab und einige Frameworks sind je nach Plan verfügbar.

Widget	Was es zeigt
Framework-Karten	Open findings, Critical / High, Fixed, Affected assets und die Anzahl der Kontrollen für jedes Framework
Risk Dashboard	Einen Fluss von Total Findings zu Fixed und Remaining, dann nach Schweregrad, Asset-Gruppe (Code, Cloud, SCM) und Framework
Compliance Findings	Eine Heatmap der offenen Befunde pro Repository und Framework für deine am stärksten belasteten Repositories
Findings Trend	Neue Befunde pro Woche und Framework über Last 30 days, Last 90 days (Standard), Last 6 months oder Last year
Framework Risk Quadrant	Offene Befunde, aufgetragen gegen die Anzahl der Repositories, die das jeweilige Framework betrifft
Top Violated Controls	Control, Framework, Category, Severity, Findings und Assets, die mit den meisten Befunden zuerst

Die meisten Widgets führen per Drill-down zu Findings mit gesetzten Filtern. Eine Framework-Karte oder ein Framework-Knoten filtert auf diese Regulierung, ein Schweregrad-Knoten auf diesen Schweregrad, eine Heatmap-Zelle auf Framework und Repository und eine Zeile in Top Violated Controls auf Framework und Kontrolle. Die Filter Repository und Severity des Tabs werden übernommen. Asset type wird nicht übernommen, und Drill-downs öffnen unter Findings den Tab Repo. Für Cloud- oder SCM-Befunde wechselst du daher in den Tab Cloud oder SCM. Eine Karte mit „No findings · mapping pending“ hat noch keine zugeordneten Befunde.

Die Zahlen schließen Duplikate, Unterbefunde, False Positives und gelöschte Befunde aus, und „offen“ heißt: noch nicht gelöst. Die Qualität der Triage zeigt sich hier direkt: Ein offen gelassenes False Positive bläht die Zahlen eines Frameworks auf, und gelöste Befunde wandern zu Fixed.

Berichte und Nachweise

Auditoren, Kunden und deine eigene Führungsebene verlangen Nachweise in unterschiedlicher Form. Plexicus bietet dir neben den XBOM-Exporten drei Berichtsarten.

Der Findings Intelligence Report

Wähle unter Findings den Tab (Repo, SCM, Cloud, Registry oder App Pentest), setz deine Filter und klick dann auf Findings Download PDF . Der Bericht wird im Hintergrund erstellt. Eine Toast-Meldung „Report being generated“ teilt dir mit, dass du eine E-Mail bekommst, sobald er fertig ist. Danach erhältst du eine E-Mail und eine In-App-Benachrichtigung Report Ready mit dem Button Download report. Beide öffnen in Plexicus eine Download-Seite, für die du angemeldet sein musst. Wird der Bericht noch erstellt oder ist der Link abgelaufen, sagt dir die Seite das, und du kannst ihn erneut erstellen.

Das solltest du wissen, bevor du dich darauf verlässt:

Deine Organisation kann höchstens 5 Berichte pro Stunde anfordern, für alle Nutzer zusammen. Darüber hinaus siehst du „Rate limit reached“. Jede Anfrage, auch eine abgelehnte, startet die Stunde neu. Warte also, statt es erneut zu versuchen.
Der Bericht wird in der Scan & Report Language der Organisation verfasst, die du unter Settings Platform festlegst. Titel von Befunden und Code bleiben in ihrer Ausgangssprache.
PDF-Berichte sind je nach Plan verfügbar.

Der Bericht beginnt mit einem Deckblatt (Organisation, Erstellungsdatum, Gesamtzahl der Befunde, gescannte Repositories, als CONFIDENTIAL markiert) und einer Executive Summary mit der Gesamtzahl sowie den Zahlen für Critical, High, Medium, Low, Resolved, In Progress und Repositories. Zu den Diagrammen gehören Severity Distribution, die Top 5 der Befunde nach EPSS, Remediation Status, Findings by Repository und Findings by Language. Eine Tabelle Findings Detail (Severity, Title, Repository, Tool, EPSS, Status) listet bis zu 500 Befunde auf, die schwersten zuerst, während Zähler und Diagramme weiterhin jeden Befund im Scope abdecken. Bis zu 10 kritische Befunde erhalten einen eigenen Detailabschnitt mit KI-Hinweisen zur Behebung.

Filtere, bevor du klickst. „Critical und High, Zahlungs-Repository, Regulation NIS2“ ist ein Bericht, mit dem ein Reviewer arbeiten kann. Ein ungefilterter Export eines großen Backlogs schneidet die Tabelle nach 500 Zeilen ab.

SARIF- und CSV-Exporte

Findings Download JSON lädt findings.json herunter, ein SARIF-2.1.0-Dokument, das auf den aktuellen Tab und die aktuellen Filter beschränkt ist. Standardmäßig enthält es nur Befunde mit dem Status AI-Analysed. Befunde, die bereits den Status Ready to Fix, Fix Submitted, Issued oder Fixed erreicht haben, fehlen. Nutze also den PDF-Bericht, wenn du den Fortschritt der Behebung zeigen musst. Mit der SARIF-Datei übergibst du Ergebnisse an ein anderes Tool, das SARIF liest.
Download report in der Detailansicht eines einzelnen Befunds liefert dir eine SARIF-Datei für genau diesen Befund, praktisch für ein Ticket oder ein Code-Review.
Unter Assets Repo Scan exportiert der Download-Button der Tabelle die gefilterten Repositories als repositories.csv, eine fertige Asset-Liste für Auditoren.

Exporte von Befunden werden im Audit-Log festgehalten (Modul 10). Berichte aus AI Pentest behandelt Modul 6.

Regulatorische Gespräche unterstützen

Gespräch	Nachweise, die du aus Plexicus mitbringen kannst
NIS2, zu Schwachstellenmanagement und Sicherheit der Lieferkette	Der Tab Compliance gefiltert auf NIS2, ein Findings Intelligence Report gefiltert nach der Regulierung NIS2, der Findings Trend und ein SBOM-Export
DORA Art. 28, zum IKT-Drittparteienrisiko	Importierte Lieferanten-BOMs, SBOM-Exporte, in XBOM festgehaltene VEX-Statements zu Drittanbieterkomponenten (in der App sichtbar, nicht in Exporten) und der Tab Compliance gefiltert auf DORA
EU CRA	Eine SBOM in CycloneDX oder SPDX, eine PDF-Attestierung mit dem Profil EU CRA und die VEX-Statements, die du in XBOM festgehalten hast
EU AI Act	Die AIBOM mit Anbietern, Datensätzen und Risiko-Flags sowie eine PDF-Attestierung mit dem Profil EU AI Act

Das Wichtigste in Kürze

XBOM ist ein Inventar mit drei Tabs, Software (SBOM), Cryptography (CBOM) und AI Models (AIBOM). Befüllt wird es, indem du Plexicus SBOM, CBOM und AIBOM auf der Seite Connectors aktivierst und scannst.
VEX-Statements halten pro Komponente und pro Schwachstelle fest, ob der Status Affected, Not affected (Begründung erforderlich), Fixed oder Under investigation lautet. Sie ändern nicht den Status von Befunden; triagiere Befunde also separat.
Watchlists melden neu auftauchende Softwarekomponenten nach Name oder PURL, und der Vergleich stellt die letzten beiden Scans eines Repositorys gegenüber.
Exporte decken den neuesten Snapshot ab: CycloneDX 1.6 für jeden Tab, SPDX 2.3 für SBOM, CSV und eine PDF-Attestierung, deren Profil zum BOM-Typ passen muss.
Der Tab Compliance zeigt nur die Frameworks, die unter Settings, Organization, Regulations ausgewählt sind, ordnet Befunde nur Kontrollen zu, die sie verhindern könnten, und führt per Drill-down zu den Befunden, die einem Framework oder einer Kontrolle zugeordnet sind.
Findings Intelligence Reports, SARIF und Repository-CSVs sind Nachweise für Gespräche zu NIS2, DORA, CRA und EU AI Act. Plexicus liefert die Nachweise; deine Auditoren beurteilen die Compliance.