Drei Arten zu prüfen. Eine Regel für Befunde.
Werkzeuge allein finden zu viel und verstehen zu wenig. KI allein klingt überzeugend und irrt dabei. Menschen allein sind gründlich und langsam. Unsere Methodik kombiniert die drei so, dass jede die Schwäche der anderen ausgleicht.
Die Beweisregel
Kein Befund ohne Beleg. Jeder Befund im Gutachten nennt die Fundstelle (Datei und Zeile, Endpunkt oder Konfiguration), die Schritte zur Reproduktion, die Auswirkung und eine Massnahme. Ausgaben von Werkzeugen und KI-Modellen sind Hinweise — zum Befund werden sie erst, wenn ein Mensch sie nachvollzogen hat.
Das klingt selbstverständlich, ist es aber nicht: Automatische Scanner liefern Listen mit hunderten Treffern, KI-Reviews liefern flüssig formulierte Vermutungen. Beides ungefiltert weiterzugeben, wäre bequem und würde Ihre Entwicklung mit Fehlalarmen beschäftigen. Umgekehrt melden wir, was wir nicht prüfen konnten — ein Gutachten muss seine Grenzen nennen.
Ebene 1 — Deterministische Prüfstrecke
Gleiche Eingabe, gleiches Ergebnis: Diese Prüfungen laufen in einer sauberen, isolierten Umgebung gegen einen festen Commit. Werkzeugversionen und Regelsätze werden protokolliert, damit eine Nachprüfung vergleichbar ist.
| Prüfung | Was gemessen wird | Werkzeugklasse (Beispiele, je nach Stack) |
|---|---|---|
| Reproduzierbarer Build | Baut das Projekt nach der eigenen Anleitung aus einem frischen Checkout? Sind Versionen fixiert? | isolierter Container, Lockfiles, Build-Protokoll |
| Stückliste (SBOM) | Welche Komponenten in welcher Version stecken tatsächlich drin — direkt und transitiv? | CycloneDX- bzw. SPDX-Erzeuger (z. B. Syft) |
| Bekannte Schwachstellen | Abgleich der Stückliste mit Schwachstellen-Datenbanken, Bewertung der Erreichbarkeit. | OSV-Scanner, Trivy, Paketmanager-Audits |
| Geheimnisse | Schlüssel, Tokens und Passwörter im Code und in der gesamten Git-Historie. | Gitleaks, TruffleHog |
| Statische Code-Analyse | Injection, unsichere Funktionen, fehlende Ausgabe-Kodierung, gefährliche Muster. | Semgrep, CodeQL, sprachspezifische Linter |
| Lizenzen | Verträgt sich jede Abhängigkeit mit dem geplanten Einsatz und der Weitergabe? | Lizenzscanner auf Basis der SBOM |
| Container & Infrastruktur | Privilegien, offene Ports, Root-Prozesse, Basis-Images, Ressourcenlimits — dieselben Regeln wie unser Deploy-Prüfer. | Hadolint, Trivy config, Checkov, eigene Regeln |
| Tests | Laufen die vorhandenen Tests? Was decken sie ab — und decken sie die Berechtigungslogik ab? | Testrunner des Projekts, Coverage-Messung |
| Laufendes System | Passiver und aktiver Scan des Testsystems: Header, TLS, Fehlerseiten, bekannte Angriffsmuster. | OWASP ZAP, testssl.sh |
| Barrierefreiheit | Automatisch prüfbare Kriterien nach WCAG 2.1 AA bzw. BITV 2.0 auf den Kernseiten. | axe-core, Pa11y; Rest manuell |
| Struktur | Duplikate, Komplexität, tote Pfade — Messgrössen für Wartbarkeit. | jscpd, Komplexitätsmetriken |
Ebene 2 — Eigene Heuristiken für KI-typische Fehler
Standardwerkzeuge wurden für klassisch geschriebenen Code entwickelt. Vibe-Code hat eigene Fingerabdrücke. Dafür haben wir Prüfungen gebaut, die gezielt danach suchen. Heuristisch heisst: Sie liefern Verdachtsmomente mit Gewichtung, keine Gewissheit.
Paket-Existenzprüfung
Jede Abhängigkeit wird gegen das Register geprüft: Gibt es das Paket? Seit wann? Wer pflegt es? Passt der Name auffällig gut zu einem bekannten Paket? So fallen halluzinierte und untergeschobene Pakete auf.
Platzhalter-Detektor
Sucht Mock-Daten, Beispiel-Schlüssel, Test-Logins, «TODO»-Sicherheit, deaktivierte Prüfungen und Funktionen, die nur so tun als ob. Der häufigste Weg, wie ein Prototyp unbemerkt Produktion wird.
Berechtigungsmatrix
Aus Routen und Handlern wird eine Tabelle erzeugt: Endpunkt × Rolle × Prüfung vorhanden? Lücken in dieser Matrix sind die häufigste schwere Schwachstelle in KI-gebauten Anwendungen.
Vertrauen in den Client
Erkennt Logik, die nur im Browser entscheidet: Preise, Rollen, Freigaben, Validierung. Alles, was der Server nicht nachprüft, ist manipulierbar.
Doku-Code-Abgleich
Behauptet die README Verschlüsselung, Löschfristen oder Rollen, die im Code nicht vorkommen? KI-geschriebene Dokumentation beschreibt oft die Absicht, nicht den Stand.
Entstehungsspuren
Commit-Muster, grosse ungetestete Sprünge, Stil-Brüche, widersprüchliche Bibliotheken für dieselbe Aufgabe: Hinweise, wo niemand mehr den Überblick hatte — und wo wir genauer hinsehen.
Ebene 3 — KI-gestützte kritische Tests
Wir setzen KI-Modelle ein — aber als Gegenspieler, nicht als Gutachter. Die Grundsätze:
- Getrennte Rollen. Ein Modell rekonstruiert Architektur und Datenflüsse, ein anderes sucht als «Angreifer» nach Wegen hinein, ein drittes prüft aus Sicht des Betriebs. Kein Modell bewertet seine eigene Arbeit.
- Gegenprobe über Modellgrenzen. Hypothesen, die nur ein Modell sieht, werden gezielt nachgeprüft; Einigkeit zwischen Modellen ist ein Hinweis, kein Beweis.
- Generierte Missbrauchsfälle. Aus der Berechtigungsmatrix und der Fachlogik erzeugt die KI konkrete Testfälle — fremde IDs, fehlende Tokens, Grenzwerte, doppelte Abläufe — die dann gegen das Testsystem ausgeführt werden. Erst das Ergebnis zählt.
- Anwendungen mit eigener KI. Enthält die Software selbst ein Sprachmodell (Chatbot, Assistent, Agent), prüfen wir zusätzlich Prompt Injection, Datenabfluss über Antworten, übermässige Handlungsbefugnisse und den Umgang mit Modellausgaben — orientiert an den OWASP Top 10 für LLM-Anwendungen.
- Datenschutz beim Prüfen. Code und Unterlagen gehen nur an KI-Dienste, deren Bedingungen Ihre Vorgaben erfüllen (kein Training mit Ihren Daten, Verarbeitungsort nach Absprache). Auf Wunsch verzichten wir auf KI-gestützte Analyse vollständig — die Ebenen 1 und 4 tragen das Gutachten auch allein, mit entsprechend mehr AE.
Ebene 4 — Menschliches Review und Bewertung
Die Gutachterin oder der Gutachter liest die kritischen Pfade selbst: Anmeldung, Berechtigungen, Umgang mit personenbezogenen Daten, Schnittstellen nach aussen, Fehler- und Wiederanlaufverhalten. Jede Hypothese aus Ebene 2 und 3 wird reproduziert oder begründet verworfen.
Schweregrade
| Grad | Bedeutung | Erwartete Reaktion |
|---|---|---|
| kritisch | Unmittelbar ausnutzbar, ohne besondere Voraussetzungen; betrifft vertrauliche Daten oder das Gesamtsystem. | Vor Betrieb beheben; im laufenden Betrieb sofort melden. |
| hoch | Ausnutzbar mit überschaubarem Aufwand oder mit erheblicher Auswirkung auf Daten, Verfügbarkeit oder Rechtskonformität. | Vor Betrieb beheben oder als Auflage mit Frist. |
| mittel | Begrenzte Auswirkung oder schwer ausnutzbar; deutliche Schwäche in Wartbarkeit oder Betrieb. | Mit Termin einplanen. |
| niedrig | Abweichung von guter Praxis ohne unmittelbares Risiko. | Bei nächster Gelegenheit. |
| Hinweis | Beobachtung oder Empfehlung, kein Mangel. | Nach Ermessen. |
Sicherheitsbefunde erhalten zusätzlich einen CVSS-Vektor, wenn das sinnvoll ist. Das Gesamturteil folgt den offengelegten Regeln: kritisch offen → nicht nutzbar; hoch offen, aber behebbar → nutzbar mit Auflagen.
Woran wir uns orientieren
Wir erfinden keine eigenen Massstäbe, wo es etablierte gibt. Jeder Prüfpunkt im Prüfkatalog verweist auf seine Grundlage:
- BSI IT-Grundschutz-Kompendium — insbesondere CON.8 Software-Entwicklung, CON.10 Entwicklung von Webanwendungen, APP.3.1 Webanwendungen und Webservices, OPS.1.1.6 Software-Tests und -Freigaben, SYS.1.6 Containerisierung. Den Übergang zu Grundschutz++ bilden wir ab, sobald er verbindlich ist.
- BSI und ANSSI: «AI Coding Assistants» (2024) — die gemeinsame Einschätzung beider Behörden zu Chancen und Risiken von KI-Programmierassistenten
- OWASP — Application Security Verification Standard (ASVS 5.0) als gestufter Prüfkatalog, Top 10:2025 (mit dem neuen Punkt A03 «Software Supply Chain Failures»), Top 10 für LLM-Anwendungen
- ISO/IEC 25010 — Qualitätsmerkmale, insbesondere Wartbarkeit, Zuverlässigkeit, Sicherheit und Übertragbarkeit
- DSGVO und Landesdatenschutzrecht — Datenschutz durch Technikgestaltung (Art. 25), Sicherheit der Verarbeitung (Art. 32), Verzeichnis und Folgenabschätzung (Art. 30, 35)
- BITV 2.0 bzw. Landesverordnungen / EN 301 549 / WCAG 2.1 — Barrierefreiheit, verpflichtend für öffentliche Stellen
- EU-KI-Verordnung (VO 2024/1689) und, wo Software in Verkehr gebracht wird, Cyber Resilience Act (VO 2024/2847)