Cryptographic Bill of Material (CBOM, CryptoBOM, Crypto SBOM)

Warum Kryptografie in einer SBOM unverzichtbar ist

Moderne Software nutzt an vielen Stellen kryptografische Komponenten – oft tief in Frameworks, Bibliotheken oder Protokollen verborgen. Dazu gehören u. a.:
• TLS Bibliotheken
• Hash Funktionen
• Verschlüsselungsalgorithmen
• Zertifikate
• Schlüsselmaterial
• Token Signaturen
• Kryptografische Frameworks (OpenSSL, BouncyCastle, libsodium …)

Sobald in einem dieser Bausteine eine Schwachstelle entsteht (z. B. Heartbleed, Logjam, SHA 1 Risiken), muss ein Unternehmen sofort erkennen können, ob es betroffen ist. 
Eine SBOM, die Kryptografie Informationen enthält, macht genau das möglich.

A ) Wie CycloneDX Kryptografie abbildet
CycloneDX bietet ein eigenes Cryptographic Components Model, mit dem kryptografische Elemente strukturiert erfasst werden können.
1. Kryptografische Algorithmen
Beispiele:
• AES
• RSA
• ECDSA
• SHA 256
• PBKDF2
• ChaCha20
CycloneDX dokumentiert:
• verwendeter Algorithmus
• Version
• Modus (z. B. AES GCM vs. AES CBC)

2. Kryptografische Bibliotheken
Jede Bibliothek kann als Komponente erfasst werden, z. B.:
• OpenSSL
• BouncyCastle
• libsodium
• WolfSSL
• Microsoft CNG
• Java Cryptography Architecture (JCA)
Mit Metadaten wie:
• Version
• Quelle
• Hash
• Lizenz
• CVE Bezug

3. Zertifikate
CycloneDX kann Zertifikate als eigene Objekte abbilden:
• X.509 Zertifikate
• TLS Zertifikate
• Code Signing Zertifikate
Mit:
• Fingerprint
• Aussteller
• Ablaufdatum
• Key Usage
• Public Key Algorithmus

4. Schlüsselmaterial (nur Metadaten!)
CycloneDX erfasst keine Schlüssel, sondern ausschließlich Metadaten:
• Schlüssellänge
• Algorithmus
• Verwendungszweck (Signatur, Verschlüsselung, TLS Handshake)
Das ermöglicht Compliance Nachweise, ohne Sicherheitsrisiken zu erzeugen.

5. Kryptografische Services
Auch kryptografische Dienste können modelliert werden, z. B.:
• TLS Terminator
• HSM Nutzung
• Token Signaturdienste
• Key Management Systeme

B ) Wie CycloneDX Kryptografie erkennt

CycloneDX ist ein Format, kein Scanner. Die Erkennung erfolgt durch Tools wie:
• Syft
• Trivy
• CycloneDX CLI
• Snyk
• OWASP Dependency Track

Diese analysieren u. a.:
• Bibliotheken
• Container
• Build Artefakte
• Konfigurationsdateien
• Zertifikate
• Laufzeitumgebungen
und erzeugen daraus eine SBOM mit Kryptografie Einträgen.

C ) Wie man CycloneDX für Kryptografie sinnvoll nutzt

1. Kryptografische Inventarisierung
Frage: „Welche Kryptobibliotheken und Algorithmen verwenden wir überhaupt?“ CycloneDX liefert:
• vollständige Liste
• Versionen
• CVE Risiken

2. Compliance & Regulierung
Regulatorien wie NIS2, DORA, ISO 27001, ETSI EN 303 645 verlangen:
• sichere Algorithmen
• keine veralteten Hashes
• keine unsicheren Cipher Suites
CycloneDX zeigt z. B.:
• ob SHA 1 noch genutzt wird
• ob TLS 1.0/1.1 aktiv ist
• ob schwache RSA Schlüssel existieren

3. Schwachstellenmanagement
Wenn eine Kryptobibliothek eine CVE hat (z. B. OpenSSL):
• Wo wird sie verwendet?
• In welcher Version?
• In welchen Produkten oder Komponenten?
CycloneDX ermöglicht sofortige Impact Analysen.

4. Lieferkettensicherheit
CycloneDX zeigt, ob Drittanbieter:
• unsichere Algorithmen nutzen
• abgelaufene Zertifikate einsetzen
• veraltete Bibliotheken einbinden
Damit wird Kryptografie zu einem prüfbaren Bestandteil des Software Supply Chain Risikos.

D ) Checkliste für SBOM Kryptografie Check
(für CycloneDX, NIS2, Secure SDLC, Lieferkettensicherheit)

1. Vollständigkeit der Kryptografie Erfassung

