NIS2 fuer Software-Unternehmen: SaaS, Lieferkette und was OEM-Kunden verlangen

TL;DR

• NIS2 trifft Software-Unternehmen doppelt: Direkt als "Anbieter digitaler Dienste" (ab 50 MA / 10 Mio. EUR Umsatz) und indirekt ueber die Supply-Chain-Anforderungen Ihrer Kunden.
• OEM- und Enterprise-Kunden verlangen ab 2026 Nachweise: SBOM (Software Bill of Materials), signierte Container-Images, dokumentierte Incident-Response-Prozesse und regelmaessige Penetrationstests.
• SaaS-Anbieter auf Kubernetes muessen vier Bereiche abdecken: Supply-Chain-Integrity (Image Signing, SBOM), Mandantentrennung (Namespace-Isolation, Network Policies), Schwachstellenmanagement (Trivy, CVE-SLAs) und Incident-Transparenz (Benachrichtigung der Kunden).
• Wer proaktiv handelt, gewinnt Wettbewerbsvorteile: NIS2-Compliance wird zum Differenzierungsmerkmal gegenueber Konkurrenten, die diese Nachweise nicht liefern koennen.
• Die Umsetzung in der CI/CD-Pipeline ist der effizienteste Weg: Image Scanning, SBOM-Generierung und Signing lassen sich automatisieren und erfordern kein dediziertes Security-Team.

Warum NIS2 Software-Unternehmen besonders betrifft

Software-Unternehmen und SaaS-Anbieter stehen bei NIS2 in einer besonderen Position. Sie sind nicht nur selbst reguliert -- sie sind auch Teil der Lieferkette ihrer Kunden. Und genau diese Lieferkette steht im Fokus der Richtlinie.

Direkte Betroffenheit: "Anbieter digitaler Dienste"

NIS2 Anhang II listet "Digitale Dienste" als Sektor fuer "wichtige Einrichtungen". Darunter fallen:

• Cloud-Computing-Dienste (IaaS, PaaS, SaaS)
• Online-Marktplaetze
• Suchmaschinen
• Soziale Netzwerke
• Managed Services und Managed Security Services

Wenn Ihr Unternehmen eine SaaS-Plattform betreibt und die Schwellenwerte ueberschreitet (50 Mitarbeiter oder 10 Mio. EUR Umsatz), fallen Sie direkt unter NIS2.

Indirekte Betroffenheit: Die Lieferketten-Pflicht

Selbst wenn Ihr Unternehmen unter den Schwellenwerten liegt, erreicht Sie NIS2 ueber Ihre Kunden. Art. 21 Abs. 2 lit. d verpflichtet regulierte Unternehmen zur "Sicherheit der Lieferkette einschliesslich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern."

In der Praxis bedeutet das: Ihr Enterprise-Kunde -- ein Fertigungsunternehmen mit 2.000 Mitarbeitern -- muss nachweisen, dass seine Software-Lieferanten sichere Entwicklungsprozesse haben. Ihr SaaS-Produkt laeuft in seinem Betrieb. Also muessen Sie Nachweise liefern.

Was OEM- und Enterprise-Kunden ab 2026 verlangen

Die Anforderungen kommen nicht abstrakt aus Bruessel. Sie kommen als konkrete Frageboegen, Vertragsklauseln und Audit-Anforderungen von Ihren Kunden. Hier die fuenf Bereiche, die in fast jedem Zulieferer-Assessment auftauchen:

1. Software Bill of Materials (SBOM)

Ihre Kunden muessen wissen, welche Komponenten in Ihrer Software stecken -- Open-Source-Bibliotheken, Frameworks, Laufzeitabhaengigkeiten. Wenn eine kritische CVE in einer Bibliothek auftaucht, muessen sie einschaetzen koennen, ob sie betroffen sind.

2. Signierte Artefakte

Container-Images und Software-Pakete muessen nachweisbar von Ihrem Build-System stammen. Image-Signing mit Cosign und Sigstore stellt sicher, dass niemand ein manipuliertes Image unterschiebt.

3. Schwachstellenmanagement mit SLAs

Kunden erwarten definierte Reaktionszeiten: Kritische CVEs innerhalb von 48 Stunden gepatcht, hohe Schwachstellen innerhalb von 14 Tagen. Diese SLAs muessen vertraglich vereinbart und nachweisbar eingehalten werden.

4. Incident-Transparenz

Wenn ein Sicherheitsvorfall Ihre SaaS-Plattform betrifft, muessen Ihre Kunden informiert werden -- zeitnah und mit konkreten Auswirkungsanalysen. NIS2 verlangt von Ihren Kunden eine 24-Stunden-Meldung an die Behoerde, also brauchen sie Ihre Information noch schneller.

5. Penetrationstests und Audit-Berichte

Jaehrliche Penetrationstests mit dokumentierten Ergebnissen und Behebungsnachweisen. Manche Kunden verlangen Einsicht in die Berichte oder beauftragen eigene Tests Ihrer Schnittstellen.

Technische Umsetzung: NIS2-konforme CI/CD-Pipeline fuer SaaS

