Setup-Update 26.05.2026: 2 Verbesserungen

Setup-Update 26.05.2026: 2 Verbesserungen

TrapDoor-Audit-Skript und Baseline für Code-Assistenten

Ein LLM-basierter Code-Assistent hatte in Tests immer wieder unauffällige, aber potenziell unsichere Code-Passagen durchgewinkt – besonders bei Abhängigkeiten mit versteckten Rückruf-Funktionen. Ich brauchte eine automatisierte Methode, um solche TrapDoor-Muster zu erkennen, bevor sie in die Pipeline kommen.

Die Lösung ist ein zweistufiges System: Ein Skript durchsucht Code-Änderungen nach verdächtigen Mustern (z. B. dynamische Imports, verschleierte Netzwerkaufrufe, ungewöhnliche Berechtigungsanfragen) und vergleicht sie gegen eine Baseline aus bekannten sicheren Mustern. Die Baseline wird aus historisch freigegebenen Commits generiert und regelmäßig aktualisiert. Falschpositive werden manuell nachtrainiert.

Mitnehmer: Selbst einfache statische Analysen decken 80 % der offensichtlichen Risiken ab – der Rest lässt sich mit einer pflegbaren Baseline abfangen.

Souveränitäts-Check für Discovery-Phasen

In Innovationsworkshops sammeln wir oft Ideen in Markdown-Dateien, aber die Frage nach Datenhoheit und Abhängigkeiten von externen Anbietern wurde bisher erst spät gestellt. Das führte zu Nacharbeit, wenn sich herausstellte, dass eine vielversprechende Lösung auf einem proprietären Service aufsetzt.

Jetzt integriere ich einen standardisierten Check direkt in die Discovery-Dokumentation: Jede Idee wird in einer Tabelle mit den Spalten Datenstandort, Abhängigkeiten und Souveränitätsrisiko (skaliert von 1–5) erfasst. Der Check ist Teil der Vorlage und wird vor der Priorisierung ausgefüllt. So fließt die Bewertung von Anfang an in die Entscheidung ein.

Mitnehmer: Ein minimaler Overhead in der Dokumentation spart später wochenlange Diskussionen über Lock-in-Effekte.