En sida om säkerhetspolicy är inte en offentliggörandeprocess

Varje seriöst projekt har en säkerhetssida, och en sida är billig. Den användbara frågan är om en rapport som skickas genom den dokumenterade kanalen leder till en rättad utgåva som vanliga användare kan installera. Det kräver fyra bevis i stället för ett påstående, och alla är kontrollerbara utifrån utan att något undersöks. Ingen av dem kräver ett test mot någon annans server. Alla får plats på en sida anteckningar.

Hitta kanalen och kontrollera att den finns

Börja med den dokumenterade vägen: en sida om säkerhetspolicy, en dedikerad adress eller en /.well-known/security.txt-fil där fältet Contact definieras av RFC 9116.

Läs sedan avsnittet om omfattningen i stället för den vänliga introduktionen. Vilka produkter omfattas, vilka versioner, och vilken hantering ber projektet om?

En kanal som tillhör ett annat projekt, eller en webbhotellsleverantör i stället för underhållaren, är inte en offentliggörandeprocess för programvaran du utvärderar.

Offentlig tracker eller privat kanal

Vanliga fel hör hemma i en offentlig tracker och drar nytta av den. En rapport med en utnyttjbar detalj gör inte det, och att lämna in den offentligt utsätter användarna medan underhållaren fortfarande läser den.

Ett projekt som bara erbjuder en offentlig tracker har inte tillhandahållit en offentliggörandekanal, vad dokumentationen än säger.

Inget av detta tillåter testning av system du inte äger. En rapporteringsadress är en inbjudan att skicka information, inte tillstånd att undersöka orelaterade offentliga servrar.

Följ en rättelse från början till slut

Välj ett tidigare meddelande och följ det: namnger det de berörda versionerna och utgåvan som rättar dem, och kan en användare verkligen installera den utgåvan?

Det spåret är skillnaden mellan en bekräftelse och en reparation. Ett artigt svar som aldrig leder till en utgåva är ett resultat för PR. Ett kort meddelande med versionsnummer och nedladdningslänk är en fungerande process. Ett bra meddelande svarar snabbt på fyra saker: vad som berörs, vilken påverkan det har, vilken version som rättar det och var man får tag i den.

Utgivningshistoriken fyller i resten. Regelbundna utgåvor med tydliga anteckningar tyder på ett projekt som kan leverera en rättelse, och det betyder mer än en vältalig policy.

Underhållare av klienten eller operatör av tjänsten

För en VPN är de som skriver klienten och de som driver en gateway ofta olika organisationer. Ett problem i klientkoden och ett fel vid serverutrullning kräver olika mottagare.

Avgör vilken av de två ditt fynd gäller innan du skickar det, eftersom att skicka det till fel part oftast slutar i tystnad i stället för en retur.

Vad frånvaro bevisar, och vad den inte bevisar

En tom meddelandelista bevisar inte att en produkt är fri från fel. Det kan betyda ett ungt projekt, en liten yta, eller att ingen tittar.

På samma sätt är en saknad policysida inte bevis på ond tro. Det är bevis på att du inte kan verifiera processen, och det är den ärliga slutsatsen att anteckna.

Vad som ska skrivas ned

Anteckna fyra fakta: en kontakt du kan verifiera, en omfattning som täcker din version, meddelanden som namnger rättade utgåvor, och en utgivningshistorik som visar att rättelser kommer ut.

Anteckna sedan vad som förblir okänt. En granskning som säger det är mer användbar än en som förvandlar en saknad policy till ett påstående om säkerhet.