Code-Audit-Checkliste: Was Sie prüfen und wie Sie Befunde festhalten

Ein Code-Audit prüft eine ganze Codebasis anhand einer festen Liste: Sicherheit, Architektur, Abhängigkeiten, Tests, Dokumentation, Leistung und Betrieb. Ein Code-Review prüft eine einzelne Änderung, bevor sie übernommen wird. Diese Seite liefert Ihnen die Checkliste für das Audit, eine kürzere für Reviews, die Schweizer Datenschutzprüfungen, die oft vergessen gehen, und ein Format, um Ihre Befunde festzuhalten.

Geschrieben ist sie für Gründer:innen, CTOs und Inhaber:innen, die Code übernehmen, ein Produkt kaufen, Kapital aufnehmen oder einen Launch freigeben wollen. Sie müssen keine Entwickler:in sein, um ihr zu folgen. Sie müssen aber die richtigen Fragen stellen und eine klare Antwort erkennen können.

Kurz zusammengefasst

• Ein Audit prüft die gesamte Codebasis, ein Review nur einen Diff. OWASP trennt die beiden, und Ihre Checkliste sollte das ebenfalls tun.
• Arbeiten Sie nach Priorität: Läuft es von null weg, danach Sicherheit, Architektur, Abhängigkeiten, Tests, Dokumentation und Leistung.
• Überlassen Sie Formatierung und bekannte Schwachstellen den Werkzeugen. Menschliche Zeit gehört der Geschäftslogik, den Berechtigungen und den Datenflüssen, die Scanner übersehen.
• In der Schweiz kommen die Datenschutzprüfungen dazu: eine Datenschutz-Folgenabschätzung bei hohem Risiko, die Dokumentation von Verletzungen und eine zutreffende Datenschutzerklärung.
• Jeder Befund braucht Ort, Auswirkung, Nachweis, Schweregrad und eine Behebung. Danach prüfen Sie die Behebungen nach.

Code-Audit oder Code-Review: Was brauchen Sie?

Viele suchen nach «Code Review Checkliste» und «Code Audit Checkliste», als wäre es dasselbe. Das ist es nicht, und wer beides vermischt, verliert Zeit.

Ein Code-Review betrachtet eine vorgeschlagene Änderung, meist einen Pull Request. Er findet mehrmals pro Woche statt, dauert Minuten bis eine Stunde, und sein Ziel ist es, eine schlechte Änderung aus der Codebasis fernzuhalten. OWASP nennt das einen Diff-basierten Review.

Ein Code-Audit betrachtet die gesamte Codebasis zu einem bestimmten Zeitpunkt. Es findet einmal vor einem Launch, einer Finanzierungsrunde, einer Übernahme oder einer Übergabe statt, oder jährlich bei Systemen, auf die es ankommt. OWASP beschreibt die Basisprüfung einer ganzen Codebasis als eigene Tätigkeit, getrennt von der Prüfung einzelner Änderungen. Sie dauert Tage oder Wochen und endet mit einem schriftlichen Bericht und einem Entscheid.

Die praktische Regel: Reviews verhindern, dass die Qualität abrutscht, Audits zeigen Ihnen, wo Sie tatsächlich stehen. Wenn Ihr Code noch nie geprüft wurde, fangen Sie dort an. Wenn Sie jährlich auditieren, dazwischen aber ungeprüften Code übernehmen, beheben Sie zuerst das.

Vor dem Start: Umfang und Vorbereitung

Die meisten schlechten Audits scheitern, bevor jemand eine Zeile gelesen hat. Klären Sie zuerst diese Punkte.

1. Definieren Sie die Frage. «Können wir das sicher launchen?», «Kann ein neues Team das warten?» und «Was ist es wert?» führen zu unterschiedlichen Audits. Schreiben Sie die Frage an den Anfang des Berichts.
2. Legen Sie den Umfang fest. Listen Sie auf, welche Repositories, Dienste, Infrastrukturdefinitionen und Integrationen von Dritten dazugehören und welche nicht. Ein Swiss university course on code review betont, dass die zu prüfende Menge überschaubar bleiben muss. Für ein Audit gilt dasselbe: Ein enger Umfang, sauber geprüft, schlägt einen breiten Umfang, oberflächlich geprüft.
3. Bereiten Sie das Material vor. Der Code sollte formatiert und so weit dokumentiert sein, dass man ihn lesen kann, und die Stellen für eine vertiefte Prüfung sollten markiert sein. Bei einem Audit sind das die heiklen Teile: Login, Zahlungen, Datei-Uploads, Administrationswerkzeuge und alles, was Personendaten berührt.
4. Sammeln Sie den Kontext. Die Vorgaben von OWASP verlangen, dass Prüfende die geschäftlichen Anforderungen, das Bedrohungsmodell und die kritischen Werte kennen, bevor sie den Code beurteilen. Verlangen Sie Architekturdiagramme, eine Liste der Umgebungen und eine Liste, wer worauf Zugriff hat.
5. Einigen Sie sich, wer das Ergebnis liest. Eine Gründerin braucht ein einseitiges Urteil. Eine Entwicklerin braucht Dateipfade. Planen Sie beides ein.

