Software-Entwicklungshäuser
Sie entwickeln Individualsoftware, mobile und Desktop-Anwendungen,
Backend-Systeme, APIs, Embedded Software und oft kritische
Kernanwendungen Ihrer Kunden. Ihre Arbeit ist selten sichtbar von außen,
aber regulatorisch stehen Sie im Zentrum: Sie produzieren Code, der
Geschäftsprozesse trägt.
Keine andere Gruppe ist so eindeutig von der neuen Regulierung erfasst.
Die Produkthaftungsrichtlinie nennt Entwickler ausdrücklich als
Hersteller (Art. 8), der CRA behandelt jede entwickelte Software als
Produkt mit digitalen Elementen (Art. 3 Nr. 1), und als Zulieferer
kritischer Geschäftsfunktionen sind Sie unmittelbar in DORA- und
NIS2-Lieferketten eingebunden.
Typische Projekte und ihre regulatorische Einordnung
Individualsoftware für Geschäftsprozesse
Ob Sie ein Warenwirtschaftssystem, ein Produktionsleitsystem, ein
Buchhaltungsmodul oder eine Branchenlösung entwickeln - diese Software
ist nach CRA ein Produkt mit digitalen Elementen. Ihre Kunden betreiben
sie als Kernbestandteil ihres Geschäfts. Fällt sie aus oder enthält sie
Schwachstellen, greift die Produkthaftung unmittelbar.
Bei DORA-Kunden wird solche Software oft als "kritische Funktion"
eingestuft (Art. 28 Abs. 5 DORA) - mit entsprechend verschärften
Anforderungen an Qualität, Dokumentation und Ausstiegsfähigkeit.
Mobile Apps für Endkunden und Mitarbeiter
Apps sind eindeutige CRA-Produkte. Wenn sie für regulierte Kunden
gebaut werden - Banking-Apps, Versicherungs-Apps, Gesundheits-Apps -
kommen DORA oder NIS2 hinzu. Apps, die Zahlungsverkehr, Authentifizierung
oder Gesundheitsdaten verarbeiten, fallen außerdem in den "kritischen"
CRA-Bereich nach Anhang III und IV der Verordnung.
Backends, APIs und Microservices
Backend-Entwicklung ist oft unsichtbar, aber regulatorisch am
problematischsten: Backends verarbeiten die sensibelsten Daten und
tragen die zentralen Geschäftsprozesse. Ein fehlerhaftes Backend
kann einen kompletten Betrieb stilllegen oder Daten im großen Stil
kompromittieren - Art. 6 Abs. 1 lit. c der Produkthaftungsrichtlinie
(Datenverlust als Haftungsgrund) adressiert genau diese Fälle.
Embedded Software
Embedded-Entwicklung für Industrie, Medizin, Automotive oder Energie
fällt in mehreren Dimensionen unter die neuen Gesetze: CRA als Software
in Produkten, Produkthaftung als Teil eines sicherheitsrelevanten
Produkts, NIS2 als Zulieferung für kritische Sektoren. In der Regel
kommen noch sektorspezifische Anforderungen hinzu - etwa die Maschinen-
Verordnung, IEC 62443, MDR oder UN-R 155.
Core Banking, Insurance Core, Health-Systeme
Wenn Sie Kernsysteme für Finanzinstitute, Versicherungen oder
Krankenhäuser entwickeln, arbeiten Sie am schärfsten regulierten Ende
des Spektrums. DORA betrachtet solche Systeme als "kritische
IKT-Services" (Art. 28 Abs. 5), die Lieferantensteuerung ist maximal.
Sie werden im DORA-Informationsregister Ihres Kunden prominent geführt.
Welche Gesetze greifen bei welchen Kunden
Zwei Gesetze greifen immer, unabhängig davon, für wen Sie entwickeln:
- Produkthaftungsrichtlinie (RL 2024/2853) macht Sie als Entwickler zum Hersteller (Art. 8). Datenverlust ist eigener Haftungsgrund (Art. 6 Abs. 1 lit. c), die Haftung ist nicht gedeckelt (Art. 12), und die Beweislast wird zugunsten Geschädigter erleichtert (Art. 10). Kein Vertrag gegenüber dem Kunden schützt Sie vor Direktansprüchen Dritter.
- Cyber Resilience Act (VO (EU) 2024/2847) erfasst jede von Ihnen entwickelte Software als "Produkt mit digitalen Elementen" (Art. 3 Nr. 1). Sie unterliegen Sorgfaltspflichten bei FOSS-Integration (Art. 13 Abs. 5), Vulnerability-Handling (Art. 14) und mindestens fünf Jahren Support-Periode.
Weil Software-Entwicklungshäuser oft zentrale Kernanwendungen liefern,
kommen zusätzlich DORA und NIS2 über die Kundenseite ins Spiel:
- Finanzsektor (Banken, Versicherungen, Fonds, Zahlungsdienstleister, Kryptodienstleister) bringt DORA in voller Schärfe. Art. 28 DORA mit Informationsregister, Due Diligence, Exit-Strategie, TLPT-Einbezug.
- Gesundheitswesen (Krankenhäuser, Labore, Medizinprodukte- Hersteller, digitale Gesundheitsanwendungen) bringt NIS2 plus MDR-Last plus besonders hohe Datenschutzanforderungen.
- Energie und Versorgung (Stadtwerke, Übertragungsnetzbetreiber, Gasversorger) bringt NIS2 als wesentliche Einrichtungen.
- Industrie (Automotive, Maschinenbau, Halbleiter, Chemie) bringt NIS2 als wichtige Einrichtungen, oft kombiniert mit Produktsicherheits- Anforderungen der Maschinen-Verordnung.
- Öffentliche Verwaltung und Bundesbehörden bringen NIS2 und oft zusätzlich BSI-spezifische Anforderungen (ITSiG, BSI-KritisV).
- Telekommunikation und digitale Infrastruktur sind NIS2-Sektor.
Auch ohne regulierte Endkunden gilt für alle Ihre Auftragsentwicklungen
die Produkthaftungsrichtlinie. Die Vorstellung, "das ist Sache des
Kunden", trägt rechtlich nicht.
Konkrete Konsequenzen
Rechtlich stehen auf dem Spiel:
- Unbegrenzte Haftung nach der Produkthaftungsrichtlinie - bei Softwarehäusern regelmäßig der wirtschaftlich gefährlichste Punkt, weil Ihre Software oft Kernprozesse trägt und Fehler katastrophale Folgen haben können
- Bußgelder bis 15 Mio. Euro oder 2,5 % des Jahresumsatzes nach CRA (Art. 64)
- Verlust des EU-Marktzugangs: Software, die den CRA nicht erfüllt, darf nicht mehr in Verkehr gebracht werden, bestehende Auslieferungen können zurückgerufen werden (Art. 52, 53 CRA)
- 24-/72-Stunden-Meldepflichten bei aktiv ausgenutzten Schwachstellen und Sicherheitsvorfällen (Art. 14 CRA, Art. 23 NIS2, Art. 19 DORA)
- Beweislasterleichterung nach Art. 10 Produkthaftungsrichtlinie, wenn die Sorgfaltsdokumentation fehlt - im Zweifel gegen Sie
- Verlust regulierter Kundensegmente wie Finanzdienstleister, Gesundheitsversorger oder KRITIS-Betreiber
- Direkte DORA-Aufsicht bis 1 % des weltweiten Tagesumsatzes bei kritischen IKT-Drittdienstleistern (Art. 50 DORA)
Vertraglich werden Ihre Kunden verlangen:
- Entwicklungsprozesse nach dem Stand der Technik (ISO/IEC 27001, ISO/IEC 18974 "Open Source Ready"), dokumentiert und prüfbar
- SBOM für jede Lieferung, einschließlich aller Abhängigkeiten
- Secure Coding, Code-Reviews, dokumentierte Teststrategien
- Vulnerability-Handling nach Art. 14 CRA mit klaren Reaktionszeiten
- Responsible-Disclosure-Prozess, öffentlich erreichbar
- Bei DORA-Kunden: Aufnahme ins Informationsregister, Due-Diligence- Unterstützung, Exit-Strategie, TLPT-Mitwirkung
Operativ müssen Sie etablieren:
- SBOM-Automatisierung in der CI/CD-Pipeline
- Kontinuierliches Monitoring aller eingesetzten Komponenten über den gesamten Lebenszyklus der ausgelieferten Software
- Patch-Bereitstellung und -Kommunikation an Kunden, auch Jahre nach Projektabschluss (die CRA-Support-Periode beträgt mindestens fünf Jahre)
- Incident-Response mit 24/7-Bereitschaft bei DORA-Kunden
- Beweissicherung und Dokumentation aller Sicherheitsentscheidungen für mögliche Audits oder Haftungsfälle
Finanziell kommt auf Sie zu:
- Aufbau oder Zukauf von Security-Engineering-Kapazität
- Laufende Pflegekosten für ausgelieferte Software, die Sie nicht mehr vollständig auf Neukundenprojekte umlegen können
- Versicherungsprämien, die ohne nachweisbare Prozesse steil ansteigen
- Unbegrenzte Haftung nach Produkthaftungsrichtlinie
Sicherheit ist auch ohne Pflicht ein Wettbewerbsvorteil
Wer Kernsoftware entwickelt, konkurriert gegen andere Entwicklungshäuser,
die im Pitch ähnlich gut klingen. Der Unterschied entsteht dort, wo
Professionalität nachweisbar wird: dokumentierte
SBOM, nachvollziehbares Schwachstellenmanagement,
ein funktionierender Responsible-Disclosure-Prozess,
Entwicklung nach ISO/IEC 18974.
Das ist nicht nur Compliance - es ist ein Qualitätssignal, das im
Verkauf wirkt: bessere Abschlussquoten bei anspruchsvollen Kunden,
höhere Tagessätze, günstigere Versicherungsprämien, stärkere
Kundenbindung. Ihre besten Entwicklerinnen und Entwickler bleiben
lieber dort, wo die Prozesse sauber sind. Die Investition zahlt sich
mehrfach aus - auch ohne regulatorischen Druck.
Wie OTTRIA Software-Entwickler unterstützt
Kein Entwicklungshaus kann die Sicherheit aller eingesetzten
Open-Source-Komponenten intern tragen. Moderne Projekte haben Hunderte
bis Tausende transitiver Abhängigkeiten in oft mehreren
Programmiersprachen. OTTRIA übernimmt diesen Teil:
- SBOM-Analyse und -Pflege über alle Ihre Projekte und Versionen hinweg, einschließlich transitiver Abhängigkeiten
- Vulnerability-Monitoring in Echtzeit, mit Fokus auf Komponenten, die in Ihren Projekten tatsächlich eingesetzt sind
- Silent-Fix-Detection durch aktive Code-Analyse und Commit-Überwachung
- Fehlerbehebung direkt im Open-Source-Projekt bei Komponenten, die keinen aktiven Maintainer haben oder die Sie selbst nicht beheben können
- Frühwarnung durch OTTRIAs Rolle als Open Source Steward - Sie erfahren von kritischen Schwachstellen vor der öffentlichen CVE-Veröffentlichung
- Responsible-Disclosure-Kanal für Ihre Produkte als Service
- Auditfähige Dokumentation pro Projekt und pro Kunde, vorlegbar bei DORA- und NIS2-Lieferantenbewertungen
- Unterstützung bei Exit-Strategien - OTTRIAs öffentliche Arbeit in den Open-Source-Projekten bleibt verfügbar, auch wenn Sie aus einem Projekt ausscheiden
Sie konzentrieren sich auf das, was Ihr Kerngeschäft ist: Software
entwickeln. OTTRIA liefert den Open-Source-Sorgfaltsteil, den kein
Entwicklungshaus alleine bewältigen kann.
Erstgespräch vereinbaren
Zurück zur Übersicht für Software-Dienstleister
Weiterlesen