Cum citim un raport de audit VPN: aria de cuprindere contează mai mult decât insigna

Insignele sunt ieftine de afișat și scumpe de interpretat. Un raport de audit publicat este o bucată delimitată de muncă de inginerie: un evaluator numit a examinat componente numite, la o versiune numită, cu o metodă declarată și un buget de timp. Aceste patru fapte determină ce poate susține concluzia, și de obicei se află în primele pagini, nu în rezumatul de marketing. Citirea lor durează zece minute și previne eroarea obișnuită de a extinde o constatare despre o aplicație client la un serviciu întreg.

Ce delimitează de fapt secțiunea de cuprindere

O declarație de cuprindere este un gard, iar tot ce este în afara lui rămâne fără răspuns, nu trecut. Rapoartele enumeră componentele examinate, intervalul de commit-uri sau identificatorul versiunii, mediul folosit și modelul de interacțiune permis. Un client desktop, o aplicație mobilă, codul serverului, backendul contului și infrastructura de producție sunt cinci subiecte diferite, iar un angajament poate acoperi orice submulțime a lor.

Excluderile contează la fel de mult ca includerile, pentru că sunt declarate intenționat și citite neglijent. Un sistem de conturi descris ca fiind în afara ariei nu este implicit sigur, iar o aplicație mobilă lăsată în afara unui angajament pur și simplu nu este examinată. Marcați fiecare componentă netestată în propriile notițe ca necunoscută și rezistați tentației de a umple golul cu reputație.

Două tipuri de teste răspund la întrebări diferite

Revizuirea codului sursă și testarea în execuție caută defecțiuni diferite. Un recenzent care citește cod poate urmări o derivare de cheie, poate observa o verificare de lungime lipsă și poate raționa despre un parser întreg fără a-l executa. Un tester împotriva unui serviciu în funcțiune descoperă ce face de fapt versiunea implementată: un certificat pe care aplicația îl refuză, un protocol de rezervă încă activat, un punct final care scurge un banner de versiune printr-o configurație pe care nimeni nu a revizuit-o.

Niciunul nu îl înlocuiește pe celălalt, iar raportul numește de obicei care a fost efectuat. Când un rezumat spune «auditat» fără această distincție, ambiguitatea este în rezumat, nu în raport.

Limitele de acces fac același lucru. Un angajament de tip cutie neagră nu poate vedea configurația serverului, iar o revizuire de arhitectură care nu atinge niciodată un punct final implementat nu poate observa că producția diferă de diagramă. Ambele sunt legitime; combinarea rezultatelor lor nu este.

Cum o constatare devine o versiune corectată

Jumătatea valoroasă a unui raport este tabelul de remediere: fiecare constatare, gravitatea ei conform metodei evaluatorului, răspunsul operatorului și rezultatul retestării. Numerele de gravitate provin dintr-o metodologie aleasă și nu din natură, așa că comparați gravitățile într-un singur raport, nu între două cu scale diferite.

Apoi legați corectura de software-ul lansat. O constatare corectată contează pentru un utilizator doar când versiunea care poartă corectura este cea instalată, motiv pentru care identificatorul versiunii din raport și jurnalul de modificări al unei lansări trebuie citite împreună. O retestare care a acoperit corectura închide bucla; o corectură netestată este o afirmație. La fel este o corectură livrată doar într-o ramură pe care nicio lansare stabilă nu a fuzionat-o vreodată.

Ce nu vă poate spune insigna

Absența constatărilor nu este dovada absenței defectelor. Un angajament scurt cu buget fix va rata lucruri, iar lectura onestă a unui raport curat este că evaluatorul nu a găsit clasele de probleme pe care le căuta în timpul disponibil.

Insigna nu poate nici să vorbească despre proprietăți din afara ariei sale. Afirmațiile despre practicile de jurnalizare, jurisdicție sau păstrare trăiesc într-un document de politică, nu într-un audit al unei aplicații client, și nicio reputație a evaluatorului nu trece acea graniță.

Înregistrarea dovezilor pe care le puteți apăra

Scrieți citarea în trei părți: componenta, versiunea și corectura verificată. Un angajament publicat precum auditul VPN comandat de Mozilla susține exact afirmațiile pe care le descrie aria sa și nimic mai larg, ceea ce încă valorează destul de mult când citarea este precisă. Același raport citat pentru ceva ce nu a examinat niciodată valorează mai puțin decât nicio citare, pentru că invită la o încredere pe care nimeni nu a câștigat-o.

Când o proprietate afirmată cade în afara oricărui raport disponibil, lăsați-o nerezolvată în document. O linie nerezolvată invită la o întrebare ulterioară; o insignă nu. Singura excepție este o proprietate pe care o rezolvă un alt document, la fel de specific, iar atunci se schimbă citarea, nu afirmația.

Încă două obiceiuri fac lectura durabilă: notați data raportului față de lansarea pe care o rulați de fapt, și păstrați diferența dintre ce a fost testat și ce ați implementat. Ambele transformă o decizie de încredere în ceva ce un coleg poate verifica.