security.txt (RFC 9116): obligatoriska fält och exempel

Konfigurera security.txt på /.well-known/security.txt: Contact, Expires, ett färdigt exempel och kopplingen till CRA:s tekniska dokumentation.

CRA Evidence Team Publicerad 6 februari 2026 Uppdaterad 6 april 2026
security.txt (RFC 9116): obligatoriska fält och exempel
I denna artikel

Under CRA behöver tillverkare ett offentligt tillgängligt sätt för forskare och kunder att rapportera sårbarheter. Standarden är RFC 9116, en ren textfil kallad security.txt som hostas på /.well-known/security.txt. Två obligatoriska fält, ett par rekommenderade, och ungefär 10 minuters arbete.

Den här guiden täcker fälten, hostingen, de vanliga misstagen och vad du behöver referera till i din tekniska fil.

Sammanfattning

  • security.txt är en standardiserad fil (RFC 9116) som talar om för forskare hur de ska rapportera sårbarheter
  • Placera den på /.well-known/security.txt på din webbplats
  • Obligatoriska fält som minimum: Contact, Expires
  • Rekommenderat: Inkludera även Preferred-Languages, Policy, Canonical
  • För produkter utan webbgränssnitt, inkludera URL:en i dokumentationen

Vad är security.txt?

security.txt är en RFC-standard (RFC 9116) som ger ett maskinläsbart och mänskligt läsbart sätt att publicera säkerhetskontaktuppgifter.

CRA kräver att tillverkare publicerar en kontaktadress för sårbarhetrapportering. security.txt är branschstandarden för att göra det. Automatiserade skanningsverktyg och säkerhetsforskare söker efter den som standard, och att ha den på plats ger tillsynsmyndigheter ett konkret tecken på att du har satt upp ordentliga kanaler för ansvarsfull avslöjande.

Den minimalt fungerande security.txt

Här är den enklaste kompatibla filen:

Contact: mailto:security@yourcompany.com
Expires: 2027-12-31T23:59:59.000Z

Det är allt. Två rader. Du är tekniskt sett kompatibel.

Men låt oss göra det bättre.

Den rekommenderade security.txt

En komplett security.txt:

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://yourcompany.com/.well-known/pgp-key.txt
Preferred-Languages: en, de, fr
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/disclosure-policy
Hiring: https://yourcompany.com/careers/security
Acknowledgments: https://yourcompany.com/security/thanks

Fält för fält

Contact (obligatoriskt)

Hur forskare ska nå er.

Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report

Använd ett teamalias, inte en personlig e-postadress. Inkludera både en e-postadress och ett webbformulär om ni har ett. Flera Contact-rader är tillåtna, och formuläret ger er strukturerad insamling.

Expires (obligatoriskt)

Expires: 2027-01-01T00:00:00.000Z

Sätt det 6-12 månader framåt i ISO 8601-format med tidszon. Sätt en kalenderpåminnelse innan det löper ut. En inaktuell fil signalerar till forskare att ni inte underhåller den.

Encryption (rekommenderat)

Encryption: https://yourcompany.com/.well-known/pgp-key.txt

Använd en teamnyckel snarare än en individnyckel, och förvara den privata nyckeln i en HSM om möjligt. Inkludera fingeravtrycket i kommentarerna så att forskare kan verifiera det utanför bandet.

Preferred-Languages (rekommenderat)

Preferred-Languages: en, de, fr

Lista bara de språk som ert säkerhetsteam faktiskt kan svara på. Ordna efter preferens. Om ni listar tyska men ingen i teamet läser tyska, kommer ni att få rapporter som ni inte kan hantera.

Canonical (rekommenderat)

Canonical: https://yourcompany.com/.well-known/security.txt

Förhindrar förfalskning och klargör om filen speglas. Forskare kan verifiera den kanoniska URL:en mot det de hämtade för att bekräfta äktheten.

Policy (rekommenderat)

Policy: https://yourcompany.com/security/disclosure-policy

Se till att sidan finns och laddas utan autentisering. En trasig Policy-länk under en säkerhetsgranskning ger ett dåligt intryck.

Acknowledgments (valfritt)

Acknowledgments: https://yourcompany.com/security/thanks

Forskare som hittar buggar är ofta bra kandidater till ert säkerhetsteam. Erkännande uppmuntrar också fler rapporter. De flesta forskare prioriterar organisationer som uppmärksammar deras arbete.

Hiring (valfritt)

Hiring: https://yourcompany.com/careers/security

Värt att inkludera om ni har öppna säkerhetsroller. Forskare som aktivt söker arbete kollar dessa länkar.

Steg-för-steg-konfiguration

Steg 1: Skapa filen

