BOMs

Stücklisten (Bills of Materials, BOMs) stehen im Mittelpunkt der Funktionalität und des Namens von BOMnipotents. Eine BOM ist eine Liste aller Komponenten, aus denen ein Produkt besteht. Im Kontext der Cybersicherheit ist die Software-BOM (SBOM) die bekannteste Variante, BOMs ermöglichen aber auch allgemeinere Überlegungen.

Für BOM-Interaktionen, die über das Lesen hinausgehen, benötigen Sie die Berechtigung BOM_MANAGEMENT. Im Abschnitt zur Verwaltung von Zugriffsrechten wird beschrieben, wie diese erteilt wird.

Hochladen

Um eine BOM hochzuladen, rufen Sie Folgendes auf:

bomnipotent_client bom upload <PFAD/ZUR/BOM>

BOMnipotent erwartet seine BOM im strukturierten CycloneDX JSON-Format.

Im Syft-Tutorial erfahren Sie, wie Sie eine BOM für Ihr Produkt erstellen.

Der BOMnipotent Client ließt die Datei unter dem angegebenen Pfad und lädt ihren Inhalt hoch. Die BOM kann dann von Konsumenten mit entsprechenden Berechtigungen eingesehen werden.

BOMs für Konsumenten beschreibt, wie die BOMs auf dem Server aufgelistet und heruntergeladen werden.

Um eine BOM zur Datenbank hinzuzufügen, benötigt der BOMnipotent Client einige zusätzliche Informationen: einen Namen, eine Version und optional ein TLP-Label. Name und Version können entweder abgeleitet (empfohlen) oder wie unten beschrieben überschrieben werden.

Name und Version

bomnipotent_client bom upload <PFAD/ZUR/BOM> --name-overwrite=<NEUER-NAME> --version-overwrite=<NEUE-VERSION>

bomnipotent_client bom upload <PFAD/ZUR/BOM> -n <NEUER-NAME> -v <NEUE-VERSION>

TLP-Klassifizierung

Für Konsumenten verwaltet BOMnipotent den Datenzugriff über das Traffic Light Protocol (TLP) . Das CycloneDX-Format unterstützt derzeit keine Dokumentklassifizierung.

Um BOMnipotent mitzuteilen, wie ein Dokument klassifiziert werden soll, haben Sie zwei Möglichkeiten:

1. Legen Sie in der Serverkonfiguration ein Default-TLP-Label fest. Dieses wird dann für alle BOMs ohne weitere Spezifikationen verwendet.
2. Geben Sie eine TLP-Klassifizierung per Kommandozeilenargument an:
   ​

   lang kurz

   bomnipotent_client bom upload <PFAD/ZUR/BOM> --tlp=<label>

   bomnipotent_client bom upload <PFAD/ZUR/BOM> -t <LABEL>

Falls Sie keines von beiden tun, behandelt BOMnipotent alle nicht klassifizierten Dokumente so, als wären sie mit dem Label TLP:RED gekennzeichnet, und gibt jedes Mal eine Warnung aus, wenn dies erforderlich ist.

Ändern

Im einfachsten Fall funktioniert das Ändern einer vorhandenen Stückliste ähnlich wie das Hochladen einer neuen.

bomnipotent_client bom modify <PFAD/ZUR/BOM>

Dadurch werden Name und Version des Dokuments abgeleitet und der vorhandene Inhalt auf dem Server überschrieben. Sollten die Daten auf dem Server nicht vorhanden sein, wird ein 404-Fehler “Nicht gefunden” zurückgegeben.

TLP-Label ändern

Wenn der Stückliste zuvor ein TLP-Label zugewiesen wurde, wird dieses durch eine Änderung des Inhalts nicht automatisch geändert.

Wenn Sie ein neues TLP-Label angeben möchten, können Sie dies über das folgende Argument tun:

bomnipotent_client bom modify <PFAD/ZUR/BOM> --tlp=<LABEL>

bomnipotent_client bom modify <PFAD/ZUR/BOM> -t <LABEL>

Wenn sich der Inhalt der Stückliste nicht geändert hat und Sie nur das TLP-Label ändern möchten, müssen Sie das Dokument nicht erneut hochladen. Anstatt einen Dateipfad anzugeben, können Sie Name und Version der neu zu klassifizierenden BOM angeben:

