nightwatchcyber
commented
3 years ago This is probably going to be deferred after the initial draft is approved. But I am wondering, in any case, perhaps the current "Contact" field can mean "any", and we can define a more narrow set of fields for specific use-case like:
`Contact-CERT:
Contact-PSIRT:`
tschmidtb51
Is your feature request related to a problem? Please describe. The "security.txt" aims to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. In section 3.1 it states that "[it] MAY also apply to products and services provided by the organization publishing the file." Products are usually dealt with at Product-CERT / Product Security Incident Response Team (PSIRT). Infrastructure vulnerabilities are usually CERT business.
Many SME can effort to hire security experts. Therefore, they use service providers. As the IT is usually outsource the CERT function is outsourced as well. The product related vulnerability handling might be done in the development department or also by an external party. Since security experts are expensive, we see PSIRT service providers (e.g. non-profit PSIRTs at industry associations like https://cert.vde.com/) becoming more popular.
The "security.txt" of Company X might now look like:
A security researcher has now the problem of identifying which contact to use.
Describe the solution you'd like The standard should introduce mandatory categories (ALL, CERT, PSIRT) for the
Contactfield.Example:
Describe alternatives you've considered
Additional context None.