• Enthält die SBOM kryptografische Komponenten gemäß CycloneDX Crypto Model?
• Werden alle relevanten Kryptoelemente erfasst:
o Algorithmen
o Bibliotheken
o Zertifikate
o Schlüsselmaterial (nur Metadaten)
o Kryptografische Services
• Sind auch transitive Abhängigkeiten berücksichtigt?

• Prüfen, ob Tools wie Syft/Trivy/Snyk korrekt konfiguriert sind.
• Prüfen, ob Container Images und Build Artefakte gescannt wurden.

2. Kryptografische Algorithmen

• Sind alle verwendeten Algorithmen dokumentiert?
• Werden unsichere oder veraltete Algorithmen genutzt?
o SHA 1
o MD5
o RSA < 2048 Bit
o AES CBC ohne zusätzliche Integrität
• Sind die Betriebsmodi korrekt dokumentiert (z. B. AES GCM vs. AES CBC)?

• Abgleich mit BSI TR 02102, NIST SP 800 131A, ETSI Empfehlungen.

3. Kryptografische Bibliotheken

• Sind alle Kryptobibliotheken als Komponenten erfasst?
• Sind Version, Hash, Lizenz und Quelle dokumentiert?
• Gibt es bekannte CVEs zu diesen Bibliotheken?
• Werden veraltete oder ungepatchte Versionen eingesetzt?

• Speziell prüfen: OpenSSL, BouncyCastle, libsodium, WolfSSL.

4. Zertifikate

• Sind alle Zertifikate in der SBOM enthalten?
• Sind folgende Metadaten vollständig:
o Fingerprint
o Aussteller
o Ablaufdatum
o Key Usage
o Public Key Algorithmus
• Gibt es abgelaufene oder bald ablaufende Zertifikate?
• Werden schwache Schlüssel verwendet?

• Prüfen auf TLS 1.0/1.1, Self Signed Certificates, SHA 1 Signaturen.

5. Schlüsselmaterial (Metadaten)

• Werden nur Metadaten erfasst (keine Schlüssel selbst)?
• Sind Schlüssellängen und Algorithmen dokumentiert?
• Ist der Verwendungszweck klar (Signatur, Verschlüsselung, TLS Handshake)?
• Gibt es Hinweise auf schwache Schlüssel?

• Prüfen auf RSA < 2048 Bit, ECC < 256 Bit.

6. Kryptografische Services

• Sind externe oder interne Kryptoservices dokumentiert?
o HSM
o Key Management Systeme
o Token Signaturdienste
o TLS Terminatoren
• Sind deren Versionen und Konfigurationen nachvollziehbar?

• Prüfen, ob Schlüsselrotation dokumentiert ist.

7. Schwachstellenmanagement

• Werden kryptografische Komponenten regelmäßig auf CVEs geprüft?
• Gibt es Prozesse zur Bewertung kryptografischer Schwachstellen?
• Ist dokumentiert, wo eine betroffene Bibliothek eingesetzt wird?
• Gibt es definierte Reaktionszeiten (MTTD/MTTR)?

• Prüfen, ob Dependency Track oder Snyk Alerts genutzt werden.

8. Lieferkettensicherheit

• Enthält die SBOM kryptografische Informationen von Drittanbietern?
• Werden unsichere Algorithmen oder abgelaufene Zertifikate in Fremdkomponenten erkannt?
• Gibt es Anforderungen an Lieferanten zur Kryptografie Hygiene?

• Prüfen, ob AV Verträge oder SLA kryptografische Mindeststandards enthalten.

9. Compliance & Regulierung

• Erfüllt die Kryptografie die Anforderungen aus:
o NIS2
o DORA
o ISO 27001
o DSGVO Art. 32
o BSI Empfehlungen
• Werden unsichere Cipher Suites aktiv verhindert?
• Gibt es dokumentierte Kryptografie Policies?

• Prüfen, ob „Crypto Agility“ vorgesehen ist (schneller Algorithmuswechsel).

10. Dokumentation & Governance

• Ist die Kryptografie SBOM vollständig versioniert?
• Gibt es Verantwortlichkeiten (Owner, Maintainer)?
• Ist die SBOM in CI/CD integriert?
• Werden Änderungen an Kryptokomponenten automatisch erkannt?

• Prüfen, ob SBOM Updates Teil des Release Prozesses sind.

Kurzversion : 10 Punkte Check
1. Alle Kryptokomponenten vollständig erfasst?
2. Sichere Algorithmen und Betriebsmodi?
3. Kryptobibliotheken aktuell und ohne CVEs?
4. Zertifikate gültig und sicher?
5. Schlüsselmetadaten vollständig und sicher?
6. Kryptoservices dokumentiert?
7. Schwachstellenmanagement aktiv?
8. Lieferkette kryptografisch bewertet?
9. Compliance Anforderungen erfüllt?
10. SBOM Governance etabliert?

