En side om sikkerhetspolicy er ikke en offentliggjøringsprosess

Ethvert seriøst prosjekt har en sikkerhetsside, og en side er billig. Det nyttige spørsmålet er om en rapport sendt gjennom den dokumenterte kanalen fører til en rettet utgivelse som vanlige brukere kan installere. Det krever fire bevis i stedet for én påstand, og alle er kontrollerbare utenfra uten å undersøke noe. Ingen av dem krever en test mot noen andres server. Alle får plass på én side med notater.

Finn kanalen og undersøk at den finnes

Begynn med den dokumenterte veien: en side om sikkerhetspolicy, en dedikert adresse eller en /.well-known/security.txt-fil der feltet Contact er definert av RFC 9116.

Les deretter avsnittet om omfanget i stedet for den vennlige introduksjonen. Hvilke produkter er dekket, hvilke versjoner, og hvilken håndtering ber prosjektet om?

En kanal som tilhører et annet prosjekt, eller en hostingleverandør i stedet for vedlikeholderen, er ikke en offentliggjøringsprosess for programvaren du vurderer.

Offentlig tracker eller privat kanal

Vanlige feil hører hjemme i en offentlig tracker og har nytte av den. En rapport med en utnyttbar detalj gjør ikke det, og offentlig innsending utsetter brukerne mens vedlikeholderen fortsatt leser den.

Et prosjekt som bare tilbyr en offentlig tracker, har ikke gitt en offentliggjøringskanal, uansett hva dokumentasjonen sier.

Ingenting av dette tillater testing av systemer du ikke eier. En rapporteringsadresse er en invitasjon til å sende informasjon, ikke tillatelse til å undersøke urelaterte offentlige servere.

Følg én rettelse fra start til slutt

Velg et tidligere varsel og følg det: navngir det de berørte versjonene og utgivelsen som retter dem, og kan en bruker faktisk installere den utgivelsen?

Det sporet er forskjellen mellom en erkjennelse og en reparasjon. Et høflig svar som aldri fører til en utgivelse, er et resultat for omdømmearbeid. Et kort varsel med versjonsnummer og nedlastingslenke er en fungerende prosess. Et godt varsel svarer raskt på fire ting: hva som er berørt, hva påvirkningen er, hvilken versjon som retter det, og hvor man får tak i den.

Utgivelseshistorikken fyller ut resten. Regelmessige utgivelser med klare notater tyder på et prosjekt som kan levere en rettelse, og det betyr mer enn en veltalende policy.

Vedlikeholder av klienten eller operatør av tjenesten

For en VPN er de som skriver klienten, og de som driver en gateway, ofte forskjellige organisasjoner. Et problem i klientkoden og en feil ved serverutrulling krever forskjellige mottakere.

Avgjør hvilken av de to funnet ditt gjelder, før du sender det, fordi å sende det til feil part vanligvis ender i stillhet i stedet for en retur.

Hva fravær beviser, og hva det ikke beviser

En tom varselliste beviser ikke at et produkt er fritt for feil. Det kan bety et ungt prosjekt, en liten flate, eller at ingen ser.

På samme måte er en manglende policyside ikke bevis på vond tro. Det er bevis på at du ikke kan verifisere prosessen, og det er den ærlige konklusjonen å notere.

Hva som skal skrives ned

Noter fire fakta: en kontakt du kan verifisere, et omfang som dekker versjonen din, varsler som navngir rettede utgivelser, og en utgivelseshistorikk som viser at rettelser kommer ut.

Noter deretter hva som forblir ukjent. En gjennomgang som sier det, er nyttigere enn en som gjør en manglende policy til en påstand om sikkerhet.