Einen VPN-Auditbericht lesen: der Umfang schlägt das Siegel

Siegel sind billig anzuzeigen und teuer zu deuten. Ein veröffentlichter Auditbericht ist ein begrenztes Stück Ingenieursarbeit: Ein benannter Prüfer untersuchte benannte Komponenten in einer benannten Version mit einer angegebenen Methode und einem Zeitbudget. Diese vier Fakten bestimmen, was die Schlussfolgerung stützen kann, und sie stehen meist auf den ersten Seiten statt in der Marketingzusammenfassung. Sie zu lesen dauert zehn Minuten und verhindert den verbreiteten Fehler, einen Befund zu einer Client-App auf einen ganzen Dienst auszudehnen.

Was der Abschnitt zum Umfang tatsächlich begrenzt

Eine Umfangserklärung ist ein Zaun, und alles außerhalb bleibt unbeantwortet statt bestanden. Berichte listen die geprüften Komponenten, den Commit-Bereich oder die Build-Kennung, die verwendete Umgebung und das erlaubte Interaktionsmodell. Ein Desktop-Client, eine mobile App, der Servercode, das Konto-Backend und die Produktionsinfrastruktur sind fünf verschiedene Gegenstände, und ein Auftrag kann jede Teilmenge davon abdecken.

Ausschlüsse zählen so viel wie Einschlüsse, weil sie absichtlich genannt und nachlässig gelesen werden. Ein Kontosystem, das als außerhalb des Umfangs beschrieben wird, gilt nicht implizit als sicher, und eine mobile App, die aus einem Auftrag herausbleibt, ist schlicht ungeprüft. Markieren Sie jede ungeprüfte Komponente in Ihren eigenen Notizen als unbekannt und widerstehen Sie dem Drang, die Lücke mit Reputation zu füllen.

Zwei Arten von Tests beantworten verschiedene Fragen

Quelltextprüfung und Laufzeittests suchen nach unterschiedlichen Fehlern. Ein Prüfer, der Code liest, kann eine Schlüsselableitung nachvollziehen, eine fehlende Längenprüfung erkennen und über einen ganzen Parser nachdenken, ohne ihn auszuführen. Ein Tester gegen einen laufenden Dienst entdeckt, was der ausgelieferte Build tatsächlich tut: ein Zertifikat, das die App ablehnt, ein weiterhin aktives Fallback-Protokoll, einen Endpunkt, der über eine von niemandem geprüfte Konfiguration einen Versionsbanner preisgibt.

Keines ersetzt das andere, und der Bericht nennt meist, welches durchgeführt wurde. Wenn eine Zusammenfassung „geprüft“ ohne diese Unterscheidung sagt, liegt die Unklarheit in der Zusammenfassung, nicht im Bericht.

Zugriffsgrenzen leisten dasselbe. Ein Blackbox-Auftrag kann die Serverkonfiguration nicht sehen, und eine Architekturprüfung, die nie einen ausgelieferten Endpunkt berührt, kann nicht bemerken, dass die Produktion vom Diagramm abweicht. Beides ist legitim; ihre Ergebnisse zu vermengen nicht.

Wie aus einem Befund eine korrigierte Version wird

Die wertvolle Hälfte eines Berichts ist die Behebungstabelle: jeder Befund, seine Schwere nach der Methode des Prüfers, die Antwort des Betreibers und das Ergebnis des Nachtests. Schweregrade stammen aus einer gewählten Methodik und nicht aus der Natur, also vergleichen Sie Schweregrade innerhalb eines Berichts statt zwischen zwei mit unterschiedlichen Skalen.

Verbinden Sie dann die Korrektur mit veröffentlichter Software. Ein korrigierter Befund ist für einen Nutzer erst relevant, wenn die Version mit der Korrektur die installierte ist, weshalb Build-Kennung des Berichts und Änderungsprotokoll einer Veröffentlichung zusammen gelesen werden müssen. Ein Nachtest, der die Korrektur abdeckte, schließt den Kreis; eine ungetestete Korrektur ist eine Behauptung. Ebenso eine Korrektur, die nur in einem Zweig ausgeliefert wurde, den keine stabile Veröffentlichung je zusammengeführt hat.

Was das Siegel Ihnen nicht sagen kann

Das Fehlen von Befunden ist kein Beweis für das Fehlen von Mängeln. Ein kurzer Auftrag mit festem Budget wird Dinge übersehen, und die ehrliche Lesart eines sauberen Berichts ist, dass der Prüfer die gesuchten Problemklassen in der verfügbaren Zeit nicht gefunden hat.

Das Siegel kann auch nicht für Eigenschaften außerhalb seines Umfangs sprechen. Aussagen über Protokollierungspraxis, Gerichtsbarkeit oder Aufbewahrung stehen in einem Richtliniendokument, nicht in einem Audit einer Client-Anwendung, und keine Reputation des Prüfers überträgt sich über diese Grenze.

Belege festhalten, die Sie verteidigen können

Schreiben Sie den Beleg in drei Teilen: die Komponente, die Version und die verifizierte Korrektur. Ein veröffentlichter Auftrag wie das von Mozilla beauftragte VPN-Audit stützt genau die Aussagen, die sein Umfang beschreibt, und nichts darüber hinaus, was bei präziser Angabe noch recht viel wert ist. Derselbe Bericht, für etwas zitiert, das er nie untersucht hat, ist weniger wert als kein Beleg, weil er ein Vertrauen einlädt, das niemand verdient hat.

Fällt eine behauptete Eigenschaft außerhalb jedes verfügbaren Berichts, lassen Sie sie im Dokument ungeklärt. Eine ungeklärte Zeile lädt zu einer Rückfrage ein; ein Siegel nicht. Die einzige Ausnahme ist eine Eigenschaft, die ein anderes, ebenso konkretes Dokument klärt, und dann ändert sich der Beleg statt der Behauptung.

Zwei weitere Gewohnheiten machen das Lesen haltbar: Notieren Sie das Berichtsdatum gegen die Veröffentlichung, die Sie tatsächlich einsetzen, und halten Sie die Differenz zwischen dem Getesteten und dem Ausgelieferten fest. Beides macht aus einer Vertrauensentscheidung etwas, das eine Kollegin prüfen kann.