Konstantin Ziouras Blog Artikel

von Konstantin Ziouras • 5. Oktober 2026
Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit
von Konstantin Ziouras • 5. Oktober 2026
ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken
von Konstantin Ziouras • 22. September 2026
Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board
von Konstantin Ziouras • 22. September 2026
Anforderungsmanagement nach IREB - International Requirements Engineering Board
von Konstantin Ziouras • 22. September 2026
Requirements Engineering als Qualitäts- und Sicherheitsfaktor
von Konstantin Ziouras • 18. Mai 2026
Unterschiede zwischen EULA, SLA und AVV
von Konstantin Ziouras • 18. Mai 2026
Unterschiede und Parallelen bezüglich Bewertungen, bezüglich Lieferanten, Software, Cloud Dienstleistern
von Konstantin Ziouras • 10. Mai 2026
Risiken bezüglich Lieferanten
von Konstantin Ziouras • 10. Mai 2026
Lieferanten, Auswahl und Bewertung
von Konstantin Ziouras • 15. April 2026
Endpoint Security bedeutet: Schutz aller Endgeräte, die mit IT Systemen verbunden sind – also Laptops, Desktops, Smartphones, Tablets, Server, virtuelle Maschinen, Container Hosts, OT HMI Rechner etc. Bildlich: Jedes Gerät ist eine Tür ins Unternehmen. Endpoint Security sorgt dafür, dass diese Türen: • nicht offenstehen • nicht mit gestohlenen Schlüsseln geöffnet werden • und im Idealfall einen Alarm auslösen, wenn jemand versucht einzubrechen. Warum das Thema heute wichtig ist 1. Angriffe starten fast immer am Endpoint • Phishing Mails → Klick → Malware auf dem Laptop • Ransomware → Verschlüsselung startet am Endpoint • Initial Access Broker → kompromittierte Endgeräte werden verkauft 2. Arbeitswelt hat sich verändert • Homeoffice, Remote Work, BYOD • Cloud Zugriffe von überall • Mehr Endgeräte, weniger klarer Perimeter 3. Business Relevanz • Ein kompromittierter Endpoint kann: o Zugang zu AD / Identitäten geben o Ransomware ins gesamte Netz bringen o Datenabfluss ermöglichen • Direkte Auswirkungen: Ausfall, Lösegeld, Reputationsschäden, NIS2 Sanktionen. Technische Grundlagen Kernidee: Endpoint Security kombiniert Schutz, Erkennung und Reaktion direkt auf dem Gerät. Wichtige Bausteine: • Antivirus / Anti Malware: Signatur und verhaltensbasierter Schutz • Host Firewall: Filtert eingehenden/ausgehenden Traffic • Endpoint Detection & Response (EDR): Erkennung verdächtigen Verhaltens, Forensik, Response • Extended Detection & Response (XDR): Korrelation von Endpoint Daten mit Netzwerk, Cloud, Identitäten • Hardening: Konfiguration, die Angriffsfläche reduziert (z. B. Deaktivierung unnötiger Dienste) • Patch Management: Schließen von Schwachstellen Stand der Technik / Best Practices 1. Von klassischem AV zu EDR/XDR • Klassischer Virenscanner allein ist nicht mehr ausreichend. • Stand der Technik: EDR/XDR Lösungen, die Verhalten analysieren, Prozesse korrelieren und Angriffe in frühen Phasen erkennen. 2. Zero Trust am Endpoint • Endpoint wird nicht automatisch vertraut, nur weil er „im Netz“ ist. • Kombination aus: o Gerätestatus (Compliance) o Identität (User) o Kontext (Ort, Zeit, Risiko) 3. Harter Fokus auf Identitäten • Endpoint Security ist eng mit Identity & Access Management verknüpft. • Kompromittierter Endpoint → kompromittierte Identität → lateral movement. 4. Standardisierte Baselines • CIS Benchmarks, BSI Empfehlungen, Hardening Guides • Standardisierte Konfigurationen für Windows, macOS, Linux, Mobile, OT Systeme. Typische Risiken & Fehler in der Praxis • Nur Antivirus, kein EDR/XDR • Kein zentrales Management der Endpoints • Ungepatchte Systeme (insbesondere Drittsoftware wie Browser, Java, Office Plugins) • Lokale Adminrechte für Benutzer • Kein Application Whitelisting (alles darf laufen) • Shadow IT (private Geräte, nicht verwaltete Systeme) • OT Endpoints ohne Schutz, weil „Produktionssysteme darf man nicht anfassen“ • Fehlende Integration in SIEM/SOC – Alarme bleiben unbemerkt Moderne Lösungsansätze & Technologien • EDR/XDR Plattformen o Sammeln Telemetrie (Prozesse, Registry, Netzwerk, Dateien) o Erkennen verdächtige Muster (z. B. Ransomware Verhalten) o Unterstützen Incident Response (Isolieren von Endpoints, Forensik) • Zero Trust Network Access (ZTNA) o Zugriff auf Anwendungen nur, wenn Endpoint „gesund“ ist (Compliance Check) • Mobile Device Management (MDM) / Unified Endpoint Management (UEM) o Verwaltung von Laptops, Smartphones, Tablets, teilweise auch IoT/OT o Erzwingung von Policies (Verschlüsselung, PIN, Jailbreak Erkennung) • Application Control / Whitelisting o Nur erlaubte Anwendungen dürfen laufen o Sehr wirksam gegen Malware und Ransomware • Hardware basierte Sicherheit o TPM, Secure Boot, Device Guard, Plattferverschlüsselung (BitLocker, FileVault) Relevanz für Informationssicherheit & Compliance NIS2 • Verlangt „Stand der Technik“ bei technischen und organisatorischen Maßnahmen. • Endpoint Security ist zentral für: o Schutz vor Ransomware o Incident Detection & Response o Nachweis von Maßnahmen gegenüber Aufsichtsbehörden. ISO 27001:2022 • Relevante Controls u. a.: o A.5.15: Access control o A.8.1: User end point devices o A.8.7: Protection against malware o A.8.8: Management of technical vulnerabilities o A.8.9: Configuration management IEC 62443 (für OT) • Endpoint ähnliche Systeme (Engineering Stationen, HMI, Server) müssen: o gehärtet sein o nur notwendige Dienste bereitstellen o überwacht werden o in Zonen/Conduits eingebettet sein. Endpoint Security ist damit ein Pflichtbaustein für jede ernsthafte Umsetzung von NIS2, ISO 27001 und IEC 62443. Empfehlungen für Unternehmen (konkret, priorisiert) Priorität 1 – Basis schaffen • Zentrales Endpoint Management einführen (Windows, macOS, Linux, Mobile) • EDR Lösung ausrollen (mindestens auf kritischen Systemen) • Patch Management etablieren (inkl. Drittsoftware) • Plattferverschlüsselung aktivieren (Laptops, mobile Geräte) • Lokale Adminrechte abschaffen (Role Based Access, Just in Time Admin) Priorität 2 – Reifegrad erhöhen • Application Whitelisting für besonders kritische Systeme • Zero Trust Policies: Zugriff nur bei „gesundem“ Endpoint • Integration in SIEM/SOC: Alarme zentral auswerten • Standardisierte Hardening Baselines (CIS, BSI) Priorität 3 – OT & Spezialumgebungen • OT Endpoints inventarisieren (Engineering Stationen, HMI, SCADA Server) • Schutzkonzept definieren: o Hardening o Segmentierung o Monitoring (passiv, wo aktiv nicht möglich) • Remote Zugriffe auf OT nur über kontrollierte Jump Hosts mit starker Authentifizierung und Session Recording. CTO Checkliste: Die 3 entscheidenden Fragen 1) „Wie erkennen und stoppen wir heute einen Angriff auf einen Endpoint, der keine bekannte Malware Signatur hat?“ Diese Frage trennt klassischen Antivirus von echtem EDR/XDR. Eine moderne Antwort muss enthalten: • verhaltensbasierte Erkennung • Prozess und Speicheranalyse • Telemetrie Korrelation • automatische Isolation des Endpoints • Integration ins SOC/SIEM Wenn die Antwort nur „Antivirus“ oder „Signaturen“ enthält → nicht modern. 2) „Wie stellen wir sicher, dass alle Endgeräte (inkl. Homeoffice, mobile Geräte, Admin Laptops, OT Engineering Stationen) vollständig verwaltet, gepatcht und gehärtet sind?“ Diese Frage deckt Management Reifegrad, Patch Prozesse und Hardening auf. Eine moderne Antwort muss enthalten: • zentrales Endpoint Management (UEM/MDM) • automatisiertes Patch Management (inkl. Drittsoftware) • CIS/BSI Hardening Baselines • Compliance Checks vor Zugriff (Zero Trust) Wenn die Antwort „Wir patchen regelmäßig“ lautet → nicht ausreichend. 3) „Wie schnell können wir einen kompromittierten Endpoint identifizieren, isolieren und forensisch analysieren – und wer macht das konkret?“ Diese Frage prüft Incident Response Fähigkeit und operative Realität. Eine moderne Antwort muss enthalten: • EDR gestützte Isolation per Klick • klare Rollen (SOC, IT Ops, Dienstleister) • forensische Daten (Prozesse, Registry, Netzwerk, Timeline) • definierte Reaktionszeiten • Playbooks Wenn die Antwort unklar ist oder niemand zuständig ist → kritische Lücke.