Finding vulnerabilities in modern applications is getting harder and harder as security is slowly being brought to the forefront of conversation. Unfortunately, reporting the vulnerabilities that are found to the appropriate personnel can sometimes be even more challenging.

However, this issue may become less prevalent as recently, security researchers Ed Foudil (aka. EdOverflow) and Yakov Shafranovich managed to convert their draft submission to the Internet Engineering Task Force into an official RFC document. Contained within their proposal was a standardised approach to conducting vulnerability disclosure between a security researcher and an organisation, in the form of a security.txt file.

What is a security.txt file?

The security.txt file provides a security researcher the appropriate contact information should a vulnerability be found within your site. The RFC suggests placing this file within the /.well-known/ folder of your application i.e.

https://yourdomain.com.au/.well-known/security.txt

However this can be placed within the web root if required.

https://yourdomain.com.au/security.txt

What organisational information do I include?

A good example of what to add can be seen below:

While the example above doesn't comply with the standard to the letter, the key information is being displayed, that being:

  • Contact Information - Provide an appropriate email address / phone number for the security researcher to contact with their findings.
  • Encryption Key - Provide a link to your public key that researchers can use to communicate with you securely.
  • Non-Vulnerability List - While this field isn't in direct compliance with the standard, it does give researchers strict guidance on what they should NOT report to your organisation.

In addition, this organisation has digitally signed their file with an OpenPGP cleartext signature. This provides confidence to the researcher that the security.txt file they are looking at is legitimate which can be validated if necessary, and has not been tampered with by an attacker. For more information on the specific requirements, please refer to the RFC.

How do I create a security.txt file?

To create one for your organisation, it's as simple as going to the following link, inputting the relevant details, and adding it to your externally facing applications.

Has this been widely adopted in Australia?

While several of the Fortune 100 companies had implemented the security.txt file before it had even become a recognised standard, Australian companies weren't as quick to jump on the bandwagon.

Conducting a quick Google search I compared my two search results.

The first was to determine how many Australian Government organisations had implemented the standard:

The second was to determine how many Australian Industry organisations had implemented the standard:

While this isn't the most accurate way of determining adoption rates, it was interesting to see. I figured Government would have had a higher number. In saying that, I know Government organisations that have a dedicated vulnerability disclosure page that have not implemented the security.txt file, so it's hard to gauge any real meaning from my generic searches other than, the numbers are low across the board.

The standard is still in its infancy though, so I'm sure we'll see a wider adoption in due time.

I've received several questions regarding this RFC, so I thought I'd try and clear up a few misconceptions surrounding it:

"If I deploy this file to my internet facing web applications, am I giving permission for researchers to conduct active testing against them?"

Absolutely not. Unless your organisation participates in a Bug Bounty Program, or a Vulnerability Disclosure Program that specifically states researchers are permitted to conduct testing against your applications, then it is still unlawful to do so without prior consent. This is designed to simplify the disclosure process for glaringly obvious security issues while interacting with your application.

"Does displaying this file increase the overall attack surface available to cyber adversaries?"

One could argue that adding an organisational email address or phone number to a well known location increases your attack surface. However, I'm not one of those people. It's negligible at best, and the reward greatly exceeds the risk. The biggest issue Ed himself has acknowledged is the amount of junk emails that are likely to occur because of it. These would be received from both automated bots, and sub-par, manual reporting of scan tool results. However, with properly tuned email filters, a dedicated security email inbox (i.e. vulnerabilities@your-org.com.au) and specifying what your organisation doesn't deem a vulnerability, these issues can be reduced.

"Does this provide any added benefit to my organisation?"

The primary business benefit is that it spells out clear instructions for a security researcher who has found an issue, to get it to the correct personnel within your organisation and triaged ASAP. As a by-product, the file shows that your organisation cares about the security of its applications and of the people that use them. Furthermore, it provides a level of comfort to the researcher reporting the issue. There have been a few times where I've questioned whether or not I should actually report an issue through fear of legal action. This is a common story amongst vulnerability researchers.

I understand that to some, this text file might seem a little underwhelming. But for those of us who have spent hours scouring the internet looking for a security email address or phone number to report a critical issue to, only to end up emailing the sales team, I can assure you, this is an achievement to be celebrated.

So much so that in March of this year, the Australian Cyber Security Centre deemed it important enough to add a security control in Australia's InfoSec Bible (aka. the Information Security Manual) that specifically mentions the security.txt file.

Congratulations to Ed, Yakov and all involved for their achievements. Especially for influencing Australian Government policy on responsible disclosure.