Security.txt

Security.txt is een gestandaardiseerd tekstbestand dat organisaties op hun website plaatsen om beveiligingsonderzoekers te informeren over het meldproces voor kwetsbaarheden. Het bestand is vastgelegd in RFC 9116, een internetstandaard van de IETF, en biedt een machineleesbaar formaat waarin contactgegevens, het beveiligingsbeleid en de verwachte responstijd worden gecommuniceerd. Vergelijk het met een robots.txt voor zoekmachines, maar dan specifiek voor security-onderzoekers. Zonder security.txt weten onderzoekers die een kwetsbaarheid vinden vaak niet bij wie ze terecht kunnen, waardoor meldingen verloren gaan, via onveilige kanalen worden gedeeld of in het ergste geval publiek worden gemaakt. Ondanks het belang van het bestand heeft slechts 1,25 procent van de top een miljoen websites een security.txt geimplementeerd. Het Amerikaanse CISA beschouwt security.txt als een eenvoudige maar waardevolle stap richting een volwassen vulnerability disclosure-proces.

Hoe werkt security.txt? Stappen

Het implementeren van security.txt is een eenvoudig proces in vier stappen. Eerst maak je het tekstbestand aan met de vereiste velden. Het bestand bevat minimaal twee verplichte velden: Contact (hoe onderzoekers je kunnen bereiken, bijvoorbeeld een e-mailadres of URL naar een meldformulier) en Expires (wanneer de informatie verloopt, in ISO 8601-formaat). Optionele maar aanbevolen velden zijn Encryption (link naar je PGP-sleutel voor versleutelde communicatie), Policy (link naar je responsible disclosure-beleid), Acknowledgments (pagina met erkenning van eerdere melders), Preferred-Languages (talen waarin je meldingen accepteert) en Canonical (de officieel URL van het bestand om manipulatie te detecteren).

In de tweede stap plaats je het bestand op de juiste locatie op je webserver. De aanbevolen plek volgens RFC 9116 is /.well-known/security.txt, de alternatieve locatie is de root directory /security.txt. Het bestand moet toegankelijk zijn via HTTPS en in platte tekst worden geserveerd met het Content-Type text/plain. De meeste webservers ondersteunen dit zonder aanpassingen aan de configuratie. Bij WordPress, Nginx of Apache is het plaatsen van het bestand een kwestie van minuten.

Vervolgens stel je een intern proces in voor het afhandelen van meldingen. Wie ontvangt de meldingen, wat is de verwachte responstijd en hoe wordt een gemelde kwetsbaarheid getriaged en opgelost? Zorg dat het e-mailadres of de URL in het Contact-veld wordt gemonitord door je securityteam of IT-afdeling. Een melding die dagenlang ongelezen blijft, ondermijnt het vertrouwen van onderzoekers en kan ertoe leiden dat ze de kwetsbaarheid publiekelijk delen. Stel een SLA in van maximaal 48 uur voor een eerste reactie.

Tot slot onderhoud je het bestand actief als onderdeel van je reguliere IT-onderhoud. Werk het Expires-veld bij voordat het verloopt en pas contactgegevens aan bij personeelswisselingen of organisatieveranderingen. Uit recent onderzoek blijkt dat 45 procent van de websites met een security.txt geen vervaldatum heeft, en 13 procent een reeds verlopen datum toont. Dit geeft onderzoekers het signaal dat de organisatie het bestand niet actief onderhoudt en meldingen mogelijk niet serieus neemt.

Wanneer voer je security.txt uit?

Elke organisatie met een website zou een security.txt moeten hebben, ongeacht grootte of sector. Het bestand is bijzonder relevant als je digitale diensten aanbiedt, klantgegevens verwerkt, een webapplicatie beheert die via internet bereikbaar is, of API's aanbiedt aan derden. Voor organisaties die onder NIS2 vallen, is het een praktische en concrete invulling van de eis om een proces voor kwetsbaarhedenmelding in te richten.