Die Code-Audit-Checkliste

Die Reihenfolge unten ist bewusst gewählt. Wenn der erste Punkt durchfällt, zählt der Rest weniger.

1. Läuft es aus einem frischen Checkout?

Klonen Sie das Repository auf einem Rechner, der es noch nie gesehen hat, und folgen Sie der README. Zählen Sie, wie viele undokumentierte Schritte Sie brauchen.

• Lässt sich das Projekt allein anhand der Dokumentation bauen und starten?
• Sind die Umgebungsvariablen aufgeführt, mit unbedenklichen Beispielwerten?
• Lassen sich die Tests mit einem einzigen Befehl ausführen?
• Ist der Deployment-Prozess aufgeschrieben, oder steckt er im Kopf einer einzelnen Person?

Wenn nur eine Person das Produkt bauen und ausliefern kann, ist das Ihr erster Befund, ganz gleich, wie der Code aussieht.

2. Geheimnisse und Zugriffe

• Durchsuchen Sie den aktuellen Code und die Commit-Historie nach API-Schlüsseln, Passwörtern, Tokens und privaten Schlüsseln. Ein letzten Monat gelöschter Schlüssel steht noch immer in der Historie.
• Stellen Sie sicher, dass Geheimnisse aus einem Secret Store oder aus der Umgebungskonfiguration kommen und nicht aus Dateien im Repository.
• Prüfen Sie, wer Zugriff auf Repository, Cloud, Domain und DNS hat. Ehemalige Auftragnehmer:innen gehören nicht dazu.
• Wechseln Sie alles aus, was je offengelegen hat. Es aus dem Code zu entfernen, genügt nicht.

3. Anmeldung und Berechtigungen

Das sind zwei verschiedene Prüfungen, und bei der zweiten helfen Werkzeuge am wenigsten.

• Anmeldung: Wie werden Passwörter gespeichert, wann laufen Sitzungen ab, gibt es eine Mehrfaktor-Anmeldung, wie funktioniert das Zurücksetzen des Passworts?
• Berechtigungen: Was passiert, wenn eine angemeldete Person durch Ändern einer ID in der URL den Datensatz einer anderen Person abruft? Findet die Berechtigungsprüfung für jeden Endpunkt auf dem Server statt, auch für Administrations- und interne Endpunkte?
• Sind Session-Cookies als secure markiert und werden Sitzungen beim Abmelden ungültig?

Die Vorgaben von OWASP nennen Anmeldung, Berechtigungen, Eingabevalidierung, Kryptografie, Fehlerbehandlung, Konfiguration und Deployment als Bereiche, die eine Sicherheitsprüfung abdecken muss.

4. Eingaben, Ausgaben und Umgang mit Daten

• Sind Datenbankabfragen parametrisiert, sodass Benutzereingaben nie Teil eines Abfragestrings werden?
• Wird die Ausgabe vor der Darstellung kodiert, um Cross-Site-Scripting zu verhindern?
• Sind Datei-Uploads nach Typ und Grösse beschränkt und ausserhalb des Web-Root abgelegt?
• Werden sensible Daten bei der Übertragung und im Ruhezustand verschlüsselt, mit üblichen Bibliotheken statt selbstgebauter Kryptografie?
• Verraten Fehlermeldungen und Logs keine Stack Traces, Tokens oder Personendaten?

Eine kurze Sicherheitsliste wie diese, mit Geheimnissen, parametrisierten Abfragen, Ausgabekodierung und Sitzungsverwaltung, ist ein vernünftiges Minimum. Verankern Sie tiefere Arbeit in einem Standard wie OWASP ASVS, wie es die OWASP DevSecOps guideline vorschlägt.

