Since the vendors are in complete control over the security.txt, it'd be good to give some leverage to the hackers. There have been instances in the past where the vendor changed the rules of engagement after the hacker submitted a security vulnerability. To avoid discussion around the rules that applied when the hacker submitted the vulnerability, it'd be good to have some form of versioning in the file itself. This might not be trivial to implement in the file itself because the company is in complete control of the file contents.
One of the ideas could be that a third party introduces a service to cache the current version of a security.txt file. The way it could work is that the service downloads the security.txt file and returns a unique URL that proofs the file contents were on the site at one point. This should be accompanied with a timestamp and could be accompanied with a hash.
Since the vendors are in complete control over the security.txt, it'd be good to give some leverage to the hackers. There have been instances in the past where the vendor changed the rules of engagement after the hacker submitted a security vulnerability. To avoid discussion around the rules that applied when the hacker submitted the vulnerability, it'd be good to have some form of versioning in the file itself. This might not be trivial to implement in the file itself because the company is in complete control of the file contents.
One of the ideas could be that a third party introduces a service to cache the current version of a security.txt file. The way it could work is that the service downloads the security.txt file and returns a unique URL that proofs the file contents were on the site at one point. This should be accompanied with a timestamp and could be accompanied with a hash.