Die meisten Supply-Chain-Anforderungen lassen sich direkt in der Build-Pipeline automatisieren. Das ist effizienter als nachtraegliche manuelle Pruefungen und liefert gleichzeitig die Nachweise fuer Kunden und Auditoren.

Automatisierte SBOM-Generierung und Image-Signing

#!/bin/bash
# nis2-compliant-build.sh
# CI/CD-Pipeline-Schritt: Build, Scan, SBOM, Sign

set -euo pipefail

IMAGE="registry.company.de/saas-platform:${CI_COMMIT_SHA}"
VERSION="${CI_COMMIT_TAG:-${CI_COMMIT_SHA:0:8}}"

# 1. Container-Image bauen
docker build -t "${IMAGE}" \
  --label "org.opencontainers.image.created=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --label "org.opencontainers.image.revision=${CI_COMMIT_SHA}" \
  --label "org.opencontainers.image.source=${CI_PROJECT_URL}" .

# 2. Schwachstellen-Scan mit Trivy
trivy image --severity HIGH,CRITICAL \
  --format json \
  --output "trivy-report-${VERSION}.json" \
  "${IMAGE}"

# Abbruch bei kritischen Schwachstellen
CRITICAL_COUNT=$(jq '[.Results[]?.Vulnerabilities[]? | select(.Severity=="CRITICAL")] | length' "trivy-report-${VERSION}.json")
if [ "$CRITICAL_COUNT" -gt 0 ]; then
  echo "Pipeline gestoppt: ${CRITICAL_COUNT} kritische Schwachstellen."
  echo "NIS2 Art. 21 (e): Deployment nicht zulaessig."
  exit 1
fi

# 3. SBOM generieren (SPDX-Format fuer Kundenkompatibilitaet)
syft "${IMAGE}" \
  -o spdx-json \
  --file "sbom-${VERSION}.spdx.json"

# 4. Image in Registry pushen
docker push "${IMAGE}"

# 5. Image signieren mit Cosign (NIS2 Supply-Chain-Integritaet)
cosign sign --key env://COSIGN_PRIVATE_KEY \
  --annotations "nis2.scan-date=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --annotations "nis2.sbom-ref=sbom-${VERSION}.spdx.json" \
  --annotations "nis2.trivy-critical=0" \
  --annotations "nis2.pipeline-id=${CI_PIPELINE_ID}" \
  "${IMAGE}"

# 6. SBOM an Image-Signatur anhaengen
cosign attach sbom --sbom "sbom-${VERSION}.spdx.json" "${IMAGE}"

# 7. Artefakte fuer Audit archivieren (3 Jahre Aufbewahrung)
aws s3 cp "trivy-report-${VERSION}.json" \
  "s3://compliance-archive/nis2/scans/${VERSION}/"
aws s3 cp "sbom-${VERSION}.spdx.json" \
  "s3://compliance-archive/nis2/sbom/${VERSION}/"

echo "Build ${VERSION}: SBOM generiert, Image signiert, Scan bestanden."

Jeder Build produziert jetzt drei Nachweise: den Schwachstellenbericht, die SBOM und die kryptographische Signatur. Alle drei koennen Sie Ihren Kunden auf Anfrage zur Verfuegung stellen.

Admission Control: Nur signierte Images im Cluster

Die zweite Seite der Medaille: Ihr Produktionscluster akzeptiert nur Images, die aus Ihrer Pipeline stammen und signiert sind.

# cosign-verify-policy.yaml
# Kyverno-Policy: Nur signierte Images in Produktion
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
  annotations:
    policies.kyverno.io/title: NIS2 Image Signature Verification
    policies.kyverno.io/description: >-
      Stellt sicher, dass nur signierte und gescannte
      Container-Images in Produktion laufen.
      NIS2 Art. 21 Abs. 2 lit. d (Supply-Chain-Security)
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - production
                - staging
      verifyImages:
        - imageReferences:
            - "registry.company.de/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----
          required: true
---
# Network Policy: Mandantentrennung in Multi-Tenant-SaaS
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-alpha
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
        - podSelector: {}
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: shared-services
      ports:
        - protocol: TCP
          port: 443

Die Image-Verification stellt sicher, dass kein nicht-gescanntes Image in den Cluster gelangt. Die Network Policy isoliert Mandanten voneinander -- eine Kernanforderung fuer SaaS-Anbieter unter NIS2.

Mehr zu Network Policies und Netzwerksegmentierung finden Sie in unserem Security-Hardening-Guide.

Mandantentrennung: Die SaaS-spezifische NIS2-Herausforderung

Fuer SaaS-Anbieter auf Kubernetes ist Mandantentrennung die zentrale technische Herausforderung. Wenn ein Security-Incident einen Mandanten betrifft, darf er nicht auf andere uebergreifen. NIS2 verlangt, dass Sie das nachweisen koennen.

Isolationsebenen fuer Multi-Tenant-SaaS

Die vollstaendige Isolation auf allen Ebenen ist aufwendig. Fuer die meisten SaaS-Anbieter ist eine Kombination aus Namespace-Isolation, Network Policies und separaten Datenbanken der pragmatische Weg.

