VPN-auditjelentés olvasása: a hatókör többet ér, mint a jelvény

A jelvényeket olcsó felmutatni és drága értelmezni. Egy közzétett auditjelentés körülhatárolt mérnöki munka: egy megnevezett értékelő megnevezett komponenseket vizsgált megnevezett verzióban, megadott módszerrel és időkerettel. Ez a négy tény határozza meg, mit tud alátámasztani a következtetés, és általában az első oldalakon szerepelnek, nem a marketingösszefoglalóban. Elolvasásuk tíz percet vesz igénybe, és megakadályozza azt a gyakori hibát, hogy egy kliensalkalmazásra vonatkozó megállapítást kiterjesszenek egy egész szolgáltatásra.

Mit korlátoz valójában a hatókörről szóló szakasz

A hatókörnyilatkozat kerítés, és minden, ami azon kívül esik, megválaszolatlan marad, nem pedig átment. A jelentések felsorolják a vizsgált komponenseket, a commit-tartományt vagy a build-azonosítót, a használt környezetet és a megengedett interakciós modellt. Az asztali kliens, a mobilalkalmazás, a szerverkód, a fiók backendje és a termelési infrastruktúra öt különböző témakör, és egy megbízás ezek bármely részhalmazát lefedheti.

A kizárások ugyanolyan fontosak, mint a bevonások, mert szándékosan kimondják és gondatlanul olvassák őket. Egy hatókörön kívülinek leírt fiókrendszer nem minősül implicit módon biztonságosnak, és egy megbízásból kimaradt mobilalkalmazás egyszerűen vizsgálatlan. Jelöljön meg minden nem tesztelt komponenst a saját jegyzeteiben ismeretlenként, és álljon ellen a kísértésnek, hogy a hiányt hírnévvel töltse ki.

Kétféle teszt különböző kérdésekre válaszol

A forráskód-átvizsgálás és a futásidejű tesztelés különböző hibákat keres. A kódot olvasó bíráló követheti egy kulcs levezetését, észrevehet egy hiányzó hosszellenőrzést, és egy egész elemzőről tud érvelni anélkül, hogy futtatná. A futó szolgáltatás ellen tesztelő azt fedezheti fel, mit tesz valójában a telepített build: egy tanúsítvány, amelyet az alkalmazás elutasít, egy még engedélyezett tartalék protokoll, egy végpont, amely senki által nem vizsgált konfiguráción keresztül kiszivárogtat egy verzióbannert.

Egyik sem helyettesíti a másikat, és a jelentés általában megnevezi, melyik történt meg. Ha egy összefoglaló e megkülönböztetés nélkül mondja, hogy „auditált”, a kétértelműség az összefoglalóban van, nem a jelentésben.

A hozzáférési korlátok ugyanezt teszik. Egy fekete dobozos megbízás nem látja a szerverkonfigurációt, és egy olyan architektúra-átvizsgálás, amely soha nem érint egy telepített végpontot, nem veheti észre, hogy a termelés eltér a diagramtól. Mindkettő legitim; az eredményeik összemosása nem az.

Hogyan lesz egy megállapításból javított verzió

A jelentés értékes fele a helyreállítási táblázat: minden megállapítás, annak súlyossága az értékelő módszere szerint, az üzemeltető válasza és az újrateszt eredménye. A súlyossági számok választott módszertanból származnak, nem a természetből, ezért egy jelentésen belül hasonlítsa össze a súlyosságokat, ne két különböző skálájú jelentés között.

Ezután kapcsolja a javítást a kiadott szoftverhez. Egy javított megállapítás csak akkor fontos a felhasználónak, ha a javítást hordozó verzió van telepítve, ezért kell a jelentés build-azonosítóját és egy kiadás változásnaplóját együtt olvasni. A javítást lefedő újrateszt lezárja a kört; a nem tesztelt javítás állítás. Ugyanígy az a javítás is, amelyet csak olyan ágban adtak ki, amelyet egyetlen stabil kiadás sem egyesített.

Mit nem tud megmondani a jelvény

A megállapítások hiánya nem bizonyítéka a hibák hiányának. Egy rövid, fix költségvetésű megbízás kihagy dolgokat, és egy tiszta jelentés őszinte olvasata az, hogy az értékelő nem találta meg azokat a problémacsztályokat, amelyeket a rendelkezésre álló időben keresett.

A jelvény sem beszélhet a hatókörén kívüli tulajdonságokról. A naplózási gyakorlatra, joghatóságra vagy megőrzésre vonatkozó állítások szabályzatdokumentumban élnek, nem egy kliensalkalmazás auditjában, és az értékelő semmilyen hírneve nem lép át ezen a határon.

Megvédhető bizonyítékok rögzítése

Írja le a hivatkozást három részben: a komponens, a verzió és az igazolt javítás. Egy közzétett megbízás, mint a Mozilla által megrendelt VPN-audit pontosan azokat az állításokat támasztja alá, amelyeket a hatóköre leír, és semmi szélesebbet, ami pontos hivatkozás esetén még mindig meglehetősen sokat ér. Ugyanaz a jelentés, amelyet olyasmihez idéznek, amit soha nem vizsgált, kevesebbet ér a hivatkozás hiányánál, mert olyan bizalmat hív meg, amelyet senki nem érdemelt ki.

Ha egy állított tulajdonság minden elérhető jelentésen kívül esik, hagyja megoldatlanul a dokumentumban. Egy megoldatlan sor utánkövetkező kérdést hív, a jelvény nem. Az egyetlen kivétel az a tulajdonság, amelyet egy másik, ugyanolyan konkrét dokumentum eldönt, és akkor a hivatkozás változik, nem az állítás.

Két további szokás tartóssá teszi az olvasást: jegyezze fel a jelentés dátumát ahhoz a kiadáshoz képest, amelyet valóban futtat, és tartsa meg a különbséget a tesztelt és a telepített között. Mindkettő egy bizalmi döntést olyanná tesz, amit egy kolléga ellenőrizhet.