You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Keep the current state. This makes it harder for security researcher to find the right contact and might disclose vulnerabilities to the wrong parties.
The information could be provided by giving comments. However, a comment (if not explicitly specified in the standard) might be machine-parsable but can't be automated since it will be different for each instance.
The categories could have different names, e.g. "any", "infastructure", "products", "services". I'm open to that. However, it requires a definition of the different terms which I can't provide at the moment.
Additional context
None.
The text was updated successfully, but these errors were encountered:
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:
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
Contact
field.Example:
Describe alternatives you've considered
Additional context
None.
The text was updated successfully, but these errors were encountered: