Sikkerhed og beredskab

Rapportering af sikkerhedsfejl: gør det trygt at kontakte jer med security.txt

En kunde, medarbejder eller sikkerhedsresearcher kan opdage en fejl, før jeres overvågning gør. Hvis den eneste kontaktvej er en offentlig formular eller et GitHub-issue, kan følsomme detaljer ende det forkerte sted. En tydelig, privat rapporteringskanal og et lille internt flow gør det lettere at modtage fundet roligt og få det undersøgt.

Udgivet 13. oktober 2026 · Ca. 11 minutters læsetid

Det korte svar

Opret en privat kontaktvej, som en navngiven person faktisk følger. Beskriv hvad en rapport bør indeholde, og bed om at sårbarheder ikke lægges offentligt. Udgiv derefter en security.txt på /.well-known/security.txt, så kontaktvejen kan findes maskinelt. Aftal internt hvem der kvitterer, vurderer, begrænser skaden, retter, tester og melder tilbage.

security.txt er et skilt — ikke et beredskab

Filen fortæller, hvor et fund skal sendes. Den overvåger ikke appen, vurderer ikke alvoren og retter ingenting. Den har kun værdi, hvis kontaktvejen virker, ansvaret er placeret, og en troværdig rapport kan kobles til jeres driftsberedskab.

Vælg en kanal, I kan beskytte og passe

Kanalen skal være privat, tilgængelig udefra og uafhængig af én bestemt medarbejders personlige konto. Det kan være en funktionspostkasse, en sikker formular eller en etableret rapporteringsfunktion. Brug ikke en offentlig issue tracker til detaljer om en endnu uløst sårbarhed.

Kanal	God når	Kontrollér
Funktionspostkasse	I har en lille organisation og vil have en enkel indgang.	Flere ansvarlige, MFA, spamkontrol, fraværsdækning og sikker opbevaring.
Sikker webformular	I vil strukturere aktiv, trin, påvirkning og kontaktdata.	Adgang til svar, filhåndtering, rate limiting og at data ikke havner i almindelig supportanalyse.
GitHub privat rapportering	Et offentligt repository har funktionen aktiveret.	Notifikationer og ejerskab. En SECURITY.md-fil aktiverer ikke funktionen i sig selv.

Bed om en kort beskrivelse, berørt URL eller funktion, trin til at genskabe fejlen, forventet påvirkning og relevante beviser uden unødige persondata. Lov kun en svartid eller belønning, hvis I realistisk kan overholde den. En kontaktvej er ikke automatisk et bug bounty-program.

Udgiv security.txt korrekt

RFC 9116 placerer filen på domænets kendte sti og kræver mindst ét Contact-felt samt præcis ét Expires-felt. Filen skal hentes over HTTPS og serveres som UTF-8-tekst. Canonical, Policy og Preferred-Languagesgør adressen og forventningerne tydeligere.

Eksempel — erstat domæne, kontakt og dato:

Contact: mailto:security@example.dk
Expires: YYYY-MM-DDTHH:MM:SSZ
Preferred-Languages: da, en
Canonical: https://example.dk/.well-known/security.txt
Policy: https://example.dk/sikkerhedsrapportering

Sæt en rigtig udløbsdato: Brug RFC 3339-format. RFC’en anbefaler mindre end ét år frem for at begrænse risikoen for gamle kontaktoplysninger.
Beskriv scope på policy-siden: Fortæl hvilke domæner og produkter der er omfattet, hvordan der rapporteres privat, og hvilken adfærd der kan skade data eller drift.
Dæk hvert relevant domæne: Filen gælder domænet eller IP-adressen, den hentes fra — ikke automatisk underdomæner eller andre domæner.
Overvåg filen: Test jævnligt statuskode, indholdstype, kontaktlink, policy-link og udløbsdato. En gammel eller kapret fil kan sende rapporter forkert.

Forbind websted, kode og ansvar

