> The aim is that, for example, ethical hackers can immediately contact the right person or department to tackle the vulnerability.<p>We added such a file years ago. There's still some security researchers ("bug hunters") not aware of the standard and email other email addresses (info@, invoice@, data-protection@). Nobody has ever used the GPG key we list in the security.txt file. The email address we list (security@) hasn't received any significant spam.
To get an idea of how well our government organisations get along with implementing this (and a lot of other basic security requirements, like TLS, IPv6, DNSSEC, etc) you can view these maps[0][1].<p>We maintain a set of open source tools to easily get you started[2]. If you would like help to have this for your country/government/organisation as well, feel free to contact us.<p>[0] <a href="https://basisbeveiliging.nl/#/metric-progress/NL/municipality/internet_nl_wsm_web_appsecpriv_securitytxt" rel="nofollow">https://basisbeveiliging.nl/#/metric-progress/NL/municipalit...</a>
[1] <a href="https://basisbeveiliging.nl/#/maps" rel="nofollow">https://basisbeveiliging.nl/#/maps</a>
[2] <a href="https://gitlab.com/internet-cleanup-foundation/web-security-map" rel="nofollow">https://gitlab.com/internet-cleanup-foundation/web-security-...</a>
This has been discussed to death every time security.txt comes up, but in my experience it's been a great way to receive spam about bullshit "vulnerabilities" from low effort scanners operated by "security researchers".<p>Much like how people publish email addresses online using human readable replacements (e.g. AT instead of @) to avoid spam, I'd rather put up a contact page that's easy for humans to find but nontrivial to automate.
<p><pre><code> 2.5.6. Hiring
The "Hiring" field is used for linking to the vendor's security-related job positions. If this field indicates a web URI, then it MUST begin with "https://" (as per Section 2.7.2 of [RFC7230]).
</code></pre>
Hey, I just found a new way to job hunt!
Keep in mind this is only mandatory <i>for government websites</i>. That's a pretty low bar. If I worked for the government, or even a company that had one clear way to contact security, I would love this. I honestly have no fucking idea how to directly contact security most of the time and that's insane because I actually want to help them.<p>I don't care if they receive spam, I just want them to tell me how to contact them. Give me a captcha form, a phone number, an AOL Instant Messenger handle, I don't care.
"Dutch government websites must comply with the security.txt standard from 25 May. This is announced by the Digital Trust Center of the National Government."<p>Somewhat ironically:<p><a href="https://www.digitaltrustcenter.nl/security.txt" rel="nofollow">https://www.digitaltrustcenter.nl/security.txt</a><p>The website of the Digital Trust Center returns 404
I’m working on a simple website generator for developers and content creators.<p>I’ve already included everything a user would want for a complete website, including a robots.txt, sitemaps, perfect Lighthouse seo score, rich snippets, and a ton of other stuff.<p>Should I consider adding an auto generated security.txt file along side the robots.txt file for users?<p>Do you’all think a security.txt file is something users would want in 2023? Or would it look stupid and confusing?<p><a href="https://github.com/elegantframework/elegant-cli">https://github.com/elegantframework/elegant-cli</a>
Never heard about security txt files until now, but it makes a lot of sense!<p>Regulations are a hit or miss (e.g the cookie notification rules have some good parts but I wonder if there isn't any room for improvement in the current "visiting a website for 10 seconds and clicking whatever the big button is so that I see the content in interested in" status quo.<p>This one is not obtrusive, easy to implement (though only developers care about this part) and solves the problem.
I checked the top 20 most used websites in Germany (with .de), and number 20 on the list is the first to have it:
<a href="https://www.focus.de/security.txt" rel="nofollow">https://www.focus.de/security.txt</a><p>Most used webpages:
<a href="https://www.similarweb.com/top-websites/germany/" rel="nofollow">https://www.similarweb.com/top-websites/germany/</a>
I've just checked the UK's GDS advice and they have it as a "should": <a href="https://gds-way.cloudapps.digital/manuals/security-overview-for-websites.html#10-implement-security-txt" rel="nofollow">https://gds-way.cloudapps.digital/manuals/security-overview-...</a><p>They have more information at <a href="https://gds-way.cloudapps.digital/standards/vulnerability-disclosure.html" rel="nofollow">https://gds-way.cloudapps.digital/standards/vulnerability-di...</a> where they strengthen the advice by saving:<p><pre><code> As per the current policy, we only accept reports from services that have a security.txt file pointing to the security policy.</code></pre>
The formal news release on this from the Dutch Standardization Forum can be found here: <a href="https://forumstandaardisatie.nl/nieuws/securitytxt-mandatory-dutch-government" rel="nofollow">https://forumstandaardisatie.nl/nieuws/securitytxt-mandatory...</a><p>Note that you can test if a website has valid security.txt with the Internet.nl test tool: <a href="https://en.internet.nl/article/securitytxt-test-toegevoegd/" rel="nofollow">https://en.internet.nl/article/securitytxt-test-toegevoegd/</a>
This is a win for GPG. Some, like the current PyPI maintainers, want to throw it out with no replacement. That's a terrible idea. And I don't see why it needs to be replaced completely.
<a href="https://www.amsterdam.nl/security.txt" rel="nofollow">https://www.amsterdam.nl/security.txt</a> returns<p>---<p>Contact: <a href="https://www.amsterdam.nl/privacy/informatiebeveiliging-gemeente-amsterdam/" rel="nofollow">https://www.amsterdam.nl/privacy/informatiebeveiliging-gemee...</a><p>Expires: 2024-02-01T10:00:00.000Z<p>Acknowledgments: <a href="https://www.informatiebeveiligingsdienst.nl/?s=hall+of+fame" rel="nofollow">https://www.informatiebeveiligingsdienst.nl/?s=hall+of+fame</a><p>Preferred-Languages: en,nl<p>---<p>rfc9116<p>2.5.1. Acknowledgments<p>The "Acknowledgments" field indicates a link to a page where security researchers are recognized for their reports. The page being referenced should list security researchers that reported security vulnerabilities and collaborated to remediate them. Organizations should be careful to limit the vulnerability information being published in order to prevent future attacks.<p>If this field indicates a web URI, then it MUST begin with "<a href="https://" rel="nofollow">https://</a>" (as per Section 2.7.2 of [RFC7230]).
Really appreciated this article - it's high time the Dutch government websites took steps like these towards strengthening their security! Still, they could definitely do with a bit more user-friendly explanations, so everyone can understand the importance of initiatives like security.txt.
<a href="https://mijn.overheid.nl/security.txt" rel="nofollow">https://mijn.overheid.nl/security.txt</a><p>404<p>but this one does exist
<a href="https://www.ncsc.nl/.well-known/security.txt" rel="nofollow">https://www.ncsc.nl/.well-known/security.txt</a>
Unless there's a way to mandate that the security team's contacts listed in security.txt actually respond in a timely manner to security-related messages that are sent to them, then I have a nagging feeling that:<p>* well-run organizations won't benefit from doing this, since their security teams were already easy to reach<p>and<p>* poorly-run organizations won't become any better <i>by</i> doing this, because one text file doesn't fix a broken org