Das CERT-In (Indian Computer Emergency Response Team), das dem Ministerium für Elektronik und Informationstechnologie (MeitY) untersteht, hat seine Rolle als nationale Behörde für Cybersicherheit seit seiner Benennung durch das Gesetz zur Änderung der Informationstechnologie von 2008 stetig ausgebaut.
Im Jahr 2024 veröffentlichte CERT-In seine ersten speziellen Leitlinien für SBOMSoftware Bill of Materials), in denen Mindestelemente, Formate und Implementierungsanforderungen definiert sind.
Nur ein Jahr später, im Juli 2025, wurde der Anwendungsbereich mit der Version 2.0 erheblich erweitert und auf SBOM, QBOM, CBOM, AIBOM und HBOM ausgedehnt, wodurch sichere Software-Lieferketten als zentrale nationale Resilienzstrategie etabliert wurden.
Für CIOs und CISOs haben diese Richtlinien betriebliche, finanzielle und gesetzliche Konsequenzen. Unternehmen müssen bereit sein, revisionssichere SBOM-Praktiken zu demonstrieren, Anbieter und Partner mit den Compliance-Anforderungen in Einklang zu bringen und die Automatisierung zur Verwaltung von SBOMs in großem Umfang einzuführen.
Dieser Artikel enthält eine schrittweise Anleitung zur Einhaltung der CERT-In SBOM-Richtlinien, die den Anwendungsbereich, die technischen Standards, die Auswahl von Anbietern und bewährte Verfahren für indische Unternehmen und globale Organisationen mit Niederlassungen in Indien umfasst.
- CERT-In SBOM-Leitlinien: Anwendungsbereich, Anwendbarkeit und Hauptanforderungen
- Wie OPSWAT SBOM bei CERT-In-Anforderungen hilft
- Anpassung von Software an die CERT-In SBOM-Konformität
- Akzeptierte SBOM-Formate und technische Standards unter CERT-In
- Bewertung und Auswahl von Anbietern für SBOM-Compliance
- Best Practices für die nahtlose SBOM-Implementierung
- Automatisieren, einhalten und schützen: Der OPSWAT für SBOM-Management
- MetaDefender Software Supply Chain™
- FAQs
- Sektorspezifische Überlegungen: Finanzinstitute, Supply Chain und kritische Infrastrukturen
- Was kommt als Nächstes? Vorbereitung auf Cert-In SBOM-Richtlinien ist unerlässlich
CERT-In SBOM-Leitlinien: Anwendungsbereich, Anwendbarkeit und Hauptanforderungen
Was ist CERT-In und warum hat es SBOM-Richtlinien herausgegeben?
CERT-In ist Indiens nationale Agentur für Cybersicherheit. Ihre SBOM-Richtlinien zielen darauf ab, die Sicherheit der Lieferkette zu stärken, die Transparenz von Softwarekomponenten zu verbessern und schnellere, standardisierte Reaktionen auf Schwachstellen zu gewährleisten.
Was ist CERT-In und warum hat es SBOM-Richtlinien herausgegeben?
Die Einhaltung der Vorschriften gilt für Behörden, den öffentlichen Sektor, wichtige Dienste und Softwareexporteure sowie für Entwickler, Integratoren und Wiederverkäufer während des gesamten Softwarelebenszyklus.
Core eines SBOM gemäß den CERT-In-Leitlinien
Gemäß den Leitlinien müssen die SBOMs Daten wie diese enthalten:
- Komponentenname, Version, Anbieter und Lizenz
- Abhängigkeiten und Herkunft
- Schwachstellen und Patch-Status
- End-of-Life-Daten, Nutzungsbeschränkungen und Kritikalität
- Eindeutige Bezeichner, Prüfsummen und Autoreninformationen
Durch die Vorgabe dieser Mindestelemente stellt CERT-In sicher, dass SBOMs umsetzbar, maschinenlesbar und auditfähig sind.
Wie OPSWAT SBOM bei CERT-In-Anforderungen hilft
OPSWAT SBOM hilft bei der Automatisierung und Sammlung von CERT-In SBOM-Datenfeldern, um Sichtbarkeit und Transparenz in den wichtigsten Bereichen zu schaffen, von Softwarekomponentendetails über Transparenz und Risiken bis hin zu Lizenzierung und Nutzung.
Details zur Software
- Komponentenname: Name der Softwarekomponente oder Bibliothek.
- Version der Komponente: Versionsnummer oder Kennung der Komponente.
- Lieferant der Komponente: Einrichtung, die die Komponente bereitstellt (Anbieter, Drittanbieter oder Open-Source).
- Herkunft der Komponente: Quelle der Komponente (proprietär, Open-Source oder Drittanbieter).
- Eindeutiger Bezeichner: Eindeutiger Code zur Verfolgung der Komponente über Versionen und Besitzverhältnisse hinweg.
- Autor der SBOM-Daten: Entität, die für die Erstellung des SBOM-Eintrags verantwortlich ist.
- Zeitstempel: Datum und Uhrzeit, zu der der SBOM-Eintrag aufgezeichnet wurde.
Software und -Risiken
- Abhängigkeiten von Komponenten: Andere Komponenten oder Bibliotheken, auf die diese Komponente angewiesen ist.
- Schwachstellen: Bekannte Sicherheitsprobleme im Zusammenhang mit der Komponente, mit Schweregrad und CVE-Referenzen.
- Patch-Status: Aktuelle Verfügbarkeit von Updates oder Patches für Sicherheitslücken.
- Prüfsummen oder Hashes: Kryptographische Werte zur Überprüfung der Dateiintegrität.
- Eigenschaft Ausführbar: Gibt an, ob die Komponente ausgeführt werden kann.
- Archiv-Eigenschaft: Gibt an, ob die Komponente als Archivdatei verpackt ist.
- Datum der Veröffentlichung: Datum, an dem die Komponente erstmals veröffentlicht wurde.
Lizenzierung & Nutzung
- Lizenz für die Komponente: Lizenztyp und Bedingungen für die Verwendung der Komponente.
- Verwendungsbeschränkungen: Gesetzliche oder behördliche Einschränkungen für die Verwendung von Komponenten.
Anpassung von Software an die CERT-In SBOM-Konformität
Das Erreichen der CERT-In-Konformität ist ein schrittweiser Prozess, der die Koordination zwischen Entwicklungs-, Sicherheits-, Betriebs- und Compliance-Teams erfordert. Jeder Beteiligte spielt eine Rolle bei der Erstellung, Pflege und Weitergabe von SBOMs an verschiedenen Punkten des Software-Lebenszyklus.
Die nachstehende Tabelle mit Inhalten und Beispielen aus den Technischen Richtlinien von CERT-In veranschaulicht, wie sich die SBOM-Verantwortlichkeiten mit den gängigen Softwarekomponenten decken:
| Software | Beispiel | SBOM-Ebene | SBOM Autor | Warum? |
|---|---|---|---|---|
| Hauptanwendung | Eine Anwendung zur Datenanalyse | SBOM auf Anwendungsebene | Erstellt vom Produktentwicklungsteam | Vollständige SBOM, die zusammen mit der Anwendung an den Kunden oder die Behörde geliefert wird |
| Software [Datenbank, Framework] | PostgreSQL | Top-Level-SBOM | Intern entwickelt, wenn der Anbieter keine SBOM zur Verfügung gestellt hat | Sicherstellung der Rückverfolgbarkeit kritischer Komponenten |
| Plattform/Middleware [z. B. Webserver, Laufzeitumgebung] | Apache Tomcat Server | Lieferung SBOM | Von der Plattform/dem Anbieter zur Verfügung gestellt | Gemeinsame Nutzung bei der Beschaffung; Integration von Komponenten, die vom Anbieter bereitgestellt werden |
| Bibliotheken/SDKs von Drittanbietern | Postfix und Twilio SDK | Transitive SBOM | Erstellt vom Upstream-Anbieter oder intern, falls nicht verfügbar | Deckt indirekte Abhängigkeiten und externe Dienste ab |
Wenn die Rollen und Verantwortlichkeiten definiert sind, können die Unternehmen mit den praktischen Schritten zur Einhaltung der Vorschriften beginnen. Ein stufenweiser Fahrplan hilft dabei, den Reifegrad von Mitarbeitern, Prozessen und Technologien zu erhöhen.
1. Durchführung einer Bereitschaftsbewertung und Lückenanalyse
Identifizieren Sie die aktuellen Praktiken für die Software-Inventarisierung, die Verfolgung von Schwachstellen und die von den Anbietern bereitgestellten SBOMs. Vergleichen Sie diese mit den erforderlichen Datenfeldern und -formaten von CERT-In.
2. Aufbau einer internen SBOM-Politik und Governance-Struktur
Definieren Sie klare Rollen für Entwickler, IT-Betrieb, Beschaffung, Sicherheit und Compliance-Teams. Governance stellt sicher, dass SBOMs konsistent erstellt, gepflegt und im gesamten Unternehmen gemeinsam genutzt werden.
3. Auswahl und Implementierung von SBOM-Generierungswerkzeugen
Automatisierung ist entscheidend. Tools müssen:
- Generierung von SBOMs für jede neue Version, jeden Patch oder jedes Update
- Integration mit DevOps-Pipelines, Quellcode-Repositories und Container-Registries
- Ausgabe in CycloneDX- und SPDX-Formaten für den regulatorischen Abgleich
4. Integration von SBOM-Workflows in SDLC und Beschaffung
Einbettung der SBOM-Generierung in jede SDLC-Phase:
- Design SBOM: geplante Komponenten
- Quell-SBOM: Entwicklungsabhängigkeiten
- SBOM erstellen: während der Kompilierung
- Analysierte SBOM: Inspektion nach der Fertigstellung
- Deployed SBOM: installierte Umgebung
- Laufzeit-SBOM: Überwachung aktiver Komponenten
Beschaffungsverträge sollten die Lieferung von SBOM durch alle Lieferanten vorschreiben.
5. Laufende Einhaltung der Vorschriften und Bereitschaft zur Prüfung aufrechterhalten
Führen Sie kontinuierliche SBOM-Updates durch, integrieren Sie Schwachstellen-Beratungen wie VEX (Vulnerability Exploitability eXchange) und CSAF und sorgen Sie für eine sichere Speicherung und Weitergabe durch Verschlüsselung, HTTPS und digitale Signaturen.
Möchten Sie erfahren, wie Sie SBOM für Ihre Sicherheitsstrategie nutzen können?
Akzeptierte SBOM-Formate und technische Standards unter CERT-In
CycloneDX und SPDX: Die anerkannten Standards
CERT-In erkennt CycloneDX und SPDX als die wichtigsten maschinenlesbaren Formate für die SBOM-Automatisierung an.
- CycloneDX: Leichtgewichtig, sicherheitsorientiert, optimiert für Schwachstellenmanagement
- SPDX: Lizenzorientiert, weit verbreitet für Compliance-Dokumentation
Bewertung und Auswahl von Anbietern oder Lösungen für die Einhaltung von CERT-In SBOM
Die Wahl des richtigen Anbieters oder der richtigen Lösung ist sowohl für die Einhaltung der Vorschriften als auch für die betriebliche Effizienz entscheidend.
Schlüsselkriterien für die Bewertung von Anbietern, die CERT-In SBOM einhalten
- Unterstützung für SPDX und CycloneDX
- Integration in DevOps-Pipelines und CI/CD-Workflows
- Fähigkeit, mehrere SBOM-Ebenen zu erzeugen (Entwurf, Erstellung, Einsatz, Laufzeit)
- Revisionssichere Berichterstattung und sichere Freigabemechanismen
Fragen an potenzielle Anbieter zur CERT-In-Anpassung
Die Auswahl der richtigen Partner ist ebenso wichtig wie der Aufbau interner SBOM-Prozesse. CIOs und Beschaffungsleiter sollten die CERT-In-Anpassung in ihre RFP- und Due-Diligence-Checklisten aufnehmen. Zu den wichtigsten Fragen, die zu stellen sind, gehören:
- Bieten Sie SBOMs in von CERT-In genehmigten Formaten (SPDX, CycloneDX) an?
- Wie oft werden Ihre SBOMs aktualisiert - nur bei der Veröffentlichung oder kontinuierlich?
- Welche Automatisierungsmöglichkeiten bieten Sie für die Erstellung, Validierung und den sicheren Austausch von SBOMs?
- Wie setzen Sie eine sichere SBOM-Verteilung durch (z. B. Verschlüsselung, RBAC, digitale Signaturen)?
- Ist Ihre Lösung mit DevOps-Pipelines, Schwachstellendatenbanken und CERT-In-Hinweisen integriert?
- Wie unterstützen Sie die Prüfung der Einhaltung von Vorschriften und die laufende Berichterstattung?
Durch die Beantwortung dieser Fragen im Vorfeld kann sichergestellt werden, dass die Anbieter nicht nur auf dem Papier konform sind, sondern auch in der Lage sind, SBOM-Praktiken anzuwenden, die mit den sich entwickelnden Richtlinien von CERT-In übereinstimmen.
Checkliste für die Auswahl und das Onboarding von Anbietern
- Unterstützt die erforderlichen Datenfelder und Formate von CERT-In
- Automatisiert die Erstellung, Verfolgung und Aktualisierung
- Bietet rollenbasierte Zugriffskontrolle und sichere Freigabe
- Nachgewiesene Anwendung in regulierten Branchen
Best Practices für die nahtlose SBOM-Implementierung
Bewährte Strategien für große Unternehmen
- Beginnen Sie mit grundlegenden Arbeitsabläufen und erweitern Sie den Reifegrad im Laufe der Zeit
- Verpflichtung zur Bereitstellung von SBOM in allen Beschaffungsverträgen
- Anwendung eines Shift-Links-Ansatzes durch frühe Integration der SBOM-Generierung in den SDLC
- Schulung des Personals in Bezug auf SBOM und gesetzliche Anforderungen
Häufige Fehler und wie man sie vermeidet
Selbst gut gemeinte SBOM-Initiativen können scheitern, wenn Organisationen sie nur oberflächlich angehen. CERT-In betont, dass SBOMs genau, umfassend und ständig aktualisiert sein müssen. Hier sind einige der häufigsten Fallstricke und wie man sie vermeiden kann:
| Häufiger Irrtum | Erläuterung | Wie man sie vermeidet |
|---|---|---|
| Behandlung von SBOM als statischer Bericht | Viele Unternehmen erstellen bei der Veröffentlichung eine SBOM und aktualisieren sie nie. Dadurch sind sie blind für Schwachstellen, die durch Patches, Updates oder neue Abhängigkeiten entstehen. | Behandeln Sie die SBOM als ein lebendes Inventar. Automatisieren Sie Aktualisierungen durch Ihre CI/CD-Pipeline, damit die SBOM-Daten bei jedem neuen Build oder Release aktualisiert werden. |
| Fehlende Einbeziehung transitiver Abhängigkeiten | Das Übersehen indirekter Komponenten, wie z. B. Open-Source-Bibliotheken, die durch andere Abhängigkeiten eingebunden werden, schafft gefährliche blinde Flecken, die Angreifer ausnutzen. | Verwenden Sie automatische SBOM-Generierungstools, die alle direkten und transitiven Abhängigkeiten rekursiv abbilden und so eine vollständige Abdeckung Ihrer Software-Lieferkette gewährleisten. |
| Verlassen auf manuelle Erstellung ohne Automatisierung | Die manuelle SBOM-Kompilierung ist zeitaufwändig, fehleranfällig und im Unternehmensmaßstab nicht tragbar. Außerdem erhöht sich dadurch das Risiko inkonsistenter Formate. | Integrieren Sie Automatisierung und Standardisierung. Führen Sie Tools ein, die SBOMs in CERT-In-geprüften Formaten wie SPDX und CycloneDX generieren, und erzwingen Sie eine Validierung vor der Freigabe. |
Indem sie diese Fehler vermeiden und SBOM-Praktiken in die täglichen Entwicklungsabläufe einbinden, können Unternehmen die Einhaltung von Vorschriften in einen strategischen Vorteil verwandeln, indem sie Risiken reduzieren und gleichzeitig die CERT-In-Anforderungen erfüllen.
Vorbereitungen für Audits
Pflege vollständiger SBOM-Repositories, Dokumentation von Governance-Praktiken und Anpassung an CERT-In-Auditvorlagen.
Zukunftssicherer Schutz vor regulatorischen Veränderungen
Die Roadmap von CERT-In deutet bereits auf breitere BOM-Anforderungen (Hardware, KI und Cloud) hin. Unternehmen, die skalierbare, flexible Tools einsetzen, werden am besten in der Lage sein, sich anzupassen.
Automatisieren, einhalten und schützen: Der OPSWAT für SBOM-Management
OPSWAT SBOM
OPSWAT SBOM unterstützt Entwickler durch die Bereitstellung einer genauen Bestandsaufnahme von Softwarekomponenten in Quellcode und Containern. Bleiben Sie Angreifern voraus, decken Sie Bedrohungen auf und erkennen Sie Schwachstellen, ohne die Entwicklungsgeschwindigkeit zu beeinträchtigen.
SBOM für Software und Artefakte
Ermöglicht es Software-Entwicklungsteams, Sicherheitsschwachstellen und Lizenzprobleme bei Open-Source-Abhängigkeiten zu identifizieren, zu priorisieren und zu beheben.
SBOM für Software und Artefakte
Ermöglicht es Software-Entwicklungsteams, Sicherheitsschwachstellen und Lizenzprobleme bei Open-Source-Abhängigkeiten zu identifizieren, zu priorisieren und zu beheben.
SBOM für Container
Analysieren Sie Container-Images und generieren Sie SBOM für den Paketnamen, Versionsinformationen und potenzielle Schwachstellen.
MetaDefender Software Supply Chain™
Gehen Sie über die SBOM-Konformität hinaus und gehen Sie auf fortschrittliche, sich entwickelnde Angriffe auf die Software-Lieferkette ein.
OPSWAT MetaDefender Software Supply Chain bietet erweiterte Transparenz und einen robusten Schutz vor Risiken in der Lieferkette. Mit unseren Zero-Trust-Technologien zur Erkennung und Verhinderung von Bedrohungen ist Ihr Softwareentwicklungszyklus (SDLC) vor Malware und Schwachstellen geschützt, was die Anwendungssicherheit und die Einhaltung von Richtlinien stärkt.
Malware im Code erkennen
Die Kombination von über 30 Antiviren-Engines erhöht die Erkennungsraten und verhindert effektiv, dass Malware Workstations, Container oder Quellcode infiziert.
Hart kodierte Geheimnisse identifizieren
Proactive DLPTM identifiziert Anmeldeinformationen wie Passwörter, Geheimnisse, Token, API oder andere sensible Informationen, die im Quellcode hinterlassen wurden.
Secure Container gegen Angriffe auf die Supply Chain
Beurteilen und bewerten Sie jegliche Malware, Schwachstellen oder andere potenzielle Risiken, die sich unter jeder Schicht eines Container-Images befinden.
Integration leicht gemacht
Egal, ob Ihr Team Quellcode-Repositories, Container-Registries, Binärdienste oder eine Kombination von Tools verwendet, MetaDefender Software Supply Chain bietet native Integrationen mit gängigen Plattformen, um Ihren gesamten SDLC zu sichern.
FAQs
Welche Sanktionen werden bei Nichteinhaltung der CERT-In SBOM-Richtlinien verhängt?
Regulatorische Audits und mögliche Einschränkungen bei Verträgen mit Behörden und wichtigen Diensten. Die Nichteinhaltung der CERT-In SBOM-Richtlinien kann Unternehmen anfällig für Datenschutzverletzungen machen, was zu hohen Geldstrafen führen kann.
Wie oft müssen SBOMs aktualisiert werden?
Bei jedem neuen Release, Update, Patch oder Herstellerwechsel.
Können Open-Source- und Drittanbieter-Komponenten einbezogen werden?
Ja. Vollständige Einsicht in alle Abhängigkeiten - direkt und transitiv - ist obligatorisch.
Sind kleinere Unternehmen davon ausgenommen?
Neugründungen außerhalb der regulierten Sektoren haben möglicherweise nur begrenzte Erleichterungen, aber die Einführung wird dringend empfohlen.
Wie stimmt CERT-In mit den globalen Standards überein?
Der indische Ansatz spiegelt internationale Rahmenwerke wie das NIST und den EU Cyber Resilience Act wider und gewährleistet grenzüberschreitende Kompatibilität.
Wie sollte mit der Offenlegung von Schwachstellen umgegangen werden?
Durch VEX- und CSAF-Hinweise, integriert mit CERT-In-Warnungen und internen SBOM-Systemen.
Welche Rolle spielt die Automatisierung?
Die Automatisierung ermöglicht eine kontinuierliche Einhaltung der Vorschriften, reduziert menschliche Fehler und gewährleistet die Skalierbarkeit in hybriden IT-Umgebungen.
Sektorspezifische Überlegungen: Finanzinstitute, Supply Chain und kritische Infrastrukturen
Finanzsektor
Banken und NBFCs müssen die SBOM-Praktiken an die Cybersicherheitsvorgaben der RBI anpassen und strengere Prüfungsanforderungen für den Umgang mit sensiblen Daten festlegen.
Supply Chain
Lieferanten müssen SBOMs als Teil von Verträgen liefern. Unternehmen sollten aus Gründen der Transparenz und des Risikomanagements interne und externe SBOM-Bestände führen.
Kritische Infrastrukturen
In Sektoren wie Telekommunikation, Verteidigung und Energie gibt es regulatorische Überschneidungen. SBOM-Praktiken müssen in umfassendere Rahmenwerke für Systemresilienz und nationale Sicherheit integriert werden.
Was kommt als Nächstes? Vorbereitung auf Cert-In SBOM-Richtlinien ist unerlässlich
Die CERT-In SBOM-Leitlinien stellen einen Wendepunkt für indische Unternehmen dar. Was mit einem engen Fokus auf SBOMs begann, hat sich nun zu einem umfassenden Rahmen für die Transparenz der Software-Lieferkette und das Risikomanagement ausgeweitet.
Die SBOM-Technologie OPSWAT geht über die Einhaltung von Vorschriften hinaus, indem sie die Transparenz der Lieferkette in den SDLC einbettet und die mehrschichtige Sicherheit mit Code-Repositories, Container-Registrierungen und DevOps-Pipelines integriert.
Entdecken Sie, wie OPSWAT Ihrem Unternehmen helfen kann, die Einhaltung von CERT-In SBOM zu vereinfachen und Ihre Software-Lieferkette zu sichern.