5. Abhängigkeiten und Lieferkette

• Gibt es eine Lockfile, und ist sie eingecheckt?
• Führen Sie den Audit-Befehl des Paketmanagers und eine Software Composition Analysis aus. Wie viele bekannte Schwachstellen gibt es, und wie viele davon stecken in Code, der produktiv tatsächlich läuft?
• Sind Pakete aufgegeben, seit Jahren ungepflegt oder auf eine sehr alte Hauptversion festgenagelt?
• Existieren alle Abhängigkeiten, und stammen sie aus der erwarteten Registry? Das ist besonders wichtig bei Code, der mit KI-Assistenten entstanden ist, denn diese schlagen mitunter falsche Paketnamen vor.
• Sind die Lizenzen damit vereinbar, wie Sie das Produkt verkaufen?

6. Architektur und Grenzen

• Können Sie das System auf einer Seite aufzeichnen: Komponenten, Datenspeicher, Dienste von Dritten und die Linien, an denen Daten Vertrauensgrenzen überschreiten?
• Liegt die Geschäftslogik an einem Ort, oder ist sie über Frontend, Backend und Skripte verteilt?
• Gibt es einen einzelnen Ausfallpunkt, etwa einen Server, eine Datenbank ohne Backups oder eine einzelne Person?
• Sind die Module so weit getrennt, dass Sie eines ersetzen könnten (den Zahlungsanbieter, das CRM), ohne alles neu zu schreiben?
• Passt das Design zu den Anforderungen, oder hat es sich zu etwas entwickelt, das das ursprüngliche Team nicht wiedererkennen würde?

In diesem Abschnitt verdient eine erfahrene Prüferin ihr Honorar. Ein Linter sagt Ihnen nicht, dass Ihr Datenmodell die nächsten fünf Kund:innen nicht überlebt.

7. Tests

• Deckt die Testsuite neues Verhalten und Randfälle ab, nicht nur den Idealfall?
• Prüfen die Tests Ergebnisse statt Umsetzungsdetails, sodass ein Refactoring sie nicht zerstört?
• Decken die Tests die Fehlerbehandlung ab?
• Gibt es eine Continuous-Integration-Pipeline, die sie bei jeder Änderung ausführt, und hält das Team tatsächlich an, wenn sie fehlschlägt?
• Sind die heikelsten Abläufe (Checkout, Berechtigungen, Datenexport) durchgängig getestet?

Abdeckungswerte in Prozent sind ein schwaches Signal. Ein System mit 80 Prozent Abdeckung und ohne Tests für Berechtigungen ist unsicherer als eines mit 50 Prozent, das die richtigen Dinge prüft.

8. Codequalität und Wartbarkeit

• Versteht eine neue Entwicklerin eine typische Datei in wenigen Minuten?
• Gibt es riesige Dateien oder Funktionen, die niemand anzufassen wagt?
• Gibt es toten Code, auskommentierte Blöcke oder doppelte Logik?
• Ist die Formatierung einheitlich und wird sie von einem Werkzeug durchgesetzt, nicht von Meinungen?

Halten Sie diesen Abschnitt im Verhältnis. Stil ist der unwichtigste Befund in einem Audit, und wer ihn einer Lücke bei den Berechtigungen gleichsetzt, verdeckt die echten Risiken.

9. Leistung und Skalierbarkeit

• Wo sind die langsamen Datenbankabfragen? Achten Sie auf Abfragen in Schleifen und fehlende Indizes.
• Wird etwas zwischengespeichert, das zwischengespeichert gehört, und etwas, das es nicht sollte?
• Was passiert bei der zehnfachen heutigen Last? Hat es schon jemand ausprobiert?
• Werden Hintergrundjobs sicher wiederholt, oder kann ein Fehler eine E-Mail zweimal versenden oder eine Karte zweimal belasten?

10. Konfiguration, Deployment und Überwachung

• Sind Entwicklung, Staging und Produktion getrennt, mit unterschiedlichen Zugangsdaten?
• Ist die Infrastruktur als Code definiert, sodass ein verlorener Server wieder aufgebaut werden kann?
• Werden Backups erstellt, und wurde eine Wiederherstellung je getestet?
• Gibt es Überwachung, Alarmierung und Aufbewahrung der Logs, und wird jemand geweckt, wenn etwas ausfällt?
• Gibt es einen Plan zur Sicherheitsüberwachung, um verdächtiges Verhalten zu erkennen?