bomnipotent_client bom modify --name=<NAME> --version=<VERSION> --tlp=<LABEL>

bomnipotent_client bom modify -n <NAME> -v <VERSION> -t <LABEL>

Wenn Sie als TLP-Label “none”, “default” oder “unlabelled” angeben, wird jede vorhandene Klassifizierung entfernt und der Server greift auf das Default-TLP-Label der Serverkonfiguration zurück:

bomnipotent_client bom modify <PFAD/ZUR/BOM> --tlp=none
bomnipotent_client bom modify <PFAD/ZUR/BOM> --tlp=default # Führt dasselbe aus
bomnipotent_client bom modify <PFAD/ZUR/BOM> --tlp=unlabelled # Führt dasselbe aus

bomnipotent_client bom modify <PFAD/ZUR/BOM> -t none
bomnipotent_client bom modify <PFAD/ZUR/BOM> -t default # Führt dasselbe aus
bomnipotent_client bom modify <PFAD/ZUR/BOM> -t unlabelled # Führt dasselbe aus

Name oder Version ändern

Wenn das hochgeladene Dokument einen anderen Namen oder eine andere Version hat als die zu ändernden Daten, müssen Sie diese Informationen dem BOMnipotent-Client mithilfe der folgenden Befehlszeilenargumente mitteilen:

bomnipotent_client bom modify <PFAD/ZUR/BOM> --name=<ALTER-NAME> --version=<ALTE-VERSION>

bomnipotent_client bom modify <PFAD/ZUR/BOM> -n <ALTER-NAME> -v <ALTE-VERSION>

BOMnipotent leitet die neuen Daten aus dem von Ihnen bereitgestellten Dokument ab und ändert die Datenbankeinträge entsprechend.

Name oder Version überschreiben (nicht empfohlen)

Wie beim Hochladen können Sie den im lokalen Dokument gespeicherten Namen und/oder die Version überschreiben:

bomnipotent_client bom modify <PFAD/ZUR/BOM> --name-overwrite=<NEUER-NAME> --version-overwrite=<NEUE_VERSION>

Wichtig: Wie beim Hochladen werden die JSON-Daten vor dem Hochladen auf den Server geändert! Es gelten die gleichen Dinge zu bedenken.

Wenn die Daten auf dem Server einen anderen Namen und/oder eine andere Version haben als im Dokument angegeben, können Sie die Angabe mit einem Überschreiben der Daten kombinieren:

bomnipotent_client bom modify <PFAD/ZUR/BOM> --name=<ALTER-NAME> --version=<ALTE-VERSION> --name-overwrite=<NEUER-NAME> --version-overwrite=<NEUE-VERSION>

bomnipotent_client bom modify <PFAD/ZUR/BOM> -n <ALTER-NAME> -v <ALTE-VERSION> --name-overwrite=<NEUER-NAME> --version-overwrite=<NEUE-VERSION>

Das Ändern von Name und/oder Version ohne Angabe des vollständigen Dokuments ist nicht unterstützt.

Löschen

Das Löschen einer BOM ist sehr einfach:

bomnipotent_client bom delete <NAME> <VERSION>

Falls die BOM nicht existiert, gibt der Server den Fehler 404 “Nicht gefunden” zurück. Ist sie vorhanden, wird sie aus der Datenbank entfernt.

Alle Komponenten und Sicherheitslücken, die mit der BOM assoziiert sind, werden ebenfalls gelöscht.

Sicherheitslücken

Ein zentraler Bestandteil der Lieferkettensicherheit ist der Abgleich des Inhalts einer Stückliste (BOM), also aller Komponenten eines Produkts, mit Datenbanken bekannter Schwachstellen.

Für Schwachstelleninteraktionen, die über das Lesen hinausgehen, benötigen Sie die Berechtigung VULN_MANAGEMENT. Im Abschnitt zur Verwaltung von Zugriffsrechten wird beschrieben, wie diese erteilt wird.

Erkennen

BOMnipotent erkennt selbst keine neuen Schwachstellen. Ein Tool, das in Kombination mit BOMnipotent verwendet werden kann, ist grype . Es verwendet eine BOM als Eingabe und erstellt eine Liste der Schwachstellen als Ausgabe. Das grype-Tutorial enthält weitere Informationen zur Verwendung. Es können aber auch andere Tools verwendet werden, solange sie Output im CycloneDX JSON Format erstellen können.

