Feedback zu Kritierien und deren Messbarkeit

Worum geht es?

Die Kriterien des Stacks (https://deutschland-stack.gov.de/kriterien/) sind nicht hinreichend objektiv genug, um einen fairen Vergleich von unterschiedlichen Komponenten zu ermöglichen.

Damit diese Kriterien zu einer Verbesserung der adressierten Aspekte beitragen, muss es möglich sein, diese schnell und objektiv auf Basis möglicherweise bereits vorhandener Metriken zu erfassen und zu vergleichen. Es braucht Messbarkeit und Vergleichbarkeit, dass diese Metriken zu einer Verbesserung beitragen können.

Was kann daran verbessert werden?

Aspekte sollten so weit möglich, aus bereits vorhandenen, objektiv messbaren Faktoren abgeleitet werden.

Beispiele für mögliche Faktoren sind die folgenden.

Metriken zum Messen der Software Delivery Performance (Hauptkriterium Zukunftsfähigkeit)

Für die Messung der Software Delivery Performance gibt es bereits etablierte Metriken in Form von DORA (https://dora.dev/quickcheck/). Über vier Metriken lassen sich Software Delivery Performance aber auch DevOps Qualität bewerten, basierend auf der Häufigkeit von neuen Releases, der Releasegeschwindigkeit sowie der Stabilität von Releases.

Diese Metriken können als Teil des Hauptkriteriums Zukunftsfähigkeit, aber auch als Aspekt der messbaren Resilienz genutzt werden und sind ein numerischer Score, der sich beim Offenlegen von CI-Pipelines auch vollständig automatisch berechnen lässt. Teilaspekte wie Releasealter und Releasefrequenz sind darin bereits enthalten.

Metriken zum Messen der Offenheit (Hauptkriterium Nachhaltigkeit)

In Konsolidierung der Bewertung der Offenheit sollte die in den Open Code Badges bereits etablierte Lizenzprüfung auf Dokumentationen und Software Code angewendet werden. (https://badges.opencode.de/official-badges/open-source-badge/)

Metriken zum Messen der Vertrauenswürdigkeit (Hauptkriterium Vertrauenswürdigkeit)

Die Metriken zum Messen der Vertrauenswürdigkeit sind generell zu weich definiert. Die Möglichkeit zur Auditierung und Zertifizierungen haben möglicherweise viele Projekte, dies führt aber nicht automatisch zur Vertrauenswürdigkeit.

Das Kriterium Zero Trust als solches ist als einfaches Ja/Nein nicht sinnhaft, weil es fortgeschrittene Zero Trust Architekturen mit solchen gleichsetzt, die nur in Teilaspekten nach Zero Trust Prinzipien handeln.

Ein etabliertes Modell zur Bewertung von Zero Trust Architekturen ist das Zero Trust Maturity Modell der CISA (https://www.cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf), bei dem ein Projekt mindestens in allen relevanten Bereichen auf das Level Initial kommen sollte, um überhaupt ansatzweise als Zero Trust gewertet werden zu können. Weitere Härtungen im Bereich Zero Trust können dann als entsprechend höherwertiges Zero Trust gewertet werden und an bestimmte Schutzbedarfe gebunden werden.

Erfahrungen und mögliche Interessenskonflikte der beitragenden Person in Bezug auf den Konsultationsgegenstand

Bianca Kastl ist aktuell beruflich Product Owner für das Gesundheitsamt der Stadt Frankfurt am Main und technisch hauptverantwortlich für die Fachanwendungsplattform GA-Lotse mit dem Schwerpunkt auf Gesundheitsämtern. Die Umsetzung ist ein Kooperationsprojekt des Hessischen Ministeriums für Familie, Senioren, Sport, Gesundheit und Pflege mit dem Gesundheitsamt Frankfurt unter der EU-Förderung NextGenerationEU. Das Budget liegt bei über 24 Millionen Euro. GA-Lotse ist nach Stand der Technik umgesetzt, cloud native, konsequent nach Zero Trust umgesetzt und verfolgt in der Entwicklung einen konsequenten DevSecOps-Ansatz. Die Plattform wird aktuell in 12 von 24 Kommunen in Hessen seit mehr als einem Jahr betrieben und hat bereits aktive Nachnutzung im Sinne von Ko-Kreation der Plattform-Komponenten in vier Kommunen in Schleswig-Holstein. GA-Lotse ist mehrfach ausgezeichnet in den Disziplinen IT-Security, Open Source und Nutzerzentrierung (InfoSec Impact Award, Finalist Open Source Wettbewerb, OpenCoDE Top 20 Oktober 2025, Preis für gute Verwaltung 2025). GA-Lotse ist als Open Source auf OpenCoDE verfügbar und entsprechend nachnutzbar.

Zivilgesellschaftlich ist sie 1. Vorsitzende des Innovationsverbund Öffentliche Gesundheit und engagiert sich für eine bessere Digitalisierung von Verwaltung und Gesundheitswesen in Deutschland. Sie war dabei in den letzten Jahren mehrfach als Sachverständige zu Themen der Digitalisierung in Gesundheitswesen und Verwaltung geladen (OZG 2.0, Gesundheitsdatennutzungsgesetz, Open Source).

Ihr fachlicher Schwerpunkt sind skalierende, sichere digitale Infrastrukturen, Systemarchitekturen, Cloud native Anwendungen, IT-Security mit dem Fokus auf Zero Trust Prinzipien, Privacy sowie Barrierefreiheit und User Experience, seit Jahren in Open Source.

Für den InÖG hat sie in der Pandemie IRIS connect, eine Open Source Kommunikationsinfrastruktur im öffentlichen Gesundheitsdienst, als Betriebsverantwortliche von 2021 bis 2022 an begleitet. Die Betriebsverantwortung umfasste dabei 54 von 116 möglichen Ämter in NRW, Hessen, Thüringen und Sachsen in einem sehr heterogenen Betriebsszenario von SaaS für ganze Bundesländer zu On-Premises Selfhosting in einzelnen Kommunen.