11. Dokumentation und Übergabe

• Gibt es eine README, eine Architekturübersicht und eine Liste der Integrationen?
• Sind Entscheidungen irgendwo festgehalten, und sei es nur kurz?
• Könnte eine kompetente fremde Person in zwei Wochen übernehmen? Wenn nicht, sind Sie von denen abhängig, die den Code geschrieben haben.

Schweizer Prüfpunkte: Datenschutz und Branchenregeln

Allgemeine Checklisten stammen aus den USA und der EU und erwähnen die Schweiz selten. Wenn Ihre Software Personendaten von Menschen in der Schweiz bearbeitet, kommen diese Punkte dazu.

Datenschutz-Folgenabschätzung (DSFA). Nach dem Schweizer Datenschutzgesetz (DSG) muss eine verantwortliche Person eine DSFA durchführen, wenn die geplante Bearbeitung voraussichtlich ein hohes Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Personen mit sich bringt. Das factsheet on the DPIA des Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten hält fest, dass sie die Bearbeitung beschreiben, die Risiken bewerten und die Schutzmassnahmen festlegen soll. Es bezeichnet die DSFA zudem als proaktives Arbeitsinstrument für digitale Projekte, nicht als Papierübung. Fragen Sie im Audit, ob für Funktionen wie Profiling, Gesundheitsdaten oder umfangreiches Tracking eine DSFA vorliegt und ob der Code dem entspricht, was darin steht.

Dokumentation von Datenschutzverletzungen. Die Data Protection Ordinance verlangt von Verantwortlichen, Verletzungen zu dokumentieren; eine Meldung an den Beauftragten muss die Art der Verletzung, ihre Folgen und die getroffenen oder geplanten Massnahmen nennen. Prüfen Sie, ob die Protokollierung gut genug ist, um den Hergang zu rekonstruieren. Wenn Ihre Logs nicht sagen, auf welche Datensätze zugegriffen wurde, können Sie diese Meldung nicht schreiben.

Datenschutzerklärung gegenüber der Realität. Die Seite des Beauftragten zu privacy statements on the internet rät Verantwortlichen, zuerst ihre Datenbearbeitung zu analysieren und dann zu beantworten, was erhoben wird, warum, wo und wie lange es gespeichert wird und ob es ins Ausland geht. Verfolgen Sie im Audit jedes Analyse-Skript, jedes Formular und jedes SDK von Dritten und vergleichen Sie es mit der veröffentlichten Erklärung. Cloud-Regionen und Übermittlungen ins Ausland sind die üblichen Lücken.

Branchenregeln. Die Schweiz hat einen technologieneutralen Rechtsrahmen statt einer einzigen allgemeingültigen Zertifizierung für sichere Entwicklung, wie diese Swiss law firm overview of cybersecurity beschreibt. Die Checkliste muss deshalb zum Produkt und zu den Daten passen. Dieselbe Übersicht hält fest, dass eHealth Suisse von medizinischer Software erwartet, die Sicherheit bereits im Design festzulegen, eine Risikoanalyse durchzuführen und Verifizierung, Validierung, Aktualisierungen und den Schutz sensibler Daten zu dokumentieren. Kund:innen aus Finanzwesen, Gesundheitswesen und öffentlicher Hand ergänzen meist vertragliche Anforderungen, verlangen Sie diese also vor dem Start des Audits.

Wenn Ihre Website öffentlich erreichbar ist und Sie eine zweite Meinung zu ihrer Angriffsfläche möchten, ergänzen ein paar website security checks die Prüfung auf Code-Ebene.

Automatisierung gegenüber menschlichem Urteil

Ein gutes Audit nutzt beides und weiss, was wo gehört.

Werkzeuge sind gut in wiederholbarer Arbeit: Formatierung, statische Analyse, Abhängigkeiten mit bekannten Schwachstellen, Muster von Geheimnissen. Sourcegraph’s review guidance macht denselben Punkt für Reviews: Automatisieren Sie, was sich wiederholt, damit sich Menschen auf Design und Logik konzentrieren können.

