En dag kan noen utenfor selskapet ditt finne en svakhet i produktet ditt. Hva som skjer da, avhenger av et lite spørsmål: kan de finne ut hvem de skal si fra til? Er svaret et generelt supportskjema, en salgsinnboks eller ingenting, kan meldingen bli liggende i feil kø, eller aldri komme frem.
Dette essayet tar for seg to svar på det spørsmålet: en fil som forteller folk hvor de skal skrive, og en policy som forteller dem hva som skjer når de har gjort det. Det er ikke juridisk rådgivning, og ingenting her sier om produktet ditt oppfyller noen lov. Den vurderingen hører til deg og rådgiverne dine.
En fil på et sted alle kan se
RFC 9116, publisert i april 2022, beskriver en ren tekstfil som heter security.txt. For et nettsted ligger den på /.well-known/security.txt, og RFC-en ber om at den leveres over HTTPS. Alle som vil melde et problem, kan se på samme sted på hvert nettsted.
RFC 9116 gjør to felt påkrevd:
- Contact: hvor meldinger skal sendes, skrevet som en URI, for eksempel en e-postadresse eller en nettside. Det må stå minst én gang og kan stå flere ganger.
- Expires: datoen og tidspunktet da filen skal regnes som utdatert. Det må stå nøyaktig én gang, og RFC-en anbefaler en dato mindre enn ett år frem i tid.
Alt annet er valgfritt. RFC 9116 kaller de andre feltene Acknowledgments (en side som takker dem som har meldt problemer), Canonical (hvor filen offisielt ligger), Encryption (en nøkkel for å sende en melding privat), Hiring (sikkerhetsstillinger dere rekrutterer til), Policy (en lenke til policyen deres for avsløring) og Preferred-Languages (språkene teamet ditt leser). RFC-en anbefaler også å signere filen med en OpenPGP-klartekstsignatur.
Expires-feltet er det som gjør en fil til en vane. Det tvinger noen til å se på kontakten igjen, og det er poenget: en kontakt ingen leser, er verre enn ingen, fordi den ser ut som et svar.
En policy som sier hva som skjer videre
En fil forteller folk hvor de skal skrive. En policy for koordinert avsløring forteller dem hva som skjer etter at de har gjort det. Enkelt sagt er det en publisert side som sier hva dere vil ha meldt og hvordan, hva den som melder kan regne med fra dere, og hvordan dere og de blir enige om når en svakhet og rettelsen av den blir offentlig. Ordet «koordinert» bærer ideen: den som fant svakheten og den som lagde produktet, blir enige om tidspunktet, i stedet for at én av sidene bestemmer alene.
Policy-feltet i security.txt er der de to møtes. Filen peker til policyen, og policyen forklarer prosessen.
Der Cyber Resilience Act kommer inn
I Europa er dette i ferd med å gå fra god praksis mot et lovkrav for noen produkter. Forordning (EU) 2024/2847, Cyber Resilience Act, setter krav til håndtering av sårbarheter i vedlegg I, del II. Blant dem bes en produsent om å innføre og håndheve en policy for koordinert avsløring av sårbarheter, og om å gjøre det lettere å dele informasjon om mulige sårbarheter, blant annet ved å oppgi en kontaktadresse for å melde dem.
Etter artikkel 71 gjelder disse kravene fra 11. desember 2027. Forordningen nevner ikke security.txt, og om produktet ditt i det hele tatt faller inn under den, er et spørsmål for rådgiverne dine. Essayet vårt Cyber Resilience Act, for produktledere går gjennom virkeområdet, datoene og resten av det teksten krever.
Hva som må bestemmes
Det koker ned til en håndfull beslutninger som noen bør eie:
- Hvem som mottar meldinger, og hvilken adresse de kommer til. Velg en dere er villige til å beholde.
- Hvem som fornyer filen før Expires-datoen, og hvordan de blir minnet på det.
- Hva policyen deres sier, med ord teamet deres selv kan stå inne for.
- Hvem som avgjør når en meldt svakhet er alvorlig, og hvem som snakker med den som meldte den.
Avgjør dette én gang, hold det oppdatert, og du kan løfte blikket fra innboksen til produktet kundene dine er avhengige av.
Der vi kommer inn
Vi gir ikke juridisk rådgivning, vi lover aldri etterlevelse, og vi sier ikke når du vil være klar. Sikkerhetskontakten din, policyen din og meldingene du mottar, forblir dine.
Det vi kan gjøre, er sikkerhetsarbeidet på produktet ditt som du velger. Vi arbeider innenfor tilgangen du gir, og ikke noe mer. Arbeidet havner i ditt eget kodelager. Koden vi bygger for deg, er din. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning. Det starter med en samtale, helt uforpliktende, og selve arbeidet er beskrevet i Harden security before the questionnaire arrives (på engelsk).
