Een pagina met beveiligingsbeleid is geen openbaringsproces

Elk serieus project heeft een beveiligingspagina, en een pagina is goedkoop. De nuttige vraag is of een melding via het gedocumenteerde kanaal leidt tot een herstelde versie die gewone gebruikers kunnen installeren. Dat vraagt vier stukken bewijs in plaats van één bewering, en ze zijn allemaal van buitenaf controleerbaar zonder iets te onderzoeken. Geen ervan vereist een test tegen iemands anders server. Ze passen allemaal op één pagina notities.

Vind het kanaal en controleer dat het bestaat

Begin met de gedocumenteerde route: een pagina met beveiligingsbeleid, een toegewijd adres of een bestand /.well-known/security.txt waarvan het veld Contact is gedefinieerd door RFC 9116.

Lees dan de alinea over het bereik in plaats van de vriendelijke inleiding. Welke producten worden gedekt, welke versies, en welke behandeling vraagt het project?

Een kanaal dat bij een ander project hoort, of bij een hostingprovider in plaats van de beheerder, is geen openbaringsproces voor de software die je beoordeelt.

Openbare tracker of privékanaal

Gewone fouten horen in een openbare tracker en hebben er baat bij. Een melding met een exploiteerbaar detail niet, en die openbaar indienen stelt gebruikers bloot terwijl de beheerder het nog leest.

Een project dat alleen een openbare tracker biedt, heeft geen openbaringskanaal geleverd, wat de documentatie ook zegt.

Niets hiervan geeft toestemming om systemen te testen die niet van jou zijn. Een meldadres is een uitnodiging om informatie te sturen, geen toestemming om ongerelateerde openbare servers te onderzoeken.

Volg één herstel van begin tot eind

Kies een eerder advies en volg het: noemt het de getroffen versies en de release die ze herstelt, en kan een gebruiker die release echt installeren?

Dat spoor is het verschil tussen een bevestiging en een reparatie. Een beleefd antwoord dat nooit een release oplevert, is een resultaat voor public relations. Een kort advies met een versienummer en een downloadlink is een werkend proces. Een goed advies beantwoordt vier dingen snel: wat getroffen is, wat de impact is, welke versie het herstelt en waar je het haalt.

De releasegeschiedenis vult de rest in. Regelmatige releases met duidelijke notities wijzen op een project dat een herstel kan leveren, en dat telt meer dan een welsprekend beleid.

Beheerder van de client of operator van de dienst

Voor een VPN zijn de mensen die de client schrijven en de mensen die een gateway beheren vaak verschillende organisaties. Een probleem in clientcode en een fout bij serveruitrol vragen verschillende ontvangers.

Bepaal welke van de twee je bevinding betreft voordat je hem verstuurt, want naar de verkeerde partij sturen eindigt meestal in stilte in plaats van een terugstuitering.

Wat afwezigheid bewijst, en wat niet

Een lege advieslijst bewijst niet dat een product vrij is van fouten. Het kan een jong project betekenen, een klein oppervlak, of dat niemand kijkt.

Evenzo is een ontbrekende beleidspagina geen bewijs van kwade trouw. Het is bewijs dat je het proces niet kunt verifiëren, en dat is de eerlijke conclusie om op te schrijven.

Wat op te schrijven

Noteer vier feiten: een contact dat je kunt verifiëren, een bereik dat je versie dekt, adviezen die herstelde releases noemen, en een releasegeschiedenis die laat zien dat herstel uitkomt.

Noteer dan wat onbekend blijft. Een beoordeling die dat zegt is nuttiger dan een die een ontbrekend beleid omzet in een bewering over veiligheid.