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.
I denna artikel
- Sammanfattning
- Vad är security.txt?
- Den minimalt fungerande security.txt
- Den rekommenderade security.txt
- Fält för fält
- Steg-för-steg-konfiguration
- För produkter utan webbgränssnitt
- Vanliga misstag
- Valideringschecklista
- Underhållsschema
- Vad som ingår i er tekniska fil
- Komplett exempel
- Vanliga frågor
- Hur CRA Evidence hjälper
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.txtpå 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 på CVD-policy
HOSTING:
[ ] Filen på /.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.
Relaterade artiklar
CRA för tyska tillverkare: BSI, CERT-Bund och CE-märkning
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.