Mit dem BOMnipotent-Client können Sie den Inhalt einer BOM direkt ausgeben und an grype weiterleiten.

bomnipotent_client bom get <BOM-NAME> <BOM-VERSION> | grype --output cyclonedx-json=./vuln.cdx.json

bomnipotent_client bom get <BOM-NAME> <BOM-VERSION> | grype -o cyclonedx-json=./vuln.cdx.json

Dadurch werden die Softwarekomponenten anhand mehrerer Datenbanken geprüft und die Ergebnisse in das CycloneDX eingepflegt. Anschließend werden alle Ergebnisse in einer Datei namens “vuln.cdx.json” (oder einem anderen von Ihnen angegebenen Namen) gespeichert.

Grype hat derzeit einen kleinen bekannten Fehler , der dazu führt, dass die Version der Hauptkomponente beim Hinzufügen der Schwachstellen vergessen wird. Dies ist problematisch, da BOMnipotent die Version zur eindeutigen Identifizierung eines Produkts benötigt. Eine mögliche Problemumgehung besteht darin, die Version erneut zum Dokument hinzuzufügen, beispielsweise über jq '.metadata.component.version = "<VERSION>"' "vuln.cdx.json" > "vuln_with_version.cdx.json". Ab BOMnipotent v0.3.1 können Sie die Version stattdessen direkt beim Hochladen der Schwachstelle angeben, wie unten beschrieben.

Aktualisierung

Der Befehl zum Aktualisieren der mit einer BOM verknüpften Schwachstellen lautet:

bomnipotent_client vulnerability update <VULNERABILITIES>

[INFO] Updated vulnerabilities of BOM vulny_0.1.0

Das Argument “<VULNERABILITIES>” muss ein Pfad zu einer Datei im CycloneDX JSON-Format sein.

Idealerweise enthält diese Datei den Namen und die Version der zugehörigen BOM. In diesem Fall werden diese automatisch gelesen. Falls einer der Werte fehlt (z. B. aufgrund eines bekannten Fehlers in grype), können Sie ihn mit einem optionalen Argument angeben:

bomnipotent_client vulnerability update <VULNERABILITIES> --name=<NAME> --version=<VERSION>

bomnipotent_client vulnerability update <VULNERABILITIES> -n <NAME> -v <VERSION>

[INFO] Updated vulnerabilities of BOM BOMnipotent_1.0.0

Schwachstellen sollten regelmäßig aktualisiert werden. Dadurch werden alle vorherigen Schwachstellen, die mit einer BOM verknüpft sind, vollständig ersetzt. Das hochgeladene CycloneDX-Dokument muss daher eine vollständige Liste aller bekannten Schwachstellen enthalten.

Sie können Schwachstellen nur für eine BOM aktualisieren, die auf dem Server vorhanden ist:

[ERROR] Received response:
404 Not Found
BOM Schlagsahne_1.0.1 not found in database

Auflistung

Der Abschnitt zum Auflisten von Schwachstellen in der Dokumentation für Verbraucher behandelt die meisten Aspekte der Auflistung von Schwachstellen.

Ein Aspekt, der dort nicht erwähnt wird, ist die Option “–unassessed”. Damit listet der BOMnipotent-Client nur Schwachstellen auf, denen kein CSAF-Dokument zugeordnet ist.

bomnipotent_client vulnerability list --unassessed

bomnipotent_client vulnerability list -u

╭─────────────┬─────────┬─────────────────────┬───────────────────────────┬───────┬──────────┬─────────┬─────────────────╮
│ Product     │ Version │ Vulnerability       │ Description               │ Score │ Severity │ TLP     │ CSAF Assessment │
├─────────────┼─────────┼─────────────────────┼───────────────────────────┼───────┼──────────┼─────────┼─────────────────┤
│ BOMnipotent │ 1.0.0   │ GHSA-qg5g-gv98-5ffh │ rustls network-reachable  │       │ medium   │ Default │                 │
│             │         │                     │ panic in `Acceptor::accep │       │          │         │                 │
│             │         │                     │ t`                        │       │          │         │                 │
│ vulny       │ 0.1.0   │ GHSA-qg5g-gv98-5ffh │ rustls network-reachable  │       │ medium   │ Default │                 │
│             │         │                     │ panic in `Acceptor::accep │       │          │         │                 │
│             │         │                     │ t`                        │       │          │         │                 │
╰─────────────┴─────────┴─────────────────────┴───────────────────────────┴───────┴──────────┴─────────┴─────────────────╯
[ERROR] Found 2 unassessed vulnerabilities.