cat > security.txt << 'EOF'
Contact: mailto:security@yourcompany.com
Contact: https://yourcompany.com/security/report
Expires: 2027-01-15T00:00:00.000Z
Preferred-Languages: en
Canonical: https://yourcompany.com/.well-known/security.txt
Policy: https://yourcompany.com/security/policy
EOF

Steg 2: Välj hostingplats

https://yourcompany.com/.well-known/security.txt
https://192.168.1.1/.well-known/security.txt

Steg 3: Konfigurera er webbserver

Nginx:

location /.well-known/security.txt {
    alias /var/www/security.txt;
    default_type text/plain;
}

Apache:

Alias /.well-known/security.txt /var/www/security.txt
<Files "security.txt">
    ForceType text/plain
</Files>

Express.js:

app.get('/.well-known/security.txt', (req, res) => {
    res.type('text/plain');
    res.sendFile(__dirname + '/security.txt');
});

Statisk hosting: Placera bara filen i katalogen .well-known.

Steg 4: Verifiera

curl https://yourcompany.com/.well-known/security.txt

Onlinevalidator: https://securitytxt.org/

Steg 5: Signera (valfritt men rekommenderat)

gpg --clearsign security.txt
mv security.txt.asc security.txt

För produkter utan webbgränssnitt

Inbyggda enheter

Alternativ 1: Hosta på http://device-ip/.well-known/security.txt Alternativ 2: Inkludera URL:en i produktdokumentationen, referera till företagets security.txt.

Skrivbordsprogram

  • Inkludera säkerhetskontakt under Hjälp > Om
  • Lägg till i README/dokumentationen

Mobilappar

  • Inkludera i appens Inställningar > Om > Säkerhet
  • Lägg till i appbutiksbeskrivningen

Referens i dokumentation

## Rapportering av säkerhetsbrister
- E-post: security@yourcompany.com
- Webb: https://yourcompany.com/security/report
- Policy: https://yourcompany.com/security/policy
Vår security.txt-fil: https://yourcompany.com/.well-known/security.txt

Vanliga misstag

Utgången fil

Expires: 2024-01-01T00:00:00.000Z  # UTGÅNGEN!

Lösning: Sätt ett framtida datum. Lägg till en kalenderpåminnelse.

Fel plats

/security.txt           # Fel
/.well-known/security.txt  # Rätt

Ogiltigt format

Lösning: Använd ISO 8601-datum, mailto:- eller https:-URI:er.

Trasiga länkar

Lösning: Verifiera att alla länkar fungerar. Kontrollera efter driftsättningar.

Personlig e-postadress

Contact: mailto:john.smith@yourcompany.com  # Fel

Lösning: Använd ett teamalias.

Ingen HTTPS

Lösning: Använd alltid HTTPS för säkerhetsrelaterade URL:er.

Valideringschecklista

VALIDERINGSCHECKLISTA FÖR SECURITY.TXT

OBLIGATORISKA FÄLT:
[ ] Contact-fält finns (mailto: eller https:)
[ ] Expires-fält finns (framtida datum, ISO 8601)

REKOMMENDERADE FÄLT:
[ ] Preferred-Languages inkluderat
[ ] Canonical URL matchar faktisk plats
[ ] Policy-länk fungerar och pekar  CVD-policy

HOSTING:
[ ] Filen  /.well-known/security.txt
[ ] Tillgänglig via HTTPS
[ ] Content-Type: text/plain

VERIFIERING:
[ ] curl-test lyckat
[ ] Onlinevalidator godkänner
[ ] Alla länkar löser (inga 404:or)

UNDERHÅLL:
[ ] Kalenderpåminnelse satt inför Expires-datumet
[ ] Uppdateringsprocess dokumenterad

Underhållsschema

Uppgift Frekvens
Kontrollera utgångsdatum Månadsvis
Verifiera att länkar fungerar Månadsvis
Uppdatera PGP-nyckel (om den löper ut) Vid behov
Granska kontaktadresser Kvartalsvis
Fullständig valideringskontroll Inför utgång

Vad som ingår i er tekniska fil

CRA kräver att tillverkare upprätthåller en teknisk fil (Annex VII) som dokumenterar deras process för hantering av sårbarheter. Er security.txt-fil och den CVD-policy den refererar till är direkta indata till den dokumentationen.

Specifikt bör er tekniska fil referera till:

  • Security.txt-URL:en och vilka kontaktmetoder den exponerar
  • URL:en till den avslöjandepolicy den länkar till
  • De svarstider ni har åtagit er i den policyn

Tillsynsmyndigheter som granskar er tekniska fil letar efter bevis på att en fungerande process för sårbarhetsintagning finns. En aktiv, icke-utgången security.txt med en fungerande Policy-länk är ett konkret tecken. En utgången fil eller trasiga länkar talar mot er.