Für den Rest braucht es Menschen. OWASP hält fest, dass automatisierte SAST- und DAST-Werkzeuge die menschliche Prüfung ergänzen und nicht ersetzen, weil Geschäftslogik, Kontext der Datenflüsse und komplexe Sicherheitsmassnahmen jemanden brauchen, der das Produkt versteht. Ein Scanner bemerkt nicht, dass sich ein Rabattcode unbegrenzt einlösen lässt oder dass ein Rechnungs-Endpunkt die Rechnung einer anderen Kundin zurückgibt.

Nutzen Sie zuerst Werkzeuge, um eine Karte zu erhalten, und lesen Sie den Code dort, wo die Karte sagt, dass es darauf ankommt.

Die kürzere Checkliste für Code-Reviews

Für alltägliche Pull Requests sollte die Liste auf einen Bildschirm passen. Lange Checklisten werden ignoriert.

Prüfpunkt	Frage
Anforderungen	Tut die Änderung, was das Ticket verlangt, und sonst nichts?
Korrektheit	Sind Randfälle und Fehlerpfade behandelt?
Lesbarkeit	Würde jemand Neues es ohne die Autorin verstehen?
Tests	Sind neues Verhalten und Randfälle abgedeckt, mit Prüfungen auf Ergebnisse?
Sicherheit	Gibt es neue Eingaben, Berechtigungen, Geheimnisse oder Abfragen, die genauer anzusehen sind?
Architektur	Passt es zum bestehenden Design, und was wird sonst noch beeinflusst?
Betrieb	Braucht es eine Konfigurationsänderung, eine Migration oder Überwachung?

Zwei Gewohnheiten machen das wirksam, beide beschrieben im Sourcegraph’s review guidance. Behandeln Sie blockierende Probleme zuerst und kennzeichnen Sie Stilkommentare als Kleinigkeiten, damit die Autorin weiss, was wirklich geändert werden muss. Das Kursmaterial der ETH ergänzt, dass Autor:innen und Prüfende je eine eigene Checkliste haben sollten, dass die Diskussion bei technischen Mängeln bleiben soll und dass das Team Mängel festhalten und nachverfolgen soll, bis ihre Behebung bestätigt ist.

Ein Vorbehalt: Behandeln Sie jede Checkliste als Gedächtnisstütze, nicht als Ersatz für Urteilsvermögen, und aktualisieren Sie sie, wenn das Team etwas gelernt hat. Ist ein Fehler durchgerutscht, ergänzen Sie die Frage, die ihn entdeckt hätte.

So halten Sie die Befunde fest

Ein Audit ist nur so viel wert, wie der Bericht Ihnen erlaubt zu tun. Verwenden Sie für jeden Befund dieselbe Struktur, entsprechend den Vorgaben von OWASP zur Berichterstattung:

1. Komponente und Ort: der Dienst, die Datei und die Zeile.
2. Problem: was falsch ist, in ein bis zwei Sätzen.
3. Auswirkung: was passieren könnte, in geschäftlichen Begriffen.
4. Nachweis: Schritte zur Reproduktion, ein Request, ein Screenshot oder ein Code-Auszug.
5. Schweregrad: kritisch, hoch, mittel oder tief, mit einer festgelegten Regel für jede Stufe.
6. Behebung: was zu ändern ist, konkret genug für eine Schätzung.

Fügen Sie danach eine Zusammenfassung hinzu: das Urteil zu der Frage, die Sie am Anfang gestellt haben, die fünf grössten Risiken und eine grobe Reihenfolge der Arbeiten. Gruppieren Sie die Befunde in «vor dem Launch beheben», «in diesem Quartal beheben» und «akzeptieren und beobachten».

Und schliesslich: Bleiben Sie dran. Halten Sie die Befunde in einem Bericht fest und prüfen Sie danach, ob jeder Mangel behoben wurde, wie es das Material der ETH formuliert. Testen Sie kritische und hohe Punkte selbst nach, statt einem Statusbericht blind zu vertrauen.

Ein durchgespieltes Beispiel: Audit vor der Finanzierungsrunde

Angenommen, Sie sind Gründerin mit einem laufenden Produkt, das zwei Freelancer gebaut haben, und eine Investorin verlangt eine technische Due Diligence. Sie haben eine Woche.