In diesem Modus beendet der BOMnipotent Client den Vorgang mit einem Fehlercode genau dann wenn nicht bewertete Schwachstellen vorliegen. Dies erleichtert die Integration dieses Aufrufs in Ihre regelmäßige CI/CD.

Sie können diese Option frei mit der Angabe eines Produktnamens oder einer Version kombinieren:

bomnipotent_client vulnerability list <NAME> <VERSION> --unassessed

bomnipotent_client vulnerability list <NAME> <VERSION>  -u

[INFO] No unassessed vulnerabilities found

CSAF Dokumente

Ein Common Security Advisory Format (CSAF)-Dokument ist die Antwort eines Herstellers auf eine neu entdeckte Sicherheitslücke. Es ist ein maschinenlesbares Format, welches Informationen darüber verbreitet, wie Nutzer Ihres Produkts reagieren sollten: Muss auf eine neuere Version aktualisiert werden? Muss eine Konfiguration geändert werden? Ist Ihr Produkt überhaupt betroffen oder ruft es den betroffenen Teil der anfälligen Bibliothek möglicherweise nie auf?

Für CSAF-Interaktionen, die über das Lesen hinausgehen, benötigen Sie die Berechtigung CSAF_MANAGEMENT. Im Abschnitt über die Verwaltung von Zugriffsrechten wird beschrieben, wie diese erteilt wird.

Hochladen

Um ein CSAF-Dokument hochzuladen, rufen Sie

bomnipotent_client csaf upload <PFAD/ZUM/CSAF> auf.

[INFO] Uploaded CSAF with id WID-SEC-W-2024-3470

Bevor Ihr CSAF-Dokument hochgeladen wird, prüft der BOMnipotent Client, ob es gemäß dem OASIS CSAF-Standard gültig ist.

Sie können das Ergebnis des Vorgangs mit

bomnipotent_client csaf list

╭─────────────────────┬───────────────────────────┬─────────────────────────┬─────────────────────────┬────────┬───────────╮
│ ID                  │ Title                     │ Initial Release         │ Current Release         │ Status │ TLP       │
├─────────────────────┼───────────────────────────┼─────────────────────────┼─────────────────────────┼────────┼───────────┤
│ WID-SEC-W-2024-3470 │ binutils: Schwachstelle e │ 2024-11-14 23:00:00 UTC │ 2024-11-17 23:00:00 UTC │ final  │ TLP:WHITE │
│                     │ rmöglicht Denial of Servi │                         │                         │        │           │
│                     │ ce                        │                         │                         │        │           │
╰─────────────────────┴───────────────────────────┴─────────────────────────┴─────────────────────────┴────────┴───────────╯

Alle Daten stammen aus dem CSAF-Dokument.

Falls das Dokument nicht den optionalen TLP-Labeleintrag enthält, wird es mit dem für den Server konfigurierten Default-TLP behandelt.

...┬────────┬─────────╮
...│ Status │ TLP     │
...┼────────┼─────────┤
...│ final  │ Default │
...┴────────┴─────────╯

Ändern

Wenn sich der Status Ihres Dokuments ändert, Sie es neu klassifizieren möchten oder neue Informationen vorliegen, können Sie es ändern. Um die neue Version hochzuladen, rufen Sie Folgendes auf:

bomnipotent_client csaf delete <PFAD/ZUM/CSAF>

[INFO] Modified CSAF with id BSI-2024-0001-unlabeled

Der Befehl kann sogar die ID vom CSAF Dokument modifizieren. Da die bisheriger ID in diesem Fall nicht aus dem neuen Dokument abgeleitet werden kann, muss sie als optionales Argument angegeben werden:

bomnipotent_client csaf delete <PFAD/ZUM/CSAF> --id=<ALTE-ID>

bomnipotent_client csaf delete <PFAD/ZUM/CSAF> -i <ALTE-ID>

Löschen