De tre dele har forskellige roller. security.txt gør kontaktvejen synlig på det kørende domæne. En offentlig policy forklarer scope og forventninger. EnSECURITY.md i repositoryet hjælper mennesker, der møder projektet gennem koden. De bør pege på samme aktive rapporteringskanal, men ingen af dem bør afsløre interne systemdetaljer eller en konkret uløst fejl.

1. Navngiv ejeren. Aftal primær og stedfortræder samt hvor sagen registreres med begrænset adgang.
2. Skriv den korte policy. Angiv scope, privat kanal, ønskede oplysninger, sikker testadfærd og en realistisk forventning til første svar.
3. Udgiv og forbind. Læg security.txt på hvert relevant domæne og link til policyen. Tilføj SECURITY.md, hvis repositoryets brugere også skal kunne finde vej.
4. Test som en fremmed. Åbn filen uden login, følg kontaktvejen og send en ufarlig prøverapport. Bekræft at den lander hos de ansvarlige.

Håndtér rapporten som ubetroet, følsomt input

En rapport kan være værdifuld, forkert eller ondsindet. Links, vedhæftninger og eksempeldata skal derfor behandles som ubetroede, mens selve sagen holdes privat. Genskab ikke et destruktivt eksempel direkte i produktion, og del ikke kundedata videre for at få hjælp.

Modtag og afgræns

Kvittér, opret en begrænset sag, registrér berørt aktiv og undgå at love alvor eller løsning, før fundet er undersøgt.

Genskab sikkert

Brug et isoleret miljø og kontrollerede testdata. Indsaml kun de logs og beviser, der er nødvendige for at forstå fejlen.

Begræns og ret årsagen

Hvis data eller drift kan være påvirket, aktivér beredskabet. Tilføj en regressionstest og gennemgå lignende kodeveje.

Svar og afslut

Hold rapportøren orienteret, få rettelsen verificeret, dokumentér beslutninger og aftal eventuel offentliggørelse uden at afsløre en åben sårbarhed.

Typiske fejl

Kontaktadressen findes, men ingen følger den: En teknisk korrekt fil bliver en falsk tryghed, hvis beskeder ikke opdages under ferie eller fratrædelse.
Expires er glemt eller gammel: RFC-formatet kræver feltet, og forældede data bør ikke bruges.
Filen lægges kun i roden: Den autoritative webplacering er /.well-known/security.txt; rodstien er kun til ældre kompatibilitet.
Alle underdomæner antages dækket: En fil på hoveddomænet gælder ikke automatisk app-, kunde- eller API-underdomæner.
Et fund bliver et offentligt support-ticket: Adgang, screenshots og notifikationer kan sprede detaljer, før rettelsen er klar.
Rapportøren får tavshed: Uklare forventninger og manglende status øger risikoen for, at fundet går tabt eller offentliggøres uden koordinering.

Tjekliste før kanalen annonceres

☐ Rapporter lander privat hos en navngiven ejer og en stedfortræder.
☐ Kontaktvejen bruger virksomhedskonti med passende adgang og MFA.
☐ Policyen beskriver scope, ønskede oplysninger, sikker testadfærd og realistisk svartid.
☐ security.txt ligger på /.well-known/security.txt over HTTPS som UTF-8-tekst.
☐ Contact og Expires er gyldige; Canonical, Policy og sprog er vurderet.
☐ Relevante domæner og underdomæner er kontrolleret hver for sig.
☐ Links, statuskode, indholdstype og udløbsdato overvåges.
☐ Teamet ved, hvordan en rapport registreres, genskabes sikkert og eskaleres.
☐ En ufarlig prøverapport er gennemført fra afsender til afslutning.

Relaterede guides

Officielle kilder

Formatkrav og platformfunktioner er kontrolleret mod aktuelle primærkilder. Tilpas rapporteringskanal, scope og beredskab til den app og organisation, I faktisk driver.

Er appen i brug, men sikkerhedsansvaret stadig uformelt?

Startklar kan bruges til at gennemgå jeres konkrete app, samle de vigtigste sikkerheds- og driftsopgaver og få rapporteringsvejen til at passe sammen med den teknologi og organisation, I allerede har.

Se Startklar-forløbet