Die statische Analyse ist sehr gut darin, eine spezifische Frage zu beantworten: Ist dieser Code falsch? Sie findet Nullzeiger-Dereferenzierungen, Injections, unsichere Deserialisierungen, bekannte schlechte Muster. Was sie nicht beantworten kann, ist eine völlig andere Frage: Verletzt diese Änderung eine Pflicht, die in einer Vorschrift verankert ist?
Zwei verschiedene Fragen
Ein Linter analysiert den Code vor sich: Typen, Kontrollfluss, Taint, bekannte Schwachstellen-Signaturen. Er ist von Natur aus framework-blind, weil die Regeln, die er durchsetzt, universell sind – dieselben in jedem Repository der Welt.
Compliance ist das Gegenteil. Ob eine Änderung ein Problem darstellt, hängt von Fakten ab, die der Code nicht enthält: welche Frameworks Ihr Unternehmen erfüllen muss, was in Ihrem Bereich als personenbezogene Daten gilt, wie lange Sie diese speichern dürfen, wohin sie fließen dürfen. Derselbe Diff kann in einem Unternehmen vollständig konform sein und in einem anderen einen Befund darstellen.
Die Änderung, die korrekt und nicht konform zugleich ist
Füge eine Log-Zeile hinzu, die den vollständigen Anforderungsbody aufzeichnet, um einen Checkout-Flow zu debuggen. Der Code ist korrekt. Er kompiliert, er läuft, kein Linter beanstandet ihn, die Tests bestehen. Gleichzeitig schreibt er eine Kunden-E-Mail und Adresse in Ihre Logs, was mehr personenbezogene Daten sind, als für den Zweck nötig, und das fällt unter GDPR Art. 5(1)(c).
Kein Tool, das die Code-Qualität bewertet, wird dies markieren, weil nichts am Code von schlechter Qualität ist. Das Problem ist nur sichtbar, wenn man die Änderung gegen die Datenschutzpflichten prüft, die das Unternehmen tatsächlich hat. Das ist die framework-bewusste Ebene, die Linter nicht haben.
Die fehlende Ebene, kein Ersatz
Dies ist kein Argument gegen Linter oder Scanner. Behalten Sie sie; sie finden Dinge, die heygrc niemals finden wird. Es ist ein Argument dafür, dass es eine ganze Kategorie von Risiken gibt, die über ihnen liegt – Framework-Verpflichtungen –, die keine noch so gründliche Code-Qualitätsanalyse erkennen kann.
heygrc ist diese Ebene. Es prüft die Änderung gegen Ihre Frameworks und verweist auf die spezifische Kontrolle, sodass die framework-blinde Lücke in Ihrer bestehenden Tool-Landschaft eine zusätzliche Überprüfung erhält.