Architektur-Review mit KI: vom Diagramm zum Pull Request
Für den Cyber Resilience Act brauchen Sie eine Beschreibung von Entwurf und Architektur Ihres Produkts und eine Risikobewertung. In vielen Teams ist das ein Diagramm, das vor einem Jahr jemand gezeichnet hat und das heute nicht mehr stimmt. Das Architektur-Review von Secupipe erstellt diese Beschreibung aus Ihrem Code, prüft sie und schlägt Verbesserungen vor, direkt in Ihrer Pipeline.
Aus dem Code ein Architekturmodell
Das Review läuft als Job auf Ihrem CI-Runner, im selben Container wie Autofix und Code-Scan. Zuerst sammelt es ohne KI die Fakten: Paket-Manifeste, Dockerfiles, Compose, Kubernetes, Terraform, CI-Dateien, freigegebene Ports, die Namen der Umgebungsvariablen und die Hosts, die der Code anspricht. Dann beschreibt ein KI-Agent die Architektur:
- Komponenten: Dienste, Jobs, Frontends, Datenbanken, Speicher und Dienste Dritter.
- Vertrauenszonen: Nutzer und Clients, Rand (Proxy, CDN, Gateway), Anwendung, Daten, Dienste Dritter.
- Datenflüsse: wer mit wem spricht, über welches Protokoll, mit welcher Anmeldung, verschlüsselt oder nicht.
- SBOMs: Jede Komponente ist mit der SBOM verknüpft, die Ihre Pipeline für sie hochlädt. Ein Klick auf die Komponente führt zu allen Paketen und Schwachstellen.
Aus dem Modell zeichnet Secupipe das Diagramm. Unverschlüsselte Verbindungen sind rot markiert, jede Komponente zeigt die Zahl ihrer Befunde. Bei jedem Lauf entsteht das Diagramm neu und bleibt damit aktuell.
Drei Prüfer, ein Gegenprüfer
Auf das Modell setzen drei Agenten parallel an:
- Sicherheit: ein Bedrohungsmodell nach STRIDE für jeden Datenfluss, der eine Zonengrenze überquert. Wird am Eingang angemeldet und berechtigt? Sind Mandanten getrennt? Gibt es Ratenbegrenzung und Größenlimits? Wo liegen die Geheimnisse?
- CRA Anhang I: die grundlegenden Anforderungen, soweit sie am Repository erkennbar sind. Sichere Voreinstellungen, Zugriffsschutz, Verschlüsselung, Protokollierung, ein Löschweg für Nutzerdaten, SBOM, Meldekanal für Schwachstellen und sichere Updates.
- Struktur und Betrieb: Schichten und Kopplung, einzelne Ausfallpunkte, fehlende Zeitlimits, Konfiguration im Code statt in der Umgebung, Datensicherung.
Jeder Befund braucht Belege mit Datei und Zeile. Ein Skript prüft, ob es diese Dateien und Zeilen wirklich gibt; Befunde mit erfundenen Belegen fallen weg. Danach versucht ein weiterer Agent, jeden Befund zu widerlegen. Nur was standhält, landet in Secupipe.
Befunde, die Sie bewusst hinnehmen, markieren Sie mit Begründung. Die Agenten melden sie dann nicht mehr, und sie zählen nicht für das Freigabe-Gate. Was seit dem letzten Lauf neu ist oder weggefallen ist, sehen Sie auf einen Blick.
Die Gesamtarchitektur eines Projekts
Ein Produkt besteht selten aus einem Repository. Secupipe ordnet Repositorys zu Projekten, etwa shop-api, shop-web und shop-site zum Projekt shop. Nach jedem Review fasst ein weiterer Agent die Modelle aller Repositorys zusammen: Dieselbe Komponente aus Sicht mehrerer Repositorys wird ein Knoten, Datenflüsse zwischen den Repositorys kommen dazu. Dafür liest er keinen Quellcode, nur die Modelle und Befunde.
Daraus entstehen 5 bis 15 Verbesserungsvorschläge für die Architektur als Ganzes. Sie wiederholen nicht die Einzelbefunde, sondern fassen sie zusammen: ein gemeinsamer, gehärteter Deploy-Weg statt drei unterschiedlicher, eine Quelle für Geheimnisse, ein geprobter Wiederanlauf. Jeder Vorschlag nennt den Nutzen, den Aufwand (Tage, Wochen, Monate), die Priorität und die Befunde, die er erledigt.
Vom Befund zum Pull Request
Zu jedem Befund lässt sich ein KI-Fix anfordern. Startet der Fix-Lauf, setzt ein Agent die Empfehlung im Repository um, prüft Build und Tests und öffnet einen Pull Request mit Begründung. Gemergt wird nie automatisch; den Pull Request prüft Ihr Team.
Nicht alles lässt sich im Code beheben. Fehlt etwa eine Datensicherung auf dem Server, meldet der Agent »nicht möglich« und schreibt dazu, was ein Mensch tun muss. Sind Build oder Tests nach der Änderung rot, gibt es keinen Pull Request. Änderungen an CI-Workflows übernimmt das Skript grundsätzlich nicht.
Ihr Code bleibt bei Ihnen
- Das Review läuft auf Ihrem CI-Runner. Die prüfenden Agenten dürfen nur lesen und führen keinen Code Ihres Repositorys aus.
- Secupipe sieht keinen Quellcode. Gemeldet werden Modell, Diagramm und Befunde mit Dateipfad und Zeile.
- Der Quellcode geht an den KI-Anbieter, dessen Schlüssel Sie hinterlegen: Anthropic, Amazon Bedrock oder Google Vertex in einer EU-Region, oder ein lokales LLM in Ihrem Netzwerk.
- Sie entscheiden, wann es läuft: auf Knopfdruck in Ihrer CI, bei Pull Requests oder nach Zeitplan.
An uns selbst ausprobiert
Bevor wir das Review anbieten, haben wir es auf unsere eigenen Produkte angewendet: auf Secupipe und auf ioffice.one, je drei Repositorys für API, Web-App und Website. Je Projekt entstand eine Gesamtarchitektur mit 33 Komponenten und 14 Verbesserungsvorschlägen. Die Vorschläge reichten von einer einheitlich abgesicherten Lieferkette über einen gemeinsamen Deploy-Weg mit Rückfallversion bis zur geprobten Datensicherung. Den ersten KI-Fix, Zeitlimits für den HTTP-Server samt Test, hat der Agent in wenigen Minuten geschrieben.
So richten Sie das Review ein
Das Architektur-Review gehört zum Modul KI. In GitHub Actions genügt ein Job, den Sie von Hand starten:
on:
workflow_dispatch:
jobs:
architektur:
runs-on: ubuntu-latest
container: ghcr.io/costa-chown/secupipe-autofix:1
steps:
- uses: actions/checkout@v5
with: { fetch-depth: 0 }
- run: secupipe-archreview
env:
SECUPIPE_TOKEN: ${{ secrets.SECUPIPE_TOKEN }}
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
REPO: ${{ github.repository }}
Für GitLab CI und andere Systeme gibt es denselben Container. Das Ergebnis finden Sie in Secupipe unter Architektur; den Bericht mit Diagramm laden Sie als Markdown für Ihre technische Dokumentation herunter.
Kostenlos starten SBOM kostenlos prüfen