Die Compliance staatlicher Software beschränkt sich nicht darauf, vor der Veröffentlichung eine abschließende Prüfung zu bestehen, sondern beginnt mit der Art und Weise, wie Code geschrieben, Abhängigkeiten verwaltet und Entscheidungen dokumentiert werden. Ein auf dem JetBrains-Blog veröffentlichter Beitrag stellt im Kontext der Qodana-Plattform fünf praktische Bereiche vor, die Softwareentwicklungsteams im öffentlichen Sektor nutzen können, um Compliance-Risiken zu verringern, wobei sich die rechtlichen Anforderungen von Land zu Land unterscheiden.
Diese Frage gewinnt zusätzlich an Bedeutung, weil staatliche Systeme große Mengen personenbezogener und sensibler Daten verarbeiten. Der Beitrag zitiert den IBM Cost of a Data Breach Report 2026 mit der Angabe, dass die durchschnittlichen weltweiten Kosten einer Datenschutzverletzung 4,99 Millionen US-Dollar betrugen. Außerdem verweist er auf einen Bericht des Ponemon Institute und von Globalscape, der die Kosten der Nicht-Compliance auf das 2,71-Fache der Compliance-Kosten schätzte. Diese Zahlen stammen aus den Berichten, auf die sich die Quelle stützt, und sind keine unabhängige Schätzung von JetBrains.
1. Sicherheit und Datenschutz
Die Risiken beginnen bei bekannten Fehlern wie dem Speichern von Zugangsdaten im Code, einer unzureichenden Validierung von Ein- und Ausgaben oder der Verwendung veralteter und schwacher Verschlüsselungsalgorithmen. Dies kann zur Offenlegung personenbezogener Informationen oder zur Verletzung der Kontrollen von Sicherheitsrahmenwerken wie ISO/IEC 27001 führen und dadurch die Zertifizierung und den Ruf der Organisation gefährden.
Die Regeln unterscheiden sich je nach Rechtsordnung. Öffentliche Einrichtungen in Ländern der Europäischen Union unterliegen der DSGVO, während zentrale Stellen im Vereinigten Königreich Anforderungen unterliegen, zu denen die UK GDPR, der Data Protection Act 2018 und die Standards des National Audit Office gehören. In den Vereinigten Staaten gibt es Rahmenwerke wie die Federal Acquisition Regulation, das Defense Federal Acquisition Regulation Supplement und FedRAMP.
In der Praxis empfiehlt der Beitrag, Datenschutz und Abwehrmaßnahmen von Beginn an in den Softwareentwicklungslebenszyklus zu integrieren und sie nicht auf die Testphase oder die Zeit vor der Bereitstellung zu verschieben. Zu den genannten Maßnahmen gehören die sichere Speicherung von Zugangsdaten, eine klare Verwaltung der Einwilligung der Nutzer, Penetrationstests vor der Veröffentlichung und die Fortführung automatisierter Tests. Auch externe Abhängigkeiten sollten als aktive Risiken und nicht als neutrale Komponenten behandelt werden.
2. Verträge, Beschaffung und Open-Source-Abhängigkeiten
Software, die staatliche Beschaffung oder Lieferantenvereinbarungen verwaltet, kann vertragliche Probleme verursachen, etwa die Nichteinhaltung von Service Level Agreements oder von Abnahmekriterien. Ebenso kann ein geheimer API-Schlüssel in einem Entwicklungszweig bei gleichzeitig fehlender SAST-Prüfung dazu führen, dass Code weitergegeben wird, der die Lieferbedingungen nicht erfüllt.
Open-Source-Abhängigkeiten fügen eine weitere rechtliche und technische Ebene hinzu, da ihre Lizenzen Klauseln wie Copyleft oder Beschränkungen der kommerziellen Nutzung enthalten können. Dies kann mit Beschaffungsregeln kollidieren oder Streitigkeiten über geistiges Eigentum auslösen. Daher schlägt der Beitrag eine automatisierte Lizenzprüfung auf Abhängigkeitsebene sowie Qualitätsschranken innerhalb von CI/CD vor, die verhindern, dass nicht konformer Code in die Lieferphase gelangt.
3. Auditierbare Nachweise und Verantwortlichkeit
Bei Audits reicht es nicht aus zu sagen, dass Kontrollen vorhanden sind; Kontrollen ohne Belege können als nicht nachgewiesen gelten. Der Beitrag ist der Ansicht, dass die Abhängigkeit von manuellen Genehmigungen und inkonsistenten Ergebnissen zwischen Qualitätssicherungsteams die Wahrscheinlichkeit eines fehlgeschlagenen Audits erhöht und die Risiken technischer Schulden vergrößert.
Der vorgeschlagene praktische Ansatz besteht darin, ein digitales Register zu erstellen, das Tests, Rückverfolgbarkeit und Prüfergebnisse mit den Phasen des Entwicklungszyklus verknüpft. Dies hilft bei der Erstellung automatisierter Auditberichte und bei der Vorlage objektiver Nachweise während der Prüfung von Kontrollen wie den NIST-Leitlinien für föderale Systeme in den Vereinigten Staaten oder den Anforderungen von ISO/IEC 27001 und den Standards des National Audit Office im Vereinigten Königreich.
4. Kontinuität und langfristiger Support
Der Ausfall eines staatlichen Systems kann zur Unterbrechung grundlegender Dienstleistungen für Bürger führen. Daher sollte die Priorität nicht auf einer schnellen Reparatur liegen, die künftige Probleme anhäuft. Nicht unterstützte Open-Source-Komponenten können die Anwendung von Patches verhindern. Auch der Übergang eines Systems zwischen verschiedenen Auftragnehmern oder Teams wird riskanter, wenn Schwachstellen und der Kontext von Entscheidungen nicht dokumentiert sind.
Zu den vorgeschlagenen Praktiken gehören die Überwachung der Aktualität von Abhängigkeiten, die Verwendung der neuesten stabilen Version oder der verfügbaren Patch-Version, die Verringerung der Zahl externer Abhängigkeiten, die Durchführung von Unit- und Integrationstests sowie der Einsatz statischer Analyse zur frühzeitigen Erkennung von Codefehlern. Diese Praktiken stehen auch mit Anforderungen an die Geschäftskontinuität wie ISO 22301 in Verbindung.
5. Infrastruktur-Governance und Richtlinien
Entwicklungswerkzeuge und Cloud-Dienste müssen mit Sicherheits-Baselines und staatlichen IT-Richtlinien übereinstimmen. Der Beitrag nennt beispielsweise die Richtlinie Government Cloud First im Vereinigten Königreich sowie Einschränkungen, die öffentliche Stellen für die Nutzung von SaaS-Diensten oder externen Cloud-Abhängigkeiten festlegen können, insbesondere beim Umgang mit sensiblen Daten oder FedRAMP-Anforderungen.
Aus betrieblicher Sicht stellt der Verlust institutionellen Wissens ein Risiko für langlebige Systeme dar. Die Dokumentation des Kontexts von Entscheidungen, Umgehungslösungen und deren Gründen hilft neuen Teams bei der Wartung der Infrastruktur. Lokal gehostete oder von externen Netzwerken isolierte Werkzeuge können ebenfalls eine geeignete Option sein, wenn die Richtlinie die Nutzung einer externen Cloud verhindert.
Was ändert sich praktisch?
Die wichtigste Schlussfolgerung besteht nicht im Kauf eines bestimmten Werkzeugs, sondern darin, Compliance in kontinuierliche Kontrollen innerhalb der Entwicklungsumgebung umzuwandeln: Sicherheits- und Lizenzprüfungen, die Erkennung von Geheimnissen, die Nachverfolgung von Abhängigkeiten, automatisierte Tests sowie Richtlinien, die in CI/CD durchgesetzt und dokumentiert werden können. Dieser Ansatz verringert die Abhängigkeit von einer verspäteten manuellen Prüfung, beseitigt jedoch nicht die Notwendigkeit, rechtliche Anforderungen auszulegen und menschliche Verantwortlichkeiten festzulegen. Der Beitrag belegt außerdem nicht, dass diese Maßnahmen in jedem Land eine vollständige Compliance gewährleisten; er weist ausdrücklich darauf hin, dass die Regeln je nach Standort und angewandten Richtlinien unterschiedlich sind. Qodana wird in diesem Kontext als Werkzeug vorgestellt, das sich in Entwicklungsumgebungen und Integrationspipelines integrieren lässt. Dieser werbliche Aspekt sollte von den allgemeinen Grundsätzen getrennt werden, die mit unterschiedlichen Werkzeugen umgesetzt werden können.