Lesezeit: 5 Minuten.

SBOM operativ: Was NIS2 und CRA 2026 wirklich von Ihnen verlangen

Die nächste große Sicherheitslücke wie Log4Shell kommt bestimmt – doch sind Sie vorbereitet? Ab 2026 verlangt der Cyber Resilience Act (CRA) von Herstellern digitaler Produkte und die NIS2-Richtlinie von kritischen Einrichtungen nicht nur eine Software Bill of Materials (SBOM), sondern deren operative Nutzung.

Doch eine SBOM allein ist nur eine statische Liste: Entscheidend ist, wie Sie Schwachstellen wie neue CVEs automatisiert erkennen, priorisieren und beheben – und das mit nachweisbaren Prozessen für Audits. Dieser Beitrag zeigt, warum SBOMs 2026 zur Eintrittskarte werden und wie Sie aus einer bloßen Compliance-Pflicht einen echten Sicherheitsvorteil machen. Denn nur wer Schwachstellen im Vulnerability-Lifecycle aktiv managt, erfüllt nicht nur gesetzliche Vorgaben, sondern minimiert auch das Risiko für Ihr Unternehmen.

Wenn die nächste log4shell kommt — wissen Sie in Minuten, welche Produkte betroffen sind?

Genau das ist die Frage, auf die NIS2 und der Cyber Resilience Act (CRA) belastbare Antworten verlangen. Nicht nur von kritischen Einrichtungen unter NIS2, sondern — unter CRA — von jedem Hersteller eines Produkts mit digitalen Elementen. Das betrifft 2026/2027 deutlich mehr Unternehmen, als viele gerade annehmen.

SBOM ist 2026 die Eintrittskarte, nicht die Auszeichnung

Eine Software Bill of Materials (SBOM) im CycloneDX-Standard ist das maschinenlesbare Inhaltsverzeichnis Ihrer Software. 2026 wird sie in jedem ernstzunehmenden Build-Prozess automatisch entstehen — GitHub, GitLab, Composer, npm bringen das mit. Das Erzeugen wird Standard.

Doch die eigentliche Frage lautet: Was passiert danach?

Der Unterschied liegt im operativen Vulnerability-Lifecycle

Eine SBOM ohne kontinuierlichen Abgleich gegen Schwachstellendatenbanken ist eine Tabelle. Erst wenn neu gemeldete CVEs automatisch gegen Ihren Komponenten-Bestand laufen, definierte Schwellwerte die Eskalation steuern und ein nachvollziehbarer Workflow von Erkennung bis Patch existiert, erfüllen Sie Art. 21 NIS2 und die Pflichten aus dem CRA-Annex I.

Bei dkd ist genau das seit Jahren operative Praxis: GitLab erzeugt SBOMs in jedem Produktionsdeployment, OWASP Dependency-Track überwacht kontinuierlich gegen NVD, GitHub Advisories und OSS Index, definierte Policies steuern Reaktion und Eskalation. Der Audit-Trail entsteht im Hintergrund.

Was können wir für Sie tun & warum dkd

Wir bringen Sie in dieselbe Position. Wir integrieren GitLab und Dependency-Track in Ihre Entwicklungsinfrastruktur, definieren mit Ihnen Schwellwerte und Reaktionspfade und schulen Ihre Teams so, dass aus Tools gelebter Prozess wird. Auf Wunsch betreiben wir die Plattform als Managed Service — DSGVO-konform und in Deutschland gehostet.

Wir verkaufen Ihnen keine Tools, die Sie selbst zusammenstecken könnten. Wir bringen die operative Erfahrung mit — aus eigener Anwendung und aus über zwei Jahrzehnten professioneller Software-Entwicklung. Die Frage ist nicht, ob Sie 2026 SBOMs haben. Die Frage ist, was sie Ihnen im Ernstfall liefern.

Wir machen SBOMs operativ – sprechen Sie uns an.