Å lese en VPN-revisjonsrapport: omfanget slår merket

Merker er billige å vise og dyre å tolke. En publisert revisjonsrapport er et avgrenset stykke ingeniørarbeid: en navngitt vurderer undersøkte navngitte komponenter, på en navngitt versjon, med en oppgitt metode og et tidsbudsjett. Disse fire fakta avgjør hva konklusjonen kan underbygge, og de står vanligvis på de første sidene fremfor i markedsføringssammendraget. Å lese dem tar ti minutter og forhindrer den vanlige feilen å utvide et funn om en klientapp til en hel tjeneste.

Hva omfangsavsnittet egentlig avgrenser

En omfangserklæring er et gjerde, og alt utenfor er ubesvart fremfor bestått. Rapportene lister opp de undersøkte komponentene, commit-området eller build-identifikatoren, miljøet som ble brukt og den tillatte interaksjonsmodellen. En skrivebordsklient, en mobilapp, serverkoden, konto-backenden og produksjonsinfrastrukturen er fem forskjellige emner, og et oppdrag kan dekke en hvilken som helst delmengde av dem.

Utelatelser betyr like mye som inkluderinger, fordi de oppgis med vilje og leses slurvete. Et kontosystem beskrevet som utenfor omfang antas ikke å være sikkert, og en mobilapp som holdes utenfor et oppdrag er rett og slett ikke undersøkt. Merk hver utestet komponent i dine egne notater som ukjent, og motstå trangen til å fylle gapet med omdømme.

To typer test svarer på forskjellige spørsmål

Kildegjennomgang og test under kjøring leter etter forskjellige feil. En gjennomgåer som leser kode kan følge en nøkkelavledning, oppdage en manglende lengdekontroll og resonnere om en hel parser uten å kjøre den. En tester mot en kjørende tjeneste oppdager hva den utrullede builden faktisk gjør: et sertifikat appen avviser, en reserveprotokoll som fortsatt er aktivert, et endepunkt som lekker et versjonsbanner gjennom en konfigurasjon ingen har gjennomgått.

Ingen av dem erstatter den andre, og rapporten navngir vanligvis hvilken som ble utført. Når et sammendrag sier «revisjonert» uten den forskjellen, ligger uklarheten i sammendraget, ikke i rapporten.

Tilgangsbegrensninger gjør samme arbeid. Et svart-boks-oppdrag kan ikke se serverkonfigurasjonen, og en arkitekturgjennomgang som aldri berører et utrullet endepunkt kan ikke oppdage at produksjonen avviker fra diagrammet. Begge er legitime; å blande resultatene deres er det ikke.

Hvordan et funn blir en rettet versjon

Den verdifulle halvdelen av en rapport er utbedringstabellen: hvert funn, alvorlighetsgraden etter vurdererens metode, operatørens svar og resultatet av nyttesten. Alvorlighetstall kommer fra en valgt metodikk og ikke fra naturen, så sammenlign alvorlighet innenfor én rapport i stedet for mellom to med forskjellige skalaer.

Koble deretter rettelsen til utgitt programvare. Et rettet funn betyr noe for en bruker først når versjonen som bærer rettelsen er den installerte, og derfor må en rapports build-identifikator og en utgivelses endringslogg leses sammen. En nyttest som dekket rettelsen lukker sløyfen; en utestet rettelse er en påstand. Det samme er en rettelse som bare ble sendt i en gren som ingen stabil utgivelse noen gang slo sammen.

Hva merket ikke kan fortelle deg

Fravær av funn er ikke bevis for fravær av feil. Et kort oppdrag med fast budsjett vil overse ting, og den ærlige lesningen av en ren rapport er at vurdereren ikke fant de problemklassene de lette etter i den tiden som var tilgjengelig.

Merket kan heller ikke snakke for egenskaper utenfor sitt omfang. Påstander om loggføringspraksis, jurisdiksjon eller oppbevaring lever i et policydokument, ikke i en revisjon av en klientapplikasjon, og ingen omdømme hos vurdereren overføres over den grensen.

Å registrere bevis du kan forsvare

Skriv siteringen i tre deler: komponenten, versjonen og den verifiserte rettelsen. Et publisert oppdrag som VPN-revisjonen bestilt av Mozilla underbygger nøyaktig de utsagnene som omfanget beskriver og ingenting bredere, noe som fortsatt er ganske mye verdt når siteringen er presis. Den samme rapporten sitert for noe den aldri undersøkte er mindre verdt enn ingen sitering, fordi den inviterer til en tillit ingen har fortjent.

Når en påstått egenskap faller utenfor enhver tilgjengelig rapport, la den stå uavklart i dokumentet. En uavklart linje inviterer til et oppfølgingsspørsmål; et merke gjør det ikke. Det eneste unntaket er en egenskap som et annet, like spesifikt dokument avgjør, og da endres siteringen i stedet for påstanden.

To vaner til gjør lesningen varig: noter rapportdatoen mot utgivelsen du faktisk kjører, og hold forskjellen mellom det som ble testet og det du rullet ut. Begge gjør en tillitsbeslutning til noe en kollega kan kontrollere.