Kundenkommunikation: Security als Vertriebsargument

NIS2-Compliance ist nicht nur eine Pflicht -- sie ist ein Wettbewerbsvorteil. Wenn Ihr Enterprise-Kunde zwischen zwei SaaS-Anbietern waehlt und nur einer kann signierte Images, SBOMs und dokumentierte Incident-Response-Prozesse nachweisen, faellt die Entscheidung leicht.

Was Sie Ihren Kunden proaktiv anbieten sollten

Diese Dokumente kosten wenig Aufwand, wenn die technische Grundlage steht. Und sie ersparen Ihnen dutzende individuelle Kundenfrageboegen, weil die meisten Fragen damit bereits beantwortet sind.

Vertragliche Absicherung: Was in Ihre AGB und SLA gehoert

NIS2 veraendert die vertraglichen Anforderungen zwischen SaaS-Anbieter und Kunde. Pruefpunkte fuer Ihre Vertraege:

Sicherheitspflichten definieren: Welche Massnahmen treffen Sie? Welche Standards befolgen Sie? Welche Zertifizierungen haben Sie?

Incident-Notification-Klausel: Innerhalb welcher Frist informieren Sie den Kunden bei einem Sicherheitsvorfall? Wie (E-Mail, Statuspage, persoenlicher Anruf)? Was enthaelt die Meldung?

Audit-Rechte: Darf der Kunde Ihre Infrastruktur pruefen lassen? Unter welchen Bedingungen? Wer traegt die Kosten?

Sub-Processor-Klausel: Welche Unterauftragnehmer setzen Sie ein? Wie stellen Sie deren NIS2-Konformitaet sicher?

Haftungsbegrenzung: Wie ist die Haftung bei einem Sicherheitsvorfall geregelt? Gibt es eine Cyber-Versicherung?

Eine Uebersicht ueber die vertraglichen Supply-Chain-Anforderungen aus OEM-Sicht finden Sie in unserem NIS2-Zulieferer-Guide.

Schwachstellenmanagement: CVE-SLAs fuer SaaS-Anbieter

Kunden erwarten definierte Reaktionszeiten bei Schwachstellen. Hier sind realistische SLAs, die sich mit einem kleinen Team einhalten lassen:

Diese SLAs muessen messbar sein. Der Trivy Operator in Kombination mit einem Ticketsystem (Jira, GitLab Issues) macht die Einhaltung nachvollziehbar.

Wie Sie die Kosten fuer ein solches Schwachstellenmanagement kalkulieren, zeigt unser NIS2-Kosten-Guide.

Typische Fallstricke fuer Software-Unternehmen

Base-Images nicht im Scope. Sie scannen Ihren Anwendungscode, aber das Base-Image (z.B. node:20-alpine) enthaelt 15 bekannte CVEs. Ihr Kunde sieht das im SBOM und fragt nach.

SBOM nur bei Major-Releases. NIS2-orientierte Kunden erwarten SBOMs fuer jede deploybare Version, nicht nur fuer Major-Releases. Automatisieren Sie die Generierung in der Pipeline.

Keine Mandantentrennung dokumentiert. Sie haben Namespace-Isolation implementiert, aber kein Dokument, das sie beschreibt. Der Auditor des Kunden findet keine Evidenz.

Incident-Notification ohne Prozess. Ein Vorfall tritt auf, aber niemand weiss, welche Kunden betroffen sind und wie sie informiert werden. Der Prozess muss vor dem Vorfall stehen, nicht waehrenddessen.

Open-Source-Abhaengigkeiten ohne Tracking. Ihre SaaS-Plattform nutzt 200 npm-Packages, aber Sie wissen nicht, welche Lizenzen gelten und welche CVEs offen sind. Das SBOM deckt das auf.

Fahrplan: NIS2-Readiness fuer SaaS-Anbieter

Nach 16 Wochen koennen Sie jedem Kunden nachweisen, dass Ihre SaaS-Plattform NIS2-konform betrieben wird. Das ist kein Marketing -- das sind dokumentierte, technisch durchgesetzte Massnahmen.

Die Gesamtuebersicht ueber NIS2-Anforderungen und wie sie sich auf Kubernetes abbilden, finden Sie in unserem NIS2-Compliance-Kubernetes-Guide. Wie Sie den Audit bestehen, beschreibt unser NIS2-Audit-Guide.

Fazit

Fuer Software-Unternehmen und SaaS-Anbieter ist NIS2 keine abstrakte Regulierung -- sie veraendert, was Kunden von Ihnen erwarten. SBOMs, signierte Images, dokumentierte Incident-Response-Prozesse und nachweisbare Mandantentrennung werden zum Standard in Enterprise-Vertraegen.

Die technische Umsetzung ist mit den richtigen Tools in der CI/CD-Pipeline beherrschbar. Der groessere Aufwand liegt in den Prozessen und der Dokumentation. Wer jetzt anfaengt, baut einen Wettbewerbsvorteil auf. Wer wartet, wird von Kundenanforderungen ueberrollt.