SBOM? einfach erklärt
Eine Software Bill of Materials (SBOM)
ist eine Stückliste aller Bauteile einer Software
— ähnlich wie die Zutatenliste auf einer Lebensmittelverpackung.
Sie zeigt:
• Welche Komponenten in einer Software enthalten sind
• Welche Versionen verwendet werden
• Woher die Komponenten stammen
• Welche Risiken (z. B. CVEs) damit verbunden sind
Warum das wichtig ist:
Moderne Software besteht zu 70–90% aus Fremdkomponenten (Open Source, Bibliotheken, Frameworks). Wenn dort eine Schwachstelle auftaucht, muss man wissen:
Sind wir betroffen? Wo genau? Wie kritisch?
Eine SBOM liefert genau diese Transparenz.
Wer fordert eine SBOM?
• NIS2 (EU)
• DORA (Finanzsektor)
• US Executive Order 14028
• ISO 27001 / TISAX (indirekt über Lieferketten Sicherheit)
• Viele Kunden in Automotive, Health, KRITIS
SBOMs sind also längst ein Pflichtbestandteil moderner Software Sicherheit.
Was muss mindestens in einer SBOM enthalten sein? (Mindestanforderungen)
Die Mindestanforderungen orientieren sich an NTIA und CycloneDX/SPDX Standards.
1. Komponenteninformationen
• Name der Komponente
• Version
• Hersteller / Quelle
• Lizenztyp
2. Identifikatoren
• Package URL (purl)
• Hash (z. B. SHA 256)
• SPDX ID oder CycloneDX ID
3. Abhängigkeiten
• Welche Komponenten hängen voneinander ab?
4. Metadaten
• Erstellungsdatum
• Ersteller (Firma/Tool)
• SBOM Format (SPDX, CycloneDX)
Was enthält eine ideale SBOM? (Best Practice)
Eine ideale SBOM geht deutlich weiter:
5. Sicherheitsinformationen
• Bekannte CVEs pro Komponente
• CVSS Scores
• Exploit Status (z. B. CISA KEV)
• Patch Status
6. Integritätsinformationen
• Signaturen
• Hashes aller Dateien
• Lieferketten Nachweise (SLSA Level)
7. Build Informationen
• Build Server
• Build Pipeline
• Compiler Version
• verwendete Flags
8. Lizenz Compliance
• Lizenztyp
• Lizenzrisiken
• Nutzungseinschränkungen
9. Runtime Informationen
• Welche Komponenten werden tatsächlich genutzt?
• Welche sind nur „mitgeliefert“?
10. Abhängigkeitsgraph
• Visualisierung aller Beziehungen
• Erkennung kritischer Ketten
Wichtige Tools zur Erstellung einer SBOM
Automatisierte SBOM Generatoren
• CycloneDX CLI
• SPDX Tools
• Syft (Anchore)
• Trivy
• Snyk
• GitHub SBOM Export
• GitLab Dependency Scanning
CI/CD Integration
• GitHub Actions
• GitLab CI
• Azure DevOps Pipelines
Checkliste für SBOM‑Pflichten nach NIS2 / DORA
Hinweis: NIS2 und DORA schreiben nicht „SBOM“ wörtlich vor, verlangen aber faktisch SBOM‑ähnliche Transparenz über Software‑Komponenten und Lieferketten.
1. Governance & Verantwortlichkeiten
- Verantwortung definiert: [ ] Rolle/Owner für SBOM‑Management benannt (z. B. CISO, Head of Engineering)
- Richtlinie vorhanden: [ ] Interne Richtlinie zu SBOM, Third‑Party‑Software und Open‑Source‑Nutzung
- Scope definiert: [ ] Welche Systeme/Applikationen SBOM‑pflichtig sind (kritische Dienste, regulierte Services, Cloud‑Plattformen)
2. Erstellung & Aktualität
- Automatisierte Erstellung: [ ] SBOM wird automatisiert in CI/CD erzeugt (z. B. pro Build/Release)
- Aktualität: [ ] SBOM wird bei jeder neuen Version aktualisiert [ ] SBOM‑Stand ist nachvollziehbar (Datum, Version, Tool)
- Formatstandard: [ ] Nutzung eines anerkannten Standards (SPDX oder CycloneDX)
3. Inhaltliche Mindestanforderungen
- Komponenteninformationen: [ ] Name, Version, Hersteller/Quelle jeder Komponente [ ] Lizenzinformationen (Open Source / kommerziell)
- Identifikatoren: [ ] Eindeutige IDs (z. B. purl, SPDX‑ID) [ ] Hashes für Integrität (wo sinnvoll)
- Abhängigkeiten: [ ] Abhängigkeitsbeziehungen (Dependency Graph) dokumentiert
4. Schwachstellen‑ und Risikomanagement
- CVE‑Bezug: [ ] Komponenten werden regelmäßig gegen CVE‑Datenbanken geprüft
- Bewertung: [ ] Kritische CVEs (z. B. CISA KEV, CVSS ≥ 7.0) werden priorisiert
- Prozess: [ ] Definierter Prozess zur Behandlung von SBOM‑basierten Findings (Patch, Mitigation, Risk Acceptance)
- Nachweisbarkeit: [ ] Dokumentation von Entscheidungen (z. B. „Known Vulnerable but Accepted“)
5. Lieferkette & Drittanbieter
- Lieferantenanforderungen: [ ] Vertragliche Pflicht für kritische Lieferanten, SBOMs bereitzustellen
- Prüfung: [ ] Eingehende SBOMs werden geprüft (CVE, Lizenzen, kritische Komponenten)
- Integration: [ ] SBOMs von Dritten in eigenes Risiko‑ und Asset‑Register integriert
6. Resilienz, Reporting & Aufsicht
- Business Impact: [ ] Kritische Komponenten sind mit Geschäftsprozessen/Services verknüpft
- Reporting: [ ] Regelmäßige Berichte an Management/Board zu SBOM‑Risiken (z. B. kritische CVEs in Kernsystemen)
- Aufsichtsanforderungen: [ ] Nachweisfähigkeit gegenüber Aufsichtsbehörden (DORA/NIS2‑Audits) durch dokumentierte SBOM‑Prozesse
- Übungen: [ ] Szenarienübungen: „Kritische CVE in weit verbreiteter Bibliothek – wie reagieren wir?“
Konstantin Ziouras Blog Artikel
Unterschiede zwischen EULA, SLA und AVV
Risiken bezüglich Lieferanten
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.