Kontaktpunkter för sårbarhetrapportering:
- security.txt: https://company.com/.well-known/security.txt
- E-post: security@company.com
- Webbformulär: https://company.com/security/report
- Policy: https://company.com/security/policy

Komplett exempel

Contact: https://acmetech.eu/security/report
Contact: mailto:security@acmetech.eu
Expires: 2027-06-01T00:00:00.000Z
Preferred-Languages: en, de, es
Canonical: https://acmetech.eu/.well-known/security.txt
Policy: https://acmetech.eu/security/disclosure-policy
Acknowledgments: https://acmetech.eu/security/hall-of-fame
Hiring: https://acmetech.eu/careers#security

Tips: Att konfigurera security.txt tar 10 minuter och uppfyller ett viktigt CRA-krav för publicerad sårbarhetskontakt. Gör det idag.

Viktigt: Er security.txt måste innehålla en kontaktmetod, ett föredraget språk och ett utgångsdatum. Den ska ligga på /.well-known/security.txt på er domän.

Vanliga frågor

Vilka fält är obligatoriska i en security.txt-fil?

RFC 9116 gör bara två fält obligatoriska: Contact och Expires. Alla andra fält, däribland Canonical, Encryption, Preferred-Languages, Policy och Acknowledgments, är rekommenderade eller frivilliga. En fil med en enda Contact-rad och ett framtida Expires-datum är giltig, men det tillsynsmyndigheterna faktiskt letar efter är att den kombineras med en fungerande process för sårbarhetshantering.

Vilket format ska Expires-fältet ha?

Expires tar en enda tidsstämpel i ISO 8601-format med tidszon, till exempel 2027-01-01T00:00:00.000Z. Datumet måste ligga i framtiden, och RFC 9116 rekommenderar att du sätter det till mindre än ett år framåt så att filen inte ser övergiven ut. Bara en Expires-rad är tillåten, och ett datum som redan passerat gör hela filen ogiltig för de flesta parsrar.

Vad gör Canonical-fältet, och är det obligatoriskt?

Canonical är frivilligt. Det anger filens auktoritativa URI, vilket låter en forskare bekräfta att hen läser den äkta security.txt och inte en kopia som ligger någon annanstans. Sätt det till den exakta platsen https://dindomän/.well-known/security.txt, och håll det på HTTPS så att länken inte kan manipuleras på vägen.

Hur stavas Acknowledgments-fältet i RFC 9116?

RFC 9116 stavar fältet Acknowledgments, den amerikanska formen utan ”e” före ”-ments”. Det är ett frivilligt fält som länkar till sidan där du tackar de forskare som har rapporterat brister, ofta en så kallad security hall of fame. Det uppmuntrar ansvarsfull rapportering, men det påverkar inte om filen är giltig eller inte.

Var ska security.txt-filen ligga?

Filen måste ligga på /.well-known/security.txt, serverad över HTTPS som text/plain utan autentisering. När en skanner rapporterar att security.txt saknas betyder det att den inte finns, ligger bakom en inloggning eller ligger på fel plats, till exempel /security.txt i sajtens rot. Har du en produkt utan webbplats, hänvisa i stället till företagets fil från produktdokumentationen.

Kräver CRA egentligen en security.txt-fil?

CRA nämner inte security.txt, men kontakten bakom den är ett krav. Tillverkare måste uppge en kontaktadress för att rapportera sårbarheter, och användarna ska ha en enda kontaktpunkt. security.txt är standardsättet att publicera den kontakten, och den tekniska dokumentationen förväntas innehålla bevis på att kontakten finns. Se samordnad sårbarhetsredovisning för hur det passar in i den bredare skyldigheten. (Bilaga I, del II punkt 6. Artikel 13.17. Bevis enligt bilaga VII punkt 2 b.)

Hur CRA Evidence hjälper

security.txt är en del av sårbarhetshanterings-bilden. Den svårare delen är hela processen bakom den: policy, SLA:er för triage, ENISA-rapportering och att dokumentera allt i er tekniska fil. Det är vad CRA Evidence är till för.

Kom igång på craevidence.com.


Den här artikeln är endast i informationssyfte och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, konsultera kvalificerad juridisk rådgivning.

CRA Sårbarhetshantering Säkerhetsstandarder
Share

Gäller CRA för din produkt?

Svara på 6 enkla frågor för att ta reda på om din produkt omfattas av EU:s Cyber Resilience Act. Få ditt resultat på under 2 minuter.

Redo att uppnå CRA-efterlevnad?

Börja hantera dina SBOM:ar och efterlevnadsdokumentation med CRA Evidence.