• Tag 1: frischer Checkout, Suche nach Geheimnissen und Liste der Zugriffe. Fällt eines davon durch, beheben Sie es, bevor jemand anderes hinschaut.
• Tag 2: Berechtigungen bei jedem Endpunkt, der Benutzerdaten zurückgibt. Testen Sie mit zwei Konten.
• Tag 3: Prüfung der Abhängigkeiten, Lockfile und Lizenzen.
• Tag 4: Architekturskizze, Test von Backup und Wiederherstellung, Durchgang durch das Deployment.
• Tag 5: Tests, Dokumentation und die Datenschutzfragen: Passt Ihre Datenschutzerklärung zu Ihren Trackern?
• Tag 6 und 7: Bericht schreiben, Befunde in drei Gruppen einteilen und die günstigen kritischen Punkte beheben.

Sie werden nicht alles finden. Sie werden die Dinge finden, die eine Entwicklerin der Investorin in der ersten Stunde findet, und genau das brauchen Sie.

Wann Sie jemanden von aussen beiziehen

Machen Sie den ersten Durchgang selbst, wenn Sie Code lesen können. Holen Sie eine externe Prüferin, wenn Sie nicht unabhängig sind (Sie haben den Code geschrieben oder Sie bezahlen die Leute, die es getan haben), wenn viel auf dem Spiel steht (eine Finanzierungsrunde, eine Übernahme, regulierte Daten) oder wenn im Team niemand im betreffenden Stack genügend Erfahrung hat.

Bei Ampersand führen wir Audits und technische Due Diligence im Rahmen unserer Beratung durch, und die Personen, die das Audit machen, sind dieselben erfahrenen Entwickler:innen, die die gefundenen Punkte beheben würden. Wir sind ein kleines Zürcher Studio, und zu unseren Kunden zählen UBS und die Stadt Lugano. Wenn Sie vor Ihrem Entscheid sehen möchten, wie wir arbeiten: Unser Portfolio zeigt aktuelle Projekte, und die Preisseite listet die möglichen Zusammenarbeitsformen. Unser Guidance-Plan ist mit CHF 799 pro Monat aufgeführt und Run & monitor, unser Plan für laufende Unterstützung, mit CHF 750 pro Monat. Audits und andere Mandate werden einzeln kalkuliert, deshalb zeigt die Seite dafür keinen Preis. Wenn Sie den Ablauf lieber selbst lernen und Audits selbst durchführen möchten, richten wir das als Coaching für Sie ein.

Häufige Fragen

Was ist der Unterschied zwischen einem Code-Audit und einem Code-Review?

Ein Code-Review prüft eine einzelne Änderung, etwa einen Pull Request, bevor sie übernommen wird. Ein Code-Audit untersucht die gesamte Codebasis zu einem bestimmten Zeitpunkt, meist vor einem Launch, einem Verkauf oder einer Übergabe. OWASP behandelt die Prüfung der ganzen Codebasis und die Diff-basierte Prüfung als zwei getrennte Tätigkeiten.

Wie oft sollten wir unseren Code auditieren?

Auditieren Sie vor wichtigen Ereignissen: einem Launch, einer Finanzierungsrunde, einer Übernahme, einem Wechsel des Entwicklungsteams. Bei Systemen mit sensiblen Daten ist ein jährliches Audit ein vernünftiger Rhythmus. Prüfen Sie dazwischen jede Änderung, damit das Audit Abweichungen findet und keinen Berg an Überraschungen.

Können automatisierte Werkzeuge ein manuelles Code-Audit ersetzen?

Nein. Scanner bewältigen Formatierung, bekannte Schwachstellen und gängige Muster gut. Die Vorgaben von OWASP halten fest, dass es für Geschäftslogik, kontextabhängige Berechtigungen und Architektur weiterhin eine menschliche Prüfung braucht, denn das übersehen Werkzeuge in der Regel. Nutzen Sie Werkzeuge, um zu steuern, wo Menschen hinschauen.

Müssen Schweizer Unternehmen ihren Code für den Datenschutz auditieren?

Das DSG verlangt kein Code-Audit als solches. Es verlangt aber eine DSFA, wenn eine Bearbeitung voraussichtlich ein hohes Risiko mit sich bringt, die Dokumentation von Datenschutzverletzungen und eine zutreffende Datenschutzerklärung. Ein Code-Audit ist ein praktischer Weg, um zu prüfen, ob die Software wirklich das tut, was diese Dokumente behaupten.

Quellen

• OWASP
• OWASP DevSecOps guideline
• Swiss university course on code review
• Sourcegraph’s review guidance
• factsheet on the DPIA
• Data Protection Ordinance
• privacy statements on the internet
• Swiss law firm overview of cybersecurity