Um ein CSAF-Dokument von Ihrem Server zu löschen (was Sie wirklich nur tun sollten, falls etwas komplett schiefgelaufen ist), rufen Sie einfach Folgendes auf:

bomnipotent_client csaf delete <CSAF-ID>

[INFO] Deleted CSAF with id WID-SEC-W-2024-3470

Berechtigungen

In BOMnipotent sind Berechtigungen nicht direkt mit Benutzerkonten, sondern mit Rollen verknüpft. Der Abschnitt zur Rollenverwaltung beschreibt, wie diese Verknüpfung verwaltet wird, und der Abschnitt zur Rollenzuweisung erläutert, wie Rollen (und damit letztlich Berechtigungen) Benutzern zugewiesen werden.

Der Server verfügt über mehrere Berechtigungen im Code, von denen einige fest programmiert, andere konfigurierbar sind. Alle werden hier erläutert. Informationen zum Erstellen einer Berechtigung, die einer Rolle zugeordnet ist, finden Sie im entsprechenden Abschnitt .

Die Berechtigungen lassen sich gedanklich in Berechtigungen für Konsumenten , Manager und einige Sonderberechtigungen für Administratoren unterteilen.

Berechtigungen für Konsumenten

Ihre Kunden sind in der Regel mit einem oder mehreren Ihrer Produkte verknüpft. Sie möchten alle Arten von Dokumenten und Informationen zu diesem Produkt einsehen, haben aber nicht automatisch Anspruch auf Informationen zu anderen Produkten.

PRODUCT_ACCESS

Eine Berechtigung mit dem Wert “PRODUCT_ACCESS(<PRODUCT>)” gewährt Leseberechtigung für alle mit “<PRODUCT>” verknüpften Dokumente. Dies umfasst alle Stücklisten (BOMs) dieses Produkts, alle damit verbundenen Schwachstellen und alle CSAF-Dokumente zu diesem Produkt.

Beispielsweise könnte eine Rolle mit dem Wert “PRODUCT_ACCESS(BOMnipotent)” alle mit BOMnipotent verknüpften Dokumente (und nur diese) einsehen.

Dem Sternchen-Operator “*” kann als Globbing-Platzhalter für Produktnamen genutzt werden. Dabei entspricht das Sternchen einer beliebigen Anzahl von Symbolen. Beispielsweise würde die Berechtigung “PRODUCT_ACCESS(BOM*ent)” sowohl auf “BOMnipotent” als auch auf die (fiktiven) Produkte “BOMent” und “BOM-burárum-ent” zutreffen, nicht jedoch auf “BOMtastic” (da letzteres nicht auf “ent” endet).

Folglich ermöglicht “PRODUCT_ACCESS(*)” die Anzeige aller Dokumente.

Berechtigungen für Manager

Für Dokumentmanager ist die Situation in der Regel umgekehrt: Sie benötigen die Berechtigung, die Datenbankinhalte nicht nur anzuzeigen, sondern auch zu ändern. Ihr Umfang ist typischerweise nicht auf ein bestimmtes Produkt, sondern auf einen bestimmten Dokumenttyp beschränkt. Daher wird die Trennung der Managerberechtigungen aus einer anderen Perspektive betrachtet.

BOM_MANAGEMENT

Diese Berechtigung ermöglicht das Hochladen, Ändern und Löschen von Stücklisten (BOMs). Sie gewährt automatisch auch die Berechtigung zur Anzeige aller gehosteten Stücklisten.

VULN_MANAGEMENT

Diese Berechtigung ermöglicht das Aktualisieren und Anzeigen der Liste der Schwachstellen, die mit einer BOM verknüpft sind.

CSAF_MANAGEMENT

Diese Berechtigung ermöglicht das Hochladen, Ändern und Löschen von CSAF-Dokumenten (Common Security Advisory Format). Sie gewährt außerdem automatisch Anzeigeberechtigungen für alle gehosteten CSAF-Dokumente.

ROLE_MANAGEMENT

Mit dieser Berechtigung kann ein Benutzer die Berechtigungen von Rollen ändern . Dies kann weitreichende Folgen haben, da die Änderungen potenziell viele Benutzer betreffen.

USER_MANAGEMENT

