openCode-Repositories automatisch auf D-Stack-Konformität prüfen
Der Deutschland-Stack bewertet seine Standards und Technologien anhand von sechs offiziellen Konformitäts-Kriterien (Digitale Souveränität, Interoperabilität, Zukunftsfähigkeit, Marktrelevanz, Vertrauenswürdigkeit, Nachhaltigkeit). Ein Reifegradmodell, das diese Kriterien automatisiert erhebt und nutzt, ist laut derselben Seite vorerst zurückgestellt. Eine automatisierte Prüfung steht also noch aus; diese Seite skizziert, wie eine solche unter Nutzung des Wissensgraphen aussehen könnte.
Der D-Stack wird auf openCode veröffentlicht und setzt laut Gesamtbild auf DevSecOps mit SBOM (einer Software-Stückliste der verwendeten Komponenten) und Mechanismen für Scanning und Analyse. Welche Bausteine ein Projekt nutzt, steht in seinen Abhängigkeiten (Dependencies): den Manifest-Dateien wie package.json, build.gradle oder pyproject.toml, die zu praktisch jeder Software gehören. Ein Scanner liest die Abhängigkeiten aus und ordnet jeder die D-Stack-Standards zu, die hinter ihr stecken. Denn eine Abhängigkeit deckt sich selten direkt mit einer Kachel der Landkarte, setzt aber meist mehrere um: fastapi etwa fehlt in der Landkarte, implementiert aber REST und OpenAPI; psycopg spricht das PostgreSQL-Protokoll.
Die geprüften Repositories: was real ist und was geschätzt
Aufgenommen sind zwei reale openCode-Projekte und zwei klar als (Beispiel) markierte, erfundene Repositories. Real sind SPARK, das quelloffene Beschleunigungs-Projekt des BMDS für Planungs- und Genehmigungsverfahren (ein Python-Monorepo mit über 40 Manifest-Dateien), und das FIM-Portal der FITKO für das Föderale Informationsmanagement (Python, Rust und TypeScript); ihre Abhängigkeiten sind die tatsächlich deklarierten (Stand Juni 2026), die gescannten Dateien im Dashboard verlinken auf die Originale. Die beiden erfundenen Beispiele zeigen gezielt, was reale Projekte selten offenlegen: eines, das auf proprietäre Produkte setzt (das Souveränitätsrisiko, um das es bei der Vergabe geht), und eines, das durchgängig auf offene D-Stack-Standards aufbaut (das Vorbild).
Das Auslesen der Manifeste ließe sich vollständig automatisieren; der aufwendige Teil ist die Zuordnung der Pakete zu Standards. Darum steht hier bewusst eine repräsentative Auswahl aus einigen Manifesten statt jeder einzelnen Abhängigkeit.
Die D-Stack-Standards, auf die abgebildet wird, sind real (die Kacheln der Tech-Stack Landkarte). Die Zuordnung Paket → Standard (dstack:abgebildetAuf) ist dagegen in allen Fällen eine handkuratierte Schätzung, die aktiv gepflegt werden muss, keine geprüfte Konformitätsaussage (deshalb ein eigenes Prädikat statt dct:conformsTo). Sie ist eine eigene, wachsende Wissensschicht: was hinter einer Abhängigkeit steckt, lässt sich einmal erfassen und für jedes weitere Projekt wiederverwenden. Wo keine Zuordnung vorliegt, wird das Paket als nicht erkannt ausgewiesen.
1. Reporting-Dashboard: alle Repositories auf einen Blick
Die automatisierte Prüfung über mehrere Repositories, wie sie bspw. ein Dashboard zeigen würde: je Repository die geprüften Manifeste samt Prüfumfang, wie viele D-Stack-Standards seine Abhängigkeiten nachweislich nutzen und wie viele davon verbindlich sind (also von einem Standardbereich des IT-Planungsrats gefordert), wo blinde Flecken (reale Standards ohne Landkarte-Kachel) und proprietäre Bausteine liegen, und eine zusammenfassende Bewertung.
Ein Detail, das im Vergleich der beiden realen Projekte auffällt: SPARK und das FIM-Portal sind technisch grundverschieden gebaut und treffen über ihre Abhängigkeiten dennoch dieselben Kernstandards wie REST, OpenAPI, HTTP und PostgreSQL. Genau dafür bildet der Scanner auf Standards statt auf einzelne Pakete ab: Die Prüfung ist sprach- und stack-agnostisch und vergleicht Projekte auf der Ebene, auf die es ankommt.
2. Steckbrief eines Repositories: Befunde und Bewertung
Der Blick auf ein einzelnes Repository. Zuerst die formale Prüfung, Datei für Datei: die deklarierten Abhängigkeiten und ihr Befund, also konform (bildet ein D-Stack-Element ab, ggf. auch mehrere), blinder Fleck (ein realer Standard ohne Kachel), proprietär (ein erkanntes geschlossenes Produkt mit offener Stack-Alternative) oder nicht erkannt (der Scanner hat keine Zuordnung, also bewusst keine Aussage). Verbindlich geforderte Standardbereich-Bausteine sind eigens markiert.
Jedes D-Stack-Element trägt zusätzlich eine eigene Bewertung auf sechs Kriterien (0 bis 100 %), von Souveränität bis Nachhaltigkeit, hier für die Bausteine, die dieses Repository nutzt. Für ein bestehendes Projekt wie SPARK oder das FIM-Portal ist das eine Standortbestimmung; bei einer künftigen Vergabe wären es die Kriterien, an denen sich Angebote messen lassen. Das Kriterium ist wählbar.
3. Wie sich das in openCode einfügt
openCode bewertet Repositories bereits automatisch in fünf Badge-Dimensionen (Wartung, Nachnutzung, Lizenz, Sicherheit, Lieferketten-Transparenz), abgestimmt mit dem BSI im Rahmen der Strategie für sichere Softwarelieferketten. Bekannte Schwachstellen (CVE) liefern dabei externe Quellen wie OSV; die D-Stack-Konformität ließe sich als sechste Dimension aus denselben Manifest- und SBOM-Daten ergänzen, ohne etwas am bestehenden System zu ändern. Drei der sechs D-Stack-Kriterien deckt openCode schon ab, die anderen drei sind genau das, was ein D-Stack-Badge hinzufügt.
Der sechste Badge ist ein Vorschlag dieses Prototyps, kein offizieller openCode-Badge; die fünf bestehenden sind reale openCode-Badges.