De Nederlandse overheid heeft via het NCSC een coordinated vulnerability disclosure (CVD) beleid opgesteld en moedigt alle organisaties aan om meldprocedures transparant te communiceren. Een security.txt maakt je vindbaar voor ethische hackers en beveiligingsonderzoekers die kwetsbaarheden verantwoord willen melden in plaats van exploiteren of doorverkopen. Zonder dit bestand is de kans groter dat een ontdekte kwetsbaarheid niet wordt gemeld, via onbeveiligde e-mail wordt gecommuniceerd of, in het slechtste geval, publiek wordt gemaakt zonder dat je de kans hebt gehad het probleem te verhelpen.

Implementeer security.txt direct als je een responsible disclosure-beleid hebt of overweegt. Het bestand is ook waardevol als onderdeel van je security audit-voorbereiding, omdat auditors en certificeringsinstanties steeds vaker kijken naar de aanwezigheid van een vulnerability disclosure-proces als indicator van beveiligingsvolwassenheid. In de praktijk kost de volledige implementatie minder dan een uur werk en levert het direct waarde op als communicatiekanaal met de security-community.

Wat kost security.txt?

De directe kosten van een security.txt zijn nagenoeg nul. Het bestand zelf is een eenvoudig tekstbestand dat je in vijf minuten aanmaakt met een teksteditor. De website securitytxt.org biedt een gratis generator waarmee je het bestand samenstelt door de velden in te vullen en het resultaat te kopieren. Het plaatsen op je webserver vereist alleen FTP- of SSH-toegang, of een aanpassing in je deployment-pipeline of CMS-configuratie.

De indirecte kosten zitten in het opzetten van het achterliggende proces. Je hebt een gemonitord e-mailadres nodig (bijvoorbeeld security@jouwbedrijf.nl), een procedure voor het afhandelen en triagen van meldingen, en bij voorkeur een responsible disclosure-beleid dat de spelregels beschrijft voor zowel de melder als je organisatie. Voor een MKB-bedrijf is dit een eenmalige investering van 4 tot 8 uur. Grotere organisaties die een volwaardig bug bounty-programma willen opzetten investeren meer in platforms als HackerOne of Bugcrowd, maar security.txt zelf is altijd gratis en onafhankelijk van dergelijke platforms.

De besparingen overtreffen de investering ruimschoots. Een kwetsbaarheid die via security.txt wordt gemeld en verholpen voordat een aanvaller deze vindt, kan duizenden tot miljoenen euro's aan schade voorkomen. Een datalek dat had kunnen worden voorkomen door een tijdige melding kost een organisatie gemiddeld 4,5 miljoen euro volgens het IBM Cost of a Data Breach Report. De reputatieschade en het verlies van klantvertrouwen komen daar nog bovenop. Security.txt is daarmee een van de meest kosteneffectieve beveiligingsmaatregelen die je kunt nemen, met een nagenoeg onbestaande investering en een potentieel enorm rendement.

Veelgestelde vragen over security.txt

Is security.txt verplicht?

Security.txt is niet wettelijk verplicht, maar wordt sterk aanbevolen door het NCSC en CISA. Onder NIS2 moeten organisaties een proces hebben voor het ontvangen van kwetsbaarheidsmeldingen. Security.txt is de meest gestandaardiseerde manier om dit te faciliteren.

Waar plaats je security.txt precies?

De aanbevolen locatie is https://jouwdomein.nl/.well-known/security.txt. Alternatief mag het ook op https://jouwdomein.nl/security.txt staan. Het bestand moet via HTTPS bereikbaar zijn en als platte tekst worden geserveerd.

Wat zijn de verplichte velden in security.txt?

Volgens RFC 9116 zijn Contact en Expires verplicht. Contact geeft aan hoe onderzoekers je bereiken via e-mail, URL of telefoon. Expires geeft aan wanneer de informatie verloopt om verouderde contactgegevens te voorkomen.

Maakt security.txt je website kwetsbaar?

Nee. Security.txt bevat alleen contactinformatie en beleidslinks, geen technische details over je infrastructuur. Het maakt het juist makkelijker voor ethische onderzoekers om kwetsbaarheden verantwoord te melden.

Hoe vaak moet je security.txt updaten?

Werk het bestand bij voordat de Expires-datum verloopt, bij wijzigingen in contactpersonen of bij aanpassingen aan je disclosure-beleid. Controleer minimaal elk kwartaal of alle informatie nog actueel is.

Vind een specialist voor vulnerability disclosure via Security Assessments op IBgidsNL.