Cybersecurity für Softwarehersteller: CRA, NIS2-Lieferkette und Pentests

Welche Regeln für dich gelten

Wenn du Software in der EU verkaufst, macht dich der Cyber Resilience Act zum Hersteller mit Produktpflichten, und deine regulierten Kunden legen ihre eigenen obendrauf.

Cyber Resilience Act (EU) 2024/2847. Software ist nach Artikel 3 Absatz 1 ein Produkt mit digitalen Elementen, und Fernverarbeitung, die dein Produkt braucht, gehört nach Artikel 3 Absatz 2 dazu. Artikel 13 listet die Herstellerpflichten: eine Risikobewertung, Konformität mit den grundlegenden Anforderungen aus Anhang I Teil I (sichere Standardkonfiguration, keine bekannten ausnutzbaren Schwachstellen bei Auslieferung, Schutz von Vertraulichkeit und Integrität, minimierte Angriffsfläche, Protokollierung), die Schwachstellenbehandlung aus Anhang I Teil II (eine Software Bill of Materials, Behebung ohne Verzögerung, regelmäßige Tests, eine Richtlinie zur koordinierten Offenlegung, Sicherheitsupdates getrennt von Funktionsupdates und kostenlos während des Unterstützungszeitraums) sowie einen Unterstützungszeitraum von mindestens fünf Jahren nach Artikel 13 Absatz 8, sofern das Produkt nicht erkennbar kürzer genutzt wird. Artikel 14 ergänzt die Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Vorfälle ab 11. September 2026. Alles andere gilt ab 11. Dezember 2027 mit CE-Kennzeichnung. Produkte aus Anhang III wie Betriebssysteme, Browser, Passwortmanager, VPN- und Identitätsmanagement-Software sind wichtige Produkte mit strengerer Konformitätsbewertung. Artikel 24 schafft die Rolle des Open-Source-Stewards; nicht-kommerzielle Open Source ist außerhalb des Anwendungsbereichs.

NIS2 über das deutsche BSIG. Deine Kunden in regulierten Sektoren müssen die Sicherheit der Lieferkette nach Artikel 21 Absatz 2 Buchstabe d der Richtlinie und § 30 BSIG managen, und das kommt bei dir als Sicherheitsfragebogen, vertragliches Auditrecht und Klausel zur Vorfallsmeldung an. Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste sind nach Anhang I selbst Einrichtungen.

DORA (EU) 2022/2554 gilt, wenn deine Kunden Finanzunternehmen sind: Kapitel V macht dich zum IKT-Drittdienstleister mit Pflichtvertragsklauseln, Audit- und Ausstiegsregelungen.

DSGVO Artikel 28 und 32 regeln dich als Auftragsverarbeiter und verlangen geeignete technische Maßnahmen, einschließlich regelmäßiger Überprüfung ihrer Wirksamkeit.

Wo Angreifer anfangen

Bei einem Softwareprodukt sind die API und die Release-Pipeline der Perimeter.

• Authentifizierung und Sitzungen: Token-Prüfung, Passwort-Reset-Abläufe, Single-Sign-On-Anbindungen, langlebige API-Schlüssel.
• Autorisierung: objekt- und funktionsbezogene Prüfungen über Mandanten hinweg, die häufigste Schwäche in mandantenfähigen Produkten.
• Eingabeverarbeitung: Injection in Suche, Filtern, Datei-Uploads, Templates und Berichtsgenerierung, Server-Side Request Forgery in Cloud-Metadaten.
• Abhängigkeiten und Build: veraltete Bibliotheken mit bekannten CVEs, CI/CD-Geheimnisse, unsignierte Release-Artefakte, Container-Images aus unbekannten Basen.
• Installer und On-Premises-Deployments: Standardpasswörter, mitgelieferte Datenbanken auf allen Interfaces, Update-Kanäle ohne Signaturprüfung.
• Integrationen: Webhooks, OAuth-Clients, Plug-ins und Importformate, die der Gegenseite vertrauen.

Was Assessments typischerweise finden

Typische Findings aus Web-, API- und Backend-Pentests kommerzieller Software, anonymisiert: eine API, die beim Ändern der Objekt-ID in der URL die Datensätze jedes Mandanten lieferte, weil Autorisierung am Endpunkt, aber nicht am Objekt geprüft wurde; JSON Web Tokens ohne Audience-Prüfung, sodass ein Token aus dem Gratis-Tarif das Bezahlprodukt öffnete; Mass Assignment, mit dem ein Nutzer seine eigene Rolle setzen konnte; Server-Side Request Forgery aus einer URL-Vorschau in den Cloud-Metadatendienst und von dort zu Zugangsdaten; eine Admin-Oberfläche auf einem Nicht-Standard-Port ohne Authentifizierung im On-Premises-Installer; ein Mobile-Client mit dem Signaturgeheimnis des Backends im Bundle; und Dutzende Abhängigkeiten mit veröffentlichten CVEs im ausgelieferten Image.

Unter dem CRA ist allein der letzte Punkt eine Konformitätslücke: Anhang I Teil I verlangt, dass Produkte ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden.

Ein sinnvolles erstes Projekt

Fang mit dem Produkt an, das die meisten Kunden unter NIS2 oder DORA hat, denn von dort kommen die Fragebögen.

1. Scoping und Einstufung: welche Teile in Verkehr gebracht werden, welche Fernverarbeitung sind, ob das Produkt ein wichtiges Produkt nach Anhang III ist, welchen Unterstützungszeitraum du zusagst. Ein Tag.
2. Grey-Box-Penetrationstest der Anwendung und ihrer API mit Testkonten in zwei Mandanten, plus Review des Installers oder Container-Images und der Cloud-Konfiguration. Ein bis zwei Wochen.
3. CRA-Gap-Analyse deines Release-Prozesses: SBOM-Erzeugung, Eingang und Triage von Schwachstellen, Offenlegungsrichtlinie und security.txt, das 24-Stunden-Runbook für Meldungen, Update-Signierung und die Trennung von Sicherheits- und Funktionsupdates. Drei bis fünf Tage.
4. Fixen und Retest, dann Scanning, Abhängigkeitsprüfung und SBOM-Erzeugung in die Pipeline ziehen, damit das nächste Release mit Vorsprung startet.

Typischer Aufwand für die Schritte 1 bis 3 sind 12 bis 20 Personentage, also 15.000 bis 32.000 Euro zu Marktpreisen. Viele Hersteller finanzieren das aus dem Vertriebszyklus, den es freimacht.

Was Zyberum hier tut und was nicht

Wir testen Webanwendungen, APIs, Cloud-Umgebungen und Mobile-Clients, reviewen Code und Build-Pipelines, machen CRA-Gap-Analysen, schreiben die Prozesse für Schwachstellenbehandlung und Offenlegung und schulen Entwicklungsteams in Secure Coding. Wir helfen dir, Kundenfragebögen mit Nachweisen statt Versprechen zu beantworten. Wir sind keine benannte Stelle und vergeben weder CE-Kennzeichnung noch Zertifikate, wir verkaufen keine Scanner oder andere Sicherheitsprodukte Dritter, und wir testen nur mit deiner schriftlichen Erlaubnis.