Een VPN-auditrapport lezen: scope weegt zwaarder dan de badge

Badges zijn goedkoop om te tonen en duur om te interpreteren. Een gepubliceerd auditrapport is een afgebakend stuk engineeringwerk: een genoemde beoordelaar onderzocht genoemde componenten, op een genoemde versie, met een vermelde methode en een tijdsbudget. Die vier feiten bepalen wat de conclusie kan ondersteunen, en ze staan meestal op de eerste pagina's en niet in de marketingsamenvatting. Ze lezen kost tien minuten en voorkomt de gangbare fout om een bevinding over een client-app uit te breiden naar een hele dienst.

Wat de scopesectie werkelijk afbakent

Een scope-verklaring is een hek, en alles daarbuiten is onbeantwoord in plaats van geslaagd. Rapporten noemen de onderzochte componenten, het commit-bereik of de build-identificatie, de gebruikte omgeving en het toegestane interactiemodel. Een desktopclient, een mobiele app, de servercode, de backend van het account en de productie-infrastructuur zijn vijf verschillende onderwerpen, en een opdracht kan elke deelverzameling daarvan dekken.

Uitsluitingen tellen even zwaar als insluitingen, omdat ze bewust worden vermeld en achteloos worden gelezen. Een accountsysteem dat als buiten scope wordt beschreven, is niet impliciet veilig, en een mobiele app die buiten een opdracht blijft, is simpelweg niet onderzocht. Markeer elke ongeteste component in je eigen notities als onbekend, en weersta de neiging het gat met reputatie te vullen.

Twee soorten tests beantwoorden verschillende vragen

Broncodeonderzoek en tests tijdens gebruik zoeken naar verschillende fouten. Een reviewer die code leest kan een sleutelafleiding volgen, een ontbrekende lengtecontrole opmerken en over een hele parser redeneren zonder die uit te voeren. Een tester tegen een draaiende dienst ontdekt wat de uitgerolde build werkelijk doet: een certificaat dat de app weigert, een terugvalprotocol dat nog steeds is ingeschakeld, een eindpunt dat een versiebanner lekt via een configuratie die niemand heeft nagelopen.

Geen van beide vervangt de ander, en het rapport noemt meestal welke is uitgevoerd. Wanneer een samenvatting «geaudit» zegt zonder dat onderscheid, ligt de dubbelzinnigheid in de samenvatting, niet in het rapport.

Toegangsbeperkingen doen hetzelfde werk. Een blackbox-opdracht kan de serverconfiguratie niet zien, en een architectuuronderzoek dat nooit een uitgerold eindpunt aanraakt kan niet opmerken dat de productie afwijkt van het diagram. Beide zijn legitiem; hun resultaten vermengen niet.

Hoe een bevinding een gerepareerde versie wordt

De waardevolle helft van een rapport is de hersteltabel: elke bevinding, de ernst volgens de methode van de beoordelaar, de reactie van de operator en het resultaat van de hertest. Ernstcijfers komen uit een gekozen methodologie en niet uit de natuur, dus vergelijk ernst binnen één rapport en niet tussen twee met verschillende schalen.

Verbind de oplossing vervolgens met vrijgegeven software. Een gerepareerde bevinding is voor een gebruiker pas van belang wanneer de versie met de oplossing de geïnstalleerde is, en daarom moeten de build-identificatie van een rapport en het wijzigingslogboek van een release samen worden gelezen. Een hertest die de oplossing dekte, sluit de lus; een ongeteste oplossing is een bewering. Dat geldt ook voor een oplossing die alleen is uitgebracht in een branch die geen stabiele release ooit heeft samengevoegd.

Wat de badge je niet kan vertellen

De afwezigheid van bevindingen is geen bewijs van de afwezigheid van gebreken. Een korte opdracht met een vast budget zal dingen missen, en de eerlijke lezing van een schoon rapport is dat de beoordelaar de gezochte probleemklassen in de beschikbare tijd niet heeft gevonden.

De badge kan ook niet spreken voor eigenschappen buiten zijn scope. Beweringen over logpraktijk, jurisdictie of bewaring leven in een beleidsdocument, niet in een audit van een clientapplicatie, en geen reputatie van de beoordelaar reikt over die grens.

Bewijs vastleggen dat je kunt verdedigen

Schrijf de verwijzing in drie delen: de component, de versie en de geverifieerde oplossing. Een gepubliceerde opdracht zoals de door Mozilla opdracht gegeven VPN-audit ondersteunt precies de uitspraken die zijn scope beschrijft en niets breder, wat nog steeds veel waard is wanneer de verwijzing precies is. Hetzelfde rapport aangehaald voor iets dat het nooit heeft onderzocht, is minder waard dan geen verwijzing, omdat het een vertrouwen uitnodigt dat niemand heeft verdiend.

Wanneer een beweerde eigenschap buiten elk beschikbaar rapport valt, laat die dan onopgelost in het document. Een onopgeloste regel nodigt uit tot een vervolgvraag; een badge niet. De enige uitzondering is een eigenschap die een ander, even specifiek document beslecht, en dan verandert de verwijzing en niet de bewering.

Nog twee gewoonten maken het lezen duurzaam: noteer de rapportdatum tegenover de release die je werkelijk draait, en houd het verschil bij tussen wat is getest en wat je hebt uitgerold. Beide maken van een vertrouwensbeslissing iets dat een collega kan controleren.