Ansvarlig offentliggørelse: en kontaktvej for sårbarheder

Hvis en udefrakommende finder en sårbarhed i jeres produkt i morgen, hvor skal vedkommende så skrive? Kunder stiller det spørgsmål i sikkerhedsskemaer, fordi svaret siger noget om, hvordan I håndterer fund, også dem, ingen tester har fundet. Svaret hviler på to ting, der skal hænge sammen: en kontaktvej, som er let at finde, og en politik, der fortæller den, der melder, hvad der sker bagefter. Ingen af dem kræver et stort setup, men de skal virke, og de skal passe til jeres egen proces for rettelser.

Hvorfor kunderne spørger

Et spørgsmål om ansvarlig offentliggørelse er et spørgsmål om modenhed. Kunden vil vide, om I har tænkt over, at sårbarheder kan blive fundet af andre end jeres tester, og om I har en ordnet måde at tage imod dem på. Et ja med en henvisning til en offentlig politik er et konkret svar, kunden kan kontrollere. Et nej er også et svar, men så bør det følges af en plan for, hvornår en kontaktvej er på plads. → Spørgsmål om hændelser og håndtering af sårbarheder

For nogle produkter kan der også være et lovkrav. Cyber Resilience Act, forordning (EU) 2024/2847, kræver i bilag I, del II, at fabrikanter af produkter med digitale elementer indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder og angiver en kontaktadresse til indberetning. Om forordningen gælder jeres produkt, er et særskilt spørgsmål. → Cyber Resilience Act

Kontaktvejen

Den, der finder en sårbarhed, skal kunne finde ud af, hvor den skal meldes, uden at skulle gætte. NCSC i Storbritannien anbefaler en særskilt e-mailadresse eller en sikker webformular, og at den er let at finde, fx på siden om sikkerhed eller på kontaktsiden.

RFC 9116 beskriver en tekstfil, security.txt, som placeres et fast sted på domænet, så den kan findes på samme måde hos alle. Filen skal altid have et felt med kontaktvejen og et felt med en udløbsdato, så det er tydeligt, om oplysningerne stadig gælder. Et felt med et link til politikken er valgfrit, men nyttigt. RFC 9116 er en informativ specifikation fra IETF, ikke en standard, I kan blive målt efter, men den er et kendt sted at lede.

Hold adressen til en fælles postkasse, ikke en persons egen. Kommer en melding ind, mens den sikkerhedsansvarlige har ferie, skal den stadig blive læst.

Har I flere domæner, fx et til hjemmesiden, et til selve produktet og et til API’et, så sørg for, at kontaktvejen kan findes fra dem alle. Den, der finder noget i API’et, starter ikke nødvendigvis på forsiden. Gennemgå også filen og siden, når I skifter adresse eller organisering, så der ikke står en postkasse, ingen længere læser.

Politikken

En politik for ansvarlig offentliggørelse er en kort tekst, der sætter rammerne for begge parter. NCSC nævner som grundlæggende indhold:

Hvordan I vil kontaktes · og hvilke sikre måder der findes at sende oplysninger på.
Hvad en melding skal indeholde · så I kan genskabe og vurdere fundet.
Hvad den, der melder, kan forvente · kvittering, løbende besked og besked, når fundet er rettet.
Hvad der er med, og hvad der ikke er · hvilke dele af produktet og hvilke handlinger politikken dækker.

NCSC fraråder at kræve, at den, der melder, skriver under på en fortrolighedsaftale. Den internationale standard ISO/IEC 29147 beskriver mere detaljeret, hvordan leverandører kan modtage og offentliggøre oplysninger om sårbarheder.

Undlad at love faste frister, I ikke kan holde. Løbende besked er bedre end en frist, der overskrides. → Pligt til at underrette kunden om sårbarheder

Hvad der sker, når en melding kommer ind

Politikken er kun så god som den proces, der ligger bag. Når en melding kommer ind, skal nogen kvittere, vurdere alvorligheden, sende den videre til udviklingen og følge op. Brug den samme proces, som I bruger til fund fra pentesten, så meldinger udefra ikke lever deres eget liv.

Beslut på forhånd, hvem der vurderer, om kunderne skal have besked. En alvorlig sårbarhed, der er meldt udefra, kan stille jer i samme situation som et alvorligt fund i en test: kunderne kan have behov for at vide det, og I skal have et svar klar, før de spørger. → Sikkerhedsmeddelelse til kunderne

Politikken og pentesten

En politik for ansvarlig offentliggørelse er ikke en invitation til at teste jeres produkt. Det skal fremgå tydeligt, så ingen læser den som en tilladelse til at angribe produktet eller kundernes data. Beskriv, hvad politikken dækker, og at handlinger, der kan skade driften eller andres data, ikke er omfattet.

Kunder, der vil teste produktet, skal følge jeres regler for kundetest, ikke politikken for meldinger. Det er to forskellige veje med forskellige formål, og de bør stå hver for sig. → En testpolitik for kunder

Omvendt kan meldinger udefra bruges i planlægningen af den næste pentest. Et område, hvor der er meldt flere fund, kan være et sted, testeren bør gå grundigere til. Fortæl gerne testeren om de meldinger, I har fået siden sidste test, og om hvordan de blev rettet.

Et tænkt eksempel

Et softwarehus med et system til medlemsadministration får et sikkerhedsskema, der spørger, om der findes en offentlig politik for sårbarhedsmeldinger. Svaret er nej. Den eneste vej er den almindelige supportadresse.

Softwarehuset opretter en fælles adresse for sikkerhed, skriver en kort politik med NCSC’s punkter og lægger den på tillidssiden sammen med en security.txt-fil. Meldinger registreres i det samme system som fund fra pentesten. Svaret i skemaet bliver et ja med et link, og kunden kan selv læse politikken.

Det skal I lade være med

Bruge supportadressen · meldinger om sårbarheder skal ikke drukne blandt andre sager.
Kræve fortrolighedsaftale af den, der melder · det kan holde folk fra at melde.
Love faste frister · giv hellere løbende besked.
Formulere politikken som en testtilladelse · grænserne skal stå tydeligt.
Glemme udløbsdatoen · en forældet kontaktvej er værre end ingen.

Hvad kan og ikke kan konkluderes

En kontaktvej og en politik viser kunderne, at I har en ordnet måde at modtage sårbarheder på, og den giver dem noget konkret at kontrollere. Den viser ikke, at produktet er testet, og den erstatter ikke en penetrationstest. Om et lovkrav gælder jeres produkt, skal vurderes for sig. Teksten er ikke juridisk rådgivning.

Tjekliste til kontaktvejen

☐ Er der en fælles adresse eller sikker formular?
☐ Er politikken offentlig og let at finde?
☐ Fortæller politikken, hvad den, der melder, kan forvente?
☐ Er der en security.txt-fil med kontaktvej og udløbsdato?
☐ Går meldinger ind i samme proces som fund fra pentesten?

Kilder

NCSC (UK): Vulnerability Disclosure Toolkit: kontaktvej, politikkens grundindhold, security.txt og rådet om ikke at kræve fortrolighedsaftaler af den, der melder.
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure: informativ specifikation; felterne Contact og Expires skal altid være til stede, Policy er valgfrit.
ISO/IEC 29147:2018 Vulnerability disclosure: leverandørers modtagelse og offentliggørelse af oplysninger om sårbarheder.
Cyber Resilience Act, forordning (EU) 2024/2847: bilag I, del II, punkt 5 og 6, om politik for koordineret offentliggørelse og kontaktadresse til indberetning.

Senest gennemgået: oktober 2026.