Wie können Entwicklungsteams Compliance-Verstöße bereits im Code-Review erkennen, statt erst im Audit?
das heygrc team
Ein Audit ist ein nachlaufender Indikator: Es prüft, was vor Monaten ausgeliefert wurde, wenn der Verstoß bereits in der Produktion und teuer ist. Der Code-Review ist der vorlaufende Indikator, der letzte Moment, in dem ein Verstoß mit einem Klick verhindert werden kann. Um Compliance hier zu erkennen: Wissen Sie, welche Ihrer Kontrollen tatsächlich im Code verankert sind, machen Sie die Compliance-Frage zu einem festen Bestandteil der Prüfung jedes Diffs, verankern Sie jeden Hinweis im spezifischen Kontrollpunkt und dokumentieren Sie den Prozess, sodass der Review selbst zum Audit-Nachweis wird.
Ordnen Sie Ihre Kontrollen den Code-Oberflächen zu
Die meisten Framework-Kontrollen sind organisatorisch, aber ein konsistenter Anteil lebt im Code: Audit-Logging (ISO 27001 A.8.15, SOC 2 CC7.2), Zugriffskontrolle (CC6.1), Kryptographie (A.8.24), Datenminimierung (GDPR Art. 5(1)(c)) und Speicherbegrenzung (Art. 5(1)(e)), Backups und Abhängigkeitsänderungen. Diese Kontrollen können sich mit jedem Commit verschlechtern, daher sollten Sie sie einmal auflisten und die Liste dort platzieren, wo die Reviewer sie sehen.
Stellen Sie die Compliance-Frage bei jedem Diff
Korrektheit und Stil haben bereits einen Platz im Review, Compliance braucht ebenfalls einen. Das kann zunächst eine Review-Checkliste sein oder ein automatisierter Reviewer, der jeden Pull Request gegen Ihre Frameworks prüft. Automatisierung ist hier entscheidend, weil die Frage jedes Mal gestellt werden muss, um wirksam zu sein: Der eine ungelesene Diff ist der, bei dem der Verstoß ausgeliefert wird. Ein neutraler Status-Check verhindert, dass dies die Merges verlangsamt.
Verankern Sie jeden Hinweis im Kontrollpunkt
Ein Hinweis, der besagt, dass ISO 27001 A.8.15 gefährdet ist, ist diskutierbar, behebbar und später überprüfbar. Ein Hinweis, der nur sagt, man solle vorsichtig mit Logs sein, ist keines davon. Die Verankerung sorgt auch dafür, dass falsche Positivmeldungen tolerierbar bleiben, weil der Entwickler die Behauptung gegen die Kontrolle überprüfen kann, statt zu raten.
Dokumentieren Sie den Prozess
Eine Compliance-Prüfung, die an jeden Pull Request angehängt wird, ist ein Nachweis dafür, dass die Prüfung bei jeder Änderung durchgeführt wurde – genau die Art von pro-Änderungs-Nachweis, den ein Auditor stichprobenartig überprüft. Das bedeutet auch, dass das Audit nicht mehr der Zeitpunkt der Entdeckung ist, weil die Entdeckung bereits im Review stattgefunden hat.
track("report.exported", {- email: user.email,+ userId: user.id, reportId: report.id,})Das Event behält seinen analytischen Wert mit einer internen ID anstelle einer E-Mail-Adresse. Wird dies im Review erkannt, ist es eine einzeilige Korrektur. Wird es erst im Audit entdeckt, sind es Monate von exportierten Events, die nachgebessert werden müssen.
Verwandt