Technische Richtlinien für SBOM in Indien
| interlynk
Technische SBOM-Richtlinie von CERT-In Indien
CERT-In, oder das Indian Computer Emergency Response Team, ist die nationale Behörde, die für die Reaktion auf Cybersicherheitsvorfälle in Indien zuständig ist. CERT-In wurde 2004 gegründet und untersteht dem Ministerium für Elektronik und Informationstechnologie (MeitY). Die Aufgabe der Organisation besteht darin, die Sicherheit der digitalen Infrastruktur Indiens zu verbessern. Sie spielt eine entscheidende Rolle bei der Prävention, Erkennung und Bewältigung von Bedrohungen der Cybersicherheit, die indische Netzwerke, Regierungsbehörden, Unternehmen und Bürger betreffen könnten. Zudem hat CERT-In für bestimmte Sektoren die Meldung von Cybersicherheitsvorfällen innerhalb vorgegebener Fristen verpflichtend gemacht, um die Reaktion auf Vorfälle und die nationale Sicherheit zu verbessern.
Im Oktober veröffentlichte CERT-In technische SBOM-Richtlinien für den indischen öffentlichen Sektor, Regierungsbehörden, wesentliche Dienste sowie Unternehmen, die im Softwareexport und in der Software-Dienstleistungsbranche tätig sind. Dieses 7-teilige Dokument konzentriert sich auf die Darstellung des Nutzens von SBOMs, die Einrichtung von Prozessen und Praktiken und listet Empfehlungen sowie Best Practices auf.
In diesem Beitrag fassen wir die wichtigsten Aspekte des Leitfadens zusammen.
SBOM-Vorteile und Anwendungsfälle
CERT-In dokumentiert die folgenden Hauptvorteile der Implementierung eines SBOM-Programms:
Effektives Sicherheitsmanagement
Effektive Reaktion auf Vorfälle
Identifizierung von Schwachstellen und Patch-Management
Sicherheit der Lieferkette
Unterstützung bei der Gewährleistung der Compliance
Verbesserte operative Effizienz
und empfiehlt SBOM für Anwendungsfälle in folgenden Bereichen:
Softwareentwicklung und -wartung
(Software-) Lieferkettenmanagement
Cybersicherheit
Einhaltung gesetzlicher Vorschriften
Risikomanagement
Interoperabilität und Kompatibilität
SBOM-Implementierung
Das Dokument enthält ein durchgängiges Implementierungsbeispiel für SBOM mit der Empfehlung, diese zu aktualisieren, sobald neue Informationen verfügbar werden, selbst wenn sich die Komponente selbst nicht geändert hat. Der Erstellungs-, Abfrage- und Erfüllungsprozess der SBOM ist in Abbildung 1 des Dokuments dargestellt. Die Verantwortung für die Bereitstellung einer genauen und vollständigen SBOM liegt beim Softwareentwickler und nicht beim Verbraucher.
SBOM-Klassifizierung
Das Dokument klassifiziert die SBOM nach der Phase, in der sie erstellt wird. Konkret:
Design-SBOM: Geplante Komponenten während der Entwurfsphase
Source-SBOM: Spiegelt die Entwicklungsumgebung wider, einschließlich Quelldateien und Abhängigkeiten
Build-SBOM: Als Ergebnis des Erstellungsprozesses (Build-Prozess)
Analyzed-SBOM: Durch Untersuchung des endgültigen Artefakts
Deployed-SBOM: Bestandsverzeichnis der installierten Software
Runtime-SBOM: Überwachung aktiver Komponenten in der SBOM
Die Details innerhalb der SBOM werden auch in Bezug auf den Grad ihrer Vollständigkeit und die Auswirkungen auf die Nutzung beschrieben. Konkret:
Top-Level-SBOM: Bietet eine allgemeine Zusammenfassung der Komponenten
n-Level-SBOM: Enthält tiefere Details (n-Ebene)
Delivery-SBOM: Beinhaltet alle Teile, Bibliotheken und Abhängigkeiten, die freigegeben oder geliefert werden
Transitive-SBOM: Beinhaltet direkte, indirekte und transitive Abhängigkeiten
Complete-SBOM: Enthält eine vollständige Liste aller Teile, Abhängigkeiten und zugehörigen Metadaten
SBOM-Roadmap
CERT-In empfiehlt, die Einführung von SBOM in drei Implementierungsphasen aufzubauen: START, PROGRESS und ADVANCE.
START
SBOM Start ist die grundlegende Phase, um Folgendes zu erreichen:
Identifizierung kritischer Assets
Erstellung eines Projektplans und eines Change-Management-Prozesses
Bestimmung des SBOM-Formats und der Mindestanforderungen dafür
Identifizierung von Sicherheitsanforderungen und Tools für die Arbeit mit SBOM
Integration von SBOM in den Software-Beschaffungsprozess
PROGRESS
SBOM Progress ist die darauffolgende Reifestufe mit Fokus auf der eindeutigen Identifizierung von Komponenten und der Integration von SBOM in den SDLC.
Erstellung einer Checkliste für sichere Installation und Betriebsanleitungen
Zuweisung einer eindeutigen Kennung für jede Komponente
Abgleich der SBOM des Lieferanten mit der internen SBOM des Verbrauchers
Erstellung von SBOMs sowohl durch die Lieferanten- als auch die Verbraucherorganisation
Integration von SBOM in jede Phase des SDLC
Implementierung von Zugriffskontrollen, Verschlüsselung, Audit-Zyklen und sicherem Konfigurationsmanagement
ADVANCE
SBOM Advance ist die Phase für ein ausgereiftes und skalierbares SBOM-Management mit Fokus auf der Integration in bestehende Workflows wie Schwachstellenmanagement und Vorfallreaktion.
Implementierung von Prozessen zur Schwachstellenverfolgung
Nutzung von SBOM zur Steuerung der Vorfallreaktion
Einrichtung einer regelmäßigen Überprüfung und Analyse bestehender SBOMs
Aufrechterhaltung des Bewusstseins für neu entstehende Komponenten und Branchenfortschritte
Lizenzmanagement mit SBOM
Als eine der SBOM-Spezifikationen hat sich SPDX aus dem Software-Lizenzmanagement entwickelt. Das Dokument skizziert wichtige Praktiken, die sich speziell auf das Software-Lizenzmanagement konzentrieren. Dazu gehören:
Das Produkt und alle seine Komponenten müssen eine Lizenz enthalten
Verwendung von SPDX-Identifikatoren für Lizenzen
In Betracht ziehen alternativer Lizenzdatenbanken – Scancode, LicenseDB, AboutCode –, falls die primäre nicht gefunden wird
Zuweisung eines eindeutigen Identifikators, wenn dieser in jenen Datenbanken nicht erkannt wird
Verwendung von SPDX-Lizenz-Ausdrücken (License Expression) zum Erweitern, Modifizieren oder Erstellen von Ausnahmen
SBOM-Vorbereitung
Dieses Kapitel befasst sich mit den wichtigsten Feldern, die in einer SBOM ausgefüllt werden müssen, und enthält Empfehlungen für Mindestelemente der SBOM einschließlich spezifischer Datenfelder, Automatisierungsunterstützung und betrieblicher Praktiken.
Datenfelder
Komponentenname
Komponentenversion
Komponentenbeschreibung
Komponentenlieferant
Komponentenlizenz
Komponentenherkunft
Komponentenabhängigkeiten
Schwachstellen
Patch-Status
End-of-Life-Datum (EOL-Datum)
Kritikalität
Nutzungsbeschränkungen
Prüfsummen oder Hashes
Kommentare oder Notizen
Autor der SBOM-Daten
Zeitstempel
Ausführbare Eigenschaft
Archivierungseigenschaft
Strukturierte Eigenschaft
Eindeutige Kennung
Automatisierungsunterstützung
Das Dokument skizziert die folgenden Vorteile der automatisierten SBOM-Erstellung und ihrer Maschinenlesbarkeit unter Verwendung der SBOM-Formate CycloneDX oder SPDX.
Automatisierung der Komponentenerkennung
Automatisierte Versionsverfolgung
Abhängigkeitsanalyse
Automatisierte Schwachstellenbewertung
Lizenz-Compliance
Automatisierte SBOM-Erstellung
DevSecOps-Integration
Berichterstattung und Visualisierung
Integration mit Sicherheits-Orchestrierungsplattformen
Überwachung und Wartung
Prozesse und Praktiken für SBO-Materiallisten (SBOM)
Dieses Kapitel konzentriert sich auf die Einrichtung von Schlüsselprozessen innerhalb des SBOM-Programms, um Verantwortlichkeiten abzugrenzen, eine Governance aufzubauen und gleichzeitig den Nutzen zu maximieren.
Rollen und Verantwortlichkeiten festlegen
Schlüsselakteure identifizieren
Verantwortlichkeiten definieren
Rollen und Zuständigkeiten zuweisen
Governance etablieren
Zusammenarbeit ermöglichen
Schulungen und Ressourcen bereitstellen
Überwachen und verfeinern
Fahrplan zur Navigation durch die Funktionen von SBOM
Sichere SBOM-Verteilung
Der Abschnitt über die SBOM-Verteilung konzentriert sich auf die Auflistung von Verteilungsoptionen, Rollen sowie die Verwaltung der Sicherheit und Überprüfung der Daten.
Zugriffskontrolle
Öffentliche und private SBOM
Sichere Verteilungsmechanismen
Automatisierte SBOM-Erstellung und -Aktualisierungen
SBOM-Nutzung und -Verifizierung
Überwachung und Auditierung
Vorfallreaktion und Behebung von Sicherheitslücken
SBOM-Freigabe (Sharing)
Der Abschnitt über die Freigabe von SBOMs konzentriert sich auf die Auswirkungen und Werkzeuge für das Teilen von SBOMs außerhalb des Unternehmens, einschließlich mit Regulierungsbehörden.
Sichere Plattformen für den Datenaustausch
API-Integrationen
Kollaborationswerkzeuge
Branchenplattformen und Repositories
Schachstellen-Tracking und -Analyse in SBOM
Das Dokument empfiehlt eine Funktion zur Verfolgung und Analyse von SBOM-Schwachstellen unter Verwendung von SBOM, Vulnerability Exchange Document (VEX) und Common Security Advisory Framework (CSAF).
VEX-Dokument
Vulnerability Exploitability eXchange (VEX) (fälschlicherweise als Vulnerability Exchange Document aufgeführt) wird für den standardisierten Austausch von Schwachstelleninformationen empfohlen und muss einen der folgenden produktspezifischen Schwachstellenstatus enthalten:
Nicht betroffen
Betroffen
Behoben
In Untersuchung
CSAF
Das Common Security Advisory Framework (CSAF) wird für die Veröffentlichung von Sicherheitswarnungen im Zusammenhang mit den Schwachstellen empfohlen. Dies muss Angaben zur Schwachstelle, eine Beschreibung, betroffene Produktversionen, Schweregradeinschätzungen und empfohlene Maßnahmen zur Behebung enthalten.
Diverse Schwachstellendatenbanken
Das Dokument empfiehlt die Integration mit verschiedenen Schwachstellendatenbanken für eine vollständige Transparenz und Unterstützung bei der prioritären Behebung.
Shift-Left im SDLC
Beim Shift-Left-Ansatz in der Entwicklung wird empfohlen, die SBOM-Erstellung und -Analyse in früheren Phasen des SDLC wie Build und Packaging zu implementieren, um sicherzustellen, dass ausnutzbare Schwachstellen noch früher erkannt und behoben werden.
SBOM Best Practices
Das Dokument schließt mit 15 Empfehlungen und 16 Best Practices, die die zuvor im Dokument behandelten Schlüsselaspekte von SBOM zusammenfassen. Indische Bundesbehörden und -organisationen werden ermutigt, die Erstellung und Bereitstellung einer Software Bill of Materials (SBOM) als erforderliche Standardpraxis für die Beschaffung und Entwicklung von Software einzuführen, um die Sicherheit zu stärken und Cyber-Risiken zu reduzieren.
Interlynk SBOM Plattform
Die Interlynk SBOM-Automatisierungsplattform hat alle von CERT-In vorgeschlagenen Empfehlungen und Best Practices vorausgesehen und ist bereits bereit, folgende Empfehlungen zu erfüllen:
✅ Integration der SBOM-Erfassung in die Softwarebeschaffung
✅ Verschiebung (Shift left) der SBOM-Generierung in Pull-Requests, Build-Pipelines, Pakete oder Releases
✅ Verfolgung von SBOMs aus mehreren Phasen und bei der Hinzufügung von Komponenten zum Build
✅ Automatisierte SBOM-Analyse auf Herkunft der Komponenten, Lizenzen und Schwachstellen
✅ Automatisierte VEX-Generierung und -Verteilung
✅ Erkennung inkompatibler Lizenzen und Generierung von Lizenzbenachrichtigungen
✅ Erkennung bösartiger, veralteter, nicht mehr unterstützter (End-of-Life, End-of-Service) und manipulierte Komponenten
✅ Einrichtung von Richtlinien für den Komponentenkonsum und automatische Benachrichtigung bei Richtlinienverstößen
✅ Rollenbasierte Zugriffskontrolle und vollständiges Audit-Protokoll für Änderungen am Inventar
✅ Sichere SBOM-Verteilung und Zugriffsprotokollierung
✅ Menschlich lesbare SBOM, zugehörige Metriken und anpassbare Berichte
✅ Auditierung gegen SBOM-Vorschriften, einschließlich FDA, US Federal, OpenChain, PCI DSS und dem kommenden Cyber Resilience Act
Fazit
Die SBOM ist die Grundlage für die Automatisierung von Anwendungscompliance und -sicherheit und gewinnt weltweit an starker Dynamik. Da Indiens CERT-In nun durch detaillierte Empfehlungen nachdrücklich für die Einführung der SBOM plädiert, ebnet dieser Schritt den Weg dafür, dass eine der größten Bevölkerungen der Welt die SBOM als Standard in der Softwareentwicklung erwartet.