Scout Browser goes under peer review, analyse, revisione

Der Scout Browser wird einem Peer-Review unterzogen

Es reicht nicht aus zu sagen, dass man gut ist. Der Moment der Wahrheit kommt, wenn ein externer Experte oder Peer sich genau anschaut, was man tut – und einem dann „Daumen hoch“ signalisiert.

In der akademischen Welt nennt man so etwas ein Peer-Review und es ist für jede wissenschaftliche Arbeit unbedingt erforderlich. Bei Software-Entwicklern nennt man den Vorgang externe Code-Prüfung. Und genau solch einer haben wir unseren Scout Browser unterzogen. Wir haben genug Änderungen angesammelt (zusätzlich zum Chromium-Code), um eine externe Code-Prüfung zu rechtfertigen.

Und bevor wir näher auf dieses Ereignis eingehen, ist dies eine gute Gelegenheit, Ihnen unsere internen Best Practices und Überprüfungsprozesse vorzustellen, die wir bei Avira befolgen, wenn es um die Programmierung geht. Schließlich kann eine externe Prüfung nicht besser sein als die vorhergehende Codierung, die er (oder sie) sich ansieht:

Sichere Programmierungsprinzipien

Bei der Programmierung halten wir uns an diese Liste von „Do’s“ und „Don’ts“. Es handelt sich um ein internes Dokument, das typische Bedingungen abdeckt. Es gibt allgemeine (sprintf vs. snprintf) und projektspezifische Richtlinien.

Für das Scout-Team lautet eine wichtige Richtlinie: „Nur nicht die Sandbox kaputt machen.“ Für Chrom(ium)-Nutzer ist die Sandbox eine Wand um den Browser herum, die ihn vom Betriebssystem trennt. Selbst wenn der Browser gehackt und dadurch bösartig wird, kann er dem System keinen Schaden zufügen. Wir stellen sicher, dass wir daran nichts verändern.

Code-Prüfung während der Programmierung

Wir haben unsere Tools so konfiguriert, dass „nur Code, der von zwei weiteren Entwicklern geprüft und akzeptiert wurde, ins Repository aufgenommen wird.“ Dies ist für uns als Entwickler ein wichtiges Sicherheitsnetz. Selbst wenn wir mal einen schlechten Tag hatten, gibt es noch zwei weitere Teammitglieder, die unseren Code prüfen und sicherstellen, dass wir die effizientesten und sichersten Wege finden, um unsere Ziele zu erreichen. Als Entwickler können wir so viel besser schlafen – und auch die Endnutzer sind geschützter, auch wenn sie es vielleicht nicht bemerken.

Ehrlich gesagt: Manchmal ist es etwas schwierig, die Kritik anzunehmen, aber wenn wir es tun, lernen wir dazu und können uns verbessern.

Externe Prüfungen

Wir arbeiten mit mehreren externen Unternehmen zusammen, die sich auf Code-Prüfungen spezialisiert haben. Sie sind Experten darin, Bugs und Schwachstellen in Codes zu finden. Immer wenn wir genügend neue Codes angesammelt haben, ziehen wir per Zufallsprinzip eine ihrer Visitenkarten aus unserem Lostopf und laden sie ein, eine Prüfung bei uns vor Ort vorzunehmen. Letztes Mal haben wir X41 gezogen. Sie haben dann eine Woche mit unserem Scout-Team verbracht, unseren Code geprüft und knifflige Fragen gestellt. Am Ende dieser Prüfung haben sie ein Dutzend Bugs (klein bis mittelgroß) gefunden, die wir beheben mussten. Es war eine sehr lehrreiche und lustige Woche für das Scout-Entwicklerteam.

Fuzzing

Fuzzing ist eine Technologie, bei der man Oberflächen (Netzwerk, Dateien, Nutzer-Input) mit unerwarteten Daten bombardiert und dann abwartet, was passiert – ein Software-Absturz oder seltsames Verhalten. Dies kann durch leicht fehlerhafte Dateien, kaputte Netzwerkpakete und vielem mehr entstehen. Tausende dieser fehlerhaften Dateien können pro Sekunde getestet werden – und so kommen wir einer vollautomatischen Bug-Erkennung immer näher. Dies führen wir selbst durch und das externe Unternehmen, das wir engagiert haben, hat viel Erfahrung mit dem Fuzzing von Browsern.

Der Chromium-Quellcode selbst wurde bereits einem sehr guten Fuzzing unterzogen (Danke, Google!). Aber die Technologie, die wir zum Scout-Browser hinzugefügt haben, noch nicht. Also müssen wir das selbst tun.

Eine letzte Sache: BugBounties

Avira führt für viele seiner Produkte BugBounties durch. Dabei handelt es sich um lustige Veranstaltungen für kreative Technologie-Experten, bei denen sie Fehler (bugs) in Produkten aufstöbern können und dafür bezahlt werden. Aber für Scout machen wir das (noch) nicht. Beim Großteil unseres Codes handelt es sich um Chromium-Code und Google hat seine eigene BugBounty für diese Fehler. Jetzt gerade eine BugBounty zu veranstalten, wäre eine ziemlich langweilige Sache und für die Spieler nicht sehr lukrativ. Aber wir melden uns wieder, wenn es mehr Bugs bei uns zu finden gibt.

Dieser Artikel ist auch verfügbar in: EnglischFranzösischItalienisch

I use science to protect people. My name is Thorsten Sick and I do research projects at Avira. My last project was the ITES project where I experimented with Sandboxes, Sensors and Virtual Machines. Currently I am one of the developers of the new Avira Browser