Diese Berechtigung ist erforderlich, um Benutzer anzuzeigen, oder ihre Anfragen zur Kontoerstellung zu gewähren oder abzulehnen . Sie wird auch benötigt, um Nutzern Rollen zuzuweisen .

Sonderberechtigungen für Administratoren

BOMnipotent kennt die feststehende Rolle “admin”. Diese Rolle verfügt stets über alle Berechtigungen, die Benutzern erteilt werden können. Darüber hinaus gibt es einige Aufgaben, die nur von Benutzern mit der Administratorrolle ausgeführt werden können: – Nur Administratoren können die Administratorrolle anderen Benutzern zuweisen oder entziehen . Ein spezieller temporärer Administratormechanismus ermöglicht die Erstellung des ersten Administrators für einen neu erstellten BOMnipotent Server. – Nur Administratoren können den Abonnementschlüssel für eine BOMnipotent Server Instanz (de)aktivieren .

Rollenverwaltung

BOMnipotent verwendet ein rollenbasiertes Zugriffsmodell (RBAC), bei dem Benutzer Rollen und Rollen Berechtigungen zugeordnet werden. Während Berechtigungen in BOMnipotent größtenteils fest kodiert sind, können Rollen (fast) frei verwaltet werden. Dieser Abschnitt erklärt, wie das geht.

Um Rollen und ihre Berechtigungen zu ändern oder anzuzeigen, benötigt Ihr Benutzerkonto die Berechtigung ROLE_MANAGEMENT.

Standardrollen

Beim ersten Start Ihres BOMnipotent Servers werden in der Datenbank mehrere kreativ benannte Standardrollen angelegt:

• “bom_manager” mit der Berechtigung BOM_MANAGEMENT.
• “csaf_manager” mit der Berechtigung CSAF_MANAGEMENT.
• “role_manager” mit der Berechtigung ROLE_MANAGEMENT.
• “user_manager” mit der Berechtigung USER_MANAGEMENT.
• “vuln_manager”, mit der Berechtigung VULN_MANAGEMENT.

Sie können diese Rollen nach Belieben ändern oder löschen; es handelt sich lediglich um Vorschläge.

Wenn Ihnen diese Rollen nicht gefallen, können Sie sie mit den folgenden Aufrufen löschen:

bomnipotent_client role-permission remove bom_manager BOM_MANAGEMENT;
bomnipotent_client role-permission remove csaf_manager CSAF_MANAGEMENT;
bomnipotent_client role-permission remove role_manager ROLE_MANAGEMENT;
bomnipotent_client role-permission remove user_manager USER_MANAGEMENT;
bomnipotent_client role-permission remove vuln_manager VULN_MANAGEMENT;

Admin-Rolle

Es gibt eine spezielle Rolle namens “admin”, die nicht in den anderen Rollen aufgeführt ist. Der Grund dafür ist, dass sie nicht Teil der Datenbank, sondern des BOMnipotent-Codes selbst ist. Daher kann sie nicht geändert werden.

bomnipotent_client role-permission remove admin BOM_MANAGEMENT

bomnipotent_client role-permission add admin "PRODUCT_ACCESS(BOMnipotent)"

[ERROR] Received response:
422 Unprocessable Entity
Cannot modify admin role permissions

Die Administratorrolle verfügt über alle Berechtigungen, die erteilt werden können, und dann noch einige weitere .

Auflistung

Um alle Rollen und die zugehörigen Berechtigungen aufzulisten, rufen Sie Folgendes auf:

bomnipotent_client role-permission list

╭──────────────┬─────────────────┬───────────────────────────╮
│ Role         │ Permission      │ Last Updated              │
├──────────────┼─────────────────┼───────────────────────────┤
│ bom_manager  │ BOM_MANAGEMENT  │ 2025-03-20 10:38:27.29648 │
│              │                 │ 0 UTC                     │
│ csaf_manager │ CSAF_MANAGEMENT │ 2025-03-20 10:38:27.29695 │
│              │                 │ 2 UTC                     │
│ role_manager │ ROLE_MANAGEMENT │ 2025-03-20 10:38:27.29621 │
│              │                 │ 3 UTC                     │
│ user_manager │ USER_MANAGEMENT │ 2025-03-20 10:38:27.29562 │
│              │                 │ 0 UTC                     │
│ vuln_manager │ VULN_MANAGEMENT │ 2025-03-20 10:38:27.29671 │
│              │                 │ 9 UTC                     │
╰──────────────┴─────────────────┴───────────────────────────╯

