A biztonsági szabályzat oldala nem közzétételi folyamat

Minden komoly projektnek van biztonsági oldala, és egy oldal olcsó. A hasznos kérdés az, hogy a dokumentált csatornán küldött jelentés eredményez-e olyan javított kiadást, amelyet a hétköznapi felhasználók telepíthetnek. Ehhez négy bizonyíték kell egy állítás helyett, és mindegyik kívülről ellenőrizhető anélkül, hogy bármit is szondáznánk. Egyik sem igényel tesztet valaki más szervere ellen. Mindegyik elfér egy oldal jegyzeten.

Találja meg a csatornát, és ellenőrizze, hogy létezik

Kezdje a dokumentált útvonallal: biztonsági szabályzat oldala, dedikált cím vagy olyan /.well-known/security.txt fájl, amelynek Contact mezőjét a RFC 9116 határozza meg.

Ezután a hatókörről szóló bekezdést olvassa el, ne a barátságos bevezetőt. Mely termékeket fedi le, mely verziókat, és milyen bánásmódot kér a projekt?

Egy másik projekthez, vagy a karbantartó helyett tárhelyszolgáltatóhoz tartozó csatorna nem közzétételi folyamat az értékelt szoftver számára.

Nyilvános követő vagy privát csatorna

A hétköznapi hibák a nyilvános követőbe tartoznak, és hasznukra válnak. A kihasználható részletet tartalmazó jelentés nem, és nyilvános beküldése kiteszi a felhasználókat, miközben a karbantartó még olvassa.

Az a projekt, amely csak nyilvános követőt kínál, nem biztosított közzétételi csatornát, bármit is mond a dokumentációja.

Ezek egyike sem engedélyezi olyan rendszerek tesztelését, amelyek nem a sajátjai. A jelentési cím információ küldésére szóló meghívás, nem engedély összefüggéstelen nyilvános szerverek szondázására.

Kövessen végig egy javítást elejétől a végéig

Válasszon egy korábbi közleményt, és kövesse: megnevezi-e az érintett verziókat és a javító kiadást, és a felhasználó valóban telepítheti-e azt a kiadást?

Ez a nyom a visszaigazolás és a javítás közötti különbség. Az udvarias válasz, amely soha nem eredményez kiadást, közönségkapcsolati eredmény. A tömör közlemény verziószámmal és letöltési hivatkozással működő folyamat. A jó közlemény gyorsan négy dologra válaszol: mi érintett, mi a hatás, melyik verzió javítja, és hol szerezhető be.

A kiadási előzmények kitöltik a többit. A rendszeres, világos jegyzetekkel ellátott kiadások olyan projektre utalnak, amely képes javítást szállítani, és ez többet számít egy ékesszóló szabályzatnál.

A kliens karbantartója vagy a szolgáltatás üzemeltetője

VPN esetében a klienst írók és az átjárót üzemeltetők gyakran különböző szervezetek. A kliens kódjának problémája és a szerver telepítési hibája különböző címzetteket igényel.

Döntse el küldés előtt, melyikükre vonatkozik a lelete, mert a rossz félhez irányítás általában csenddel végződik, nem visszapattanással.

Mit bizonyít a hiány, és mit nem

Egy üres közleménylista nem bizonyítja, hogy a termék mentes a hibáktól. Jelenthet fiatal projektet, kis felületet, vagy azt, hogy senki sem nézi.

Ugyanígy a hiányzó szabályzatoldal nem a rosszhiszeműség bizonyítéka. Annak bizonyítéka, hogy nem tudja ellenőrizni a folyamatot, és ez az őszinte következtetés, amelyet rögzíteni kell.

Mit írjon le

Rögzítsen négy tényt: egy kapcsolatot, amelyet ellenőrizni tud, egy hatókört, amely lefedi a verzióját, a javított kiadásokat megnevező közleményeket, és egy kiadási előzményt, amely megmutatja, hogy a javítások megjelennek.

Ezután jegyezze fel, mi marad ismeretlen. Az ezt kimondó értékelés hasznosabb annál, amely egy hiányzó szabályzatot biztonsági állítássá alakít.