Hinzufügen

Da Rollen ohne Berechtigungen bedeutungslos sind, werden sie immer paarweise verwendet. Es gibt keinen speziellen Mechanismus zum Erstellen einer neuen Rolle. Stattdessen existiert eine Rolle dadurch, dass ihr eine Berechtigung hinzugefügt wird.

Die Syntax zum Hinzufügen einer Berechtigung zu einer Rolle lautet:

bomnipotent_client role-permission add <ROLLE> <BERECHTIGUNG>

[INFO] Added permission BOM_MANAGEMENT to role

Sie könnten beispielsweise mehrere Berechtigungen in den Rollen “doc_manager” und “access_manager” zusammenfassen:

bomnipotent_client role-permission add doc_manager BOM_MANAGEMENT;
bomnipotent_client role-permission add doc_manager CSAF_MANAGEMENT;
bomnipotent_client role-permission add doc_manager VULN_MANAGEMENT;
bomnipotent_client role-permission add access_manager ROLE_MANAGEMENT;
bomnipotent_client role-permission add access_manager USER_MANAGEMENT;

Falls Sie die Standardrollen wie oben beschrieben entfernt haben, erhalten Sie Folgendes:

bomnipotent_client role-permission list

╭────────────────┬─────────────────┬───────────────────────────╮
│ Role           │ Permission      │ Last Updated              │
├────────────────┼─────────────────┼───────────────────────────┤
│ access_manager │ ROLE_MANAGEMENT │ 2025-03-20 11:05:42.06443 │
│                │                 │ 7 UTC                     │
│ access_manager │ USER_MANAGEMENT │ 2025-03-20 11:04:57.51274 │
│                │                 │ 7 UTC                     │
│ doc_manager    │ BOM_MANAGEMENT  │ 2025-03-20 11:05:55.15986 │
│                │                 │ 0 UTC                     │
│ doc_manager    │ CSAF_MANAGEMENT │ 2025-03-20 11:05:50.92466 │
│                │                 │ 9 UTC                     │
│ doc_manager    │ VULN_MANAGEMENT │ 2025-03-20 11:05:47.35620 │
│                │                 │ 9 UTC                     │
╰────────────────┴─────────────────┴───────────────────────────╯

Falls die hinzuzufügende Berechtigung nicht existiert oder fehlerhaft ist, erhalten Sie eine Fehlermeldung:

bomnipotent_client role-permission add clam_manager CLAM_MANAGEMENT

[ERROR] Received response:
422 Unprocessable Entity
Failed to parse permission: Invalid UserPermission string: CLAM_MANAGEMENT

Entfernen

Um eine Berechtigung aus einer Rolle zu entfernen, rufen Sie einfach Folgendes auf:

bomnipotent_client role-permission remove <ROLE> <PERMISSION>

[INFO] Removed permission VULN_MANAGEMENT from role vuln_manager

Sobald Sie die letzte Rolle aus einer Berechtigung entfernt haben, existiert diese nicht mehr.

Um Hoppla-Momente zu vermeiden, unterstützt BOMnipotent nicht das Löschen ganzer Stapel von Rollenberechtigungen.

Nutzerverwaltung

Der erste Schritt beim Anlegen eines neuen Benutzers ist die Beantragung eines neuen Kontos. Dieser Schritt wird an anderer Stelle beschrieben, da er sowohl für Manager als auch für Konsumenten relevant ist.

Aus Sicht von BOMnipotent ist ein Benutzer verknüpft mit einer eindeutigen E-Mail-Adresse als Kennung, und einem öffentlichen Schlüssel zur Authentifizierung. Dies sind alle Daten, die bei der Erstellung eines neuen Benutzerkontos gesendet werden.

Nach der Beantragung eines neuen Kontos obliegt es einem Benutzermanager, die Anfrage zu genehmigen oder abzulehnen.

Für die meisten Benutzerinteraktionen, einschließlich der Auflistung, benötigen Sie die Berechtigung USER_MANAGEMENT.

Auflistung

Um alle Benutzer in Ihrer Datenbank aufzulisten, rufen Sie

bomnipotent_client user list

╭────────────────────┬───────────┬─────────────────────────┬─────────────────────────╮
│ User Email         │ Status    │ Expires                 │ Last Updated            │
├────────────────────┼───────────┼─────────────────────────┼─────────────────────────┤
│ admin@wwh-soft.com │ APPROVED  │ 2026-03-23 04:51:26 UTC │ 2025-03-22 04:51:26 UTC │
│ info@wildeheide.de │ REQUESTED │ 2026-03-23 03:52:21 UTC │ 2025-03-22 03:52:21 UTC │
╰────────────────────┴───────────┴─────────────────────────┴─────────────────────────╯

So können Sie die E-Mail-Adressen und die Stati der Benutzer einsehen.

Ein Benutzer ohne den Status “APPROVED” hat keine besonderen Berechtigungen, unabhängig von zugewiesenen Rollen.

Jedem Benutzer ist außerdem ein Ablaufdatum zugeordnet. Ab diesem Zeitpunkt wird der öffentliche Schlüssel ungültig und muss erneuert werden. Die Gültigkeitsdauer eines Schlüssels kann in der Serverkonfiguration frei konfiguriert werden.

Genehmigung oder Ablehnung

Wenn Sie die Benutzeranfrage erwartet haben, können Sie sie genehmigen:

bomnipotent_client user approve <EMAIL>

[INFO] Changed status of info@wildeheide.de to APPROVED

Analog dazu können Sie diesem Benutzer stattdessen keinen Zugriff gewähren:

bomnipotent_client user deny <EMAIL>

[INFO] Changed status of info@wildeheide.de to DENIED

Es ist möglich, einem bereits genehmigten Benutzer den Zugriff wieder zu verweigern, wodurch das Konto effektiv widerrufen wird.

Entfernen

Wenn Sie ein Benutzerkonto vollständig löschen möchten, rufen Sie

bomnipotent_client user remove <EMAIL>

[INFO] Deleted user info@wildeheide.de

Dies löscht zusätzlich alle dem Benutzer zugewiesenen Rollen.

Rollenzuweisung

Rollen verbinden Benutzer mit Berechtigungen. Das Hinzufügen oder Entfernen von Rollen steuert indirekt, in welchem ​​Umfang Benutzer mit Ihrer BOMnipotent Server Instanz interagieren können.

Zu Ihrer Bequemlichkeit werden beim ersten Start des BOMnipotent-Servers mehrere Standardrollen angelegt. BOMnipotent kennt außerdem die Administratorrolle , die eine besondere Behandlung erhält.

Um Benutzerrollen zu ändern oder anzuzeigen, benötigt Ihr Benutzerkonto die Berechtigung USER_MANAGEMENT.

Auflistung

Um alle Rollen aller Benutzer aufzulisten, rufen Sie

bomnipotent_client user-role list

╭──────────────────┬─────────────┬───────────────────────────╮
│ User Email       │ User Role   │ Last Updated              │
├──────────────────┼─────────────┼───────────────────────────┤
│ info@quantumwire │ bom_manager │ 2025-03-22 04:27:33.71579 │
│                  │             │ 7 UTC                     │
│ info@wildeheide  │ bom_manager │ 2025-03-22 04:26:08.83708 │
│                  │             │ 3 UTC                     │
╰──────────────────┴─────────────┴───────────────────────────╯

Hinzufügen

Um einem Benutzer eine neue Rolle hinzuzufügen, rufen Sie

bomnipotent_client user-role add <EMAIL> <ROLLE>

[INFO] Added role to user

Der Benutzeraccount muss zu diesem Zeitpunkt bereits auf dem Server existieren, die Rolle jedoch nicht.

Nur Benutzer mit der Admin-Rolle können anderen Benutzern die Admin-Rolle zuweisen.

Entfernen

Um einem Benutzer eine Rolle zu entfernen, rufen Sie Folgendes auf:

bomnipotent_client user-role remove <EMAIL> <ROLLE>

[INFO] Removed role bom_manager from user info@wildeheide

Wenn eine der beiden Rollen nicht vorhanden ist, wird ein Fehler angezeigt:

[ERROR] Received response:
404 Not Found
User with email info@wildeheide does not have role bom_manager

Nur Benutzer mit der Admin-Rolle können die Admin-Rolle von anderen Benutzern entfernen.