A File Format to Aid in Security Vulnerability Disclosure – the first step to a proper connection - JPCERT/CC Eyes

Hello. I am Noriko Totsuka from Early Warning Group. The Early Warning Group publishes security information such as security alerts and early warning information, as well as JVN Advisories. As a vulnerability coordinator, I am in charge of a series of coordination tasks, from coordinating with developers of target products, including taking countermeasures based on the vulnerability-related information reported to JPCERT/CC by vulnerability finders such as security researchers, to the publication of JVN Advisories. From a vulnerability coordinator’s perspective, this article introduces RFC 9116: A File Format to Aid in Security Vulnerability Disclosure [1], officially released in April 2022, as one of the measures developer organizations can implement to make it easier for vulnerability coordination agencies and vulnerability finders to work with developers.

In the vulnerability coordination, for which I am responsible, it is important to notify the product developer of the reported vulnerability-related information so that they can check and respond to it. The first task in this process is to make the first contact with the product developer. I need to contact the right person with an appropriately tailored information. It is not enough to just send information. We first need to find the right contacts who can recognize the issue, and we need to make our coordination activities understood. Failure to reach the right contact in vulnerability coordination means that appropriate action will not be taken on the reported information. It is ideal that vulnerability-related information is properly communicated: such information should be properly delivered to product developers, who then take countermeasures, and later an advisory should be published or a report be disclosed by the finder, with the information about the countermeasures. However, if we cannot reach the right person, vulnerability coordination fails from the beginning. In such cases, product users are still at risk of being exposed to the threat of a zero-day attack, and product developers may lose confidence if their products are exploited in cyber attacks. During the first contact with the product developer, JPCERT/CC takes the following points into consideration in selecting an appropriate contact and looks for contact information on the developer’s or product’s website to ensure that the information is received and verified safely. When we are unable to identify an appropriate contact by any means, we may post the information on JVN's "Unreachable Developer List" [2] and search for developer information publicly.

Vulnerability information will not be disclosed to an unspecified number of people. (e.g., OSS issue report mailing lists are not suitable.)
The department/individual is responsible for taking countermeasures against vulnerabilities within the developer organization. (It is ideal to avoid contacts for obviously different purposes such as a purchasing consultation service.)
Secure communication methods such as encrypted communication can be used. (Basically, vulnerability information should not be sent in plain text.)

Not every product developer found on websites is ready to receive vulnerability information. Each product contact and support has different approaches. It takes months for some organizations to identify responsible department after receiving reports from JPCERT/CC, and in some cases, the organization stops responding to us eventually. Furthermore, some product developers who have no experience in vulnerability handling are suspicious of JPCERT/CC and refuse to respond. Some product developers, such as those of OSS, also ask JPCERT/CC to share vulnerability-related information on public mailing lists. While it may be a more efficient way to share information, our coordination prioritizes to ensure that the information we send is properly protected.

If there is at least a vulnerability response desk, it should be clearly indicated to the public, unless the product development organization is completely unprepared to respond to vulnerabilities. This will prevent problems of vulnerability-related information reported to wrong contacts within the organization instead of the vulnerability response desk. For JPCERT/CC, "Product Developer Registration" [3] is available (Japanese only). This section introduces "RFC 9116: A File Format to Aid in Security Vulnerability Disclosure," a method to safely and securely receive information not only from JPCERT/CC but also widely from the outside.

The existing RFC 2142 [4] is recommended for an email address that organizations use to communicate security-related information. There are also other RFCs that define contact information for ISPs and CSIRTs. However, none of them provide enough information for a vulnerability finder to report a vulnerability to the developer organization, more specifically, to confirm the appropriate contact and vulnerability disclosure policy of the organization and to establish communication between the sender and receiver of the vulnerability information.

RFC9116 was defined to explain how organizations should disclose vulnerabilities and to make it easier for security researchers and others to report vulnerabilities they find. Its mechanism is simple. It requires a "security.txt" file containing the required information to be published under the "/.well-known/" path on the website. The "security.txt" file contains the following items:

Contact: Contact information and methods, including e-mail address, phone number, and contact form address
Example:
Contact: mailto:security@example.com
Contact: tel:+1-201-555-0123
Contact: https://example.com/security-contact.html
Expiration date: Expiration date of the "security.txt"
Example: Expires: 2023-03-31T18:37:07z
Acknowledgements: Location of acknowledgements to security reporters, etc.
Example: Acknowledgments: https://example.com/hall-of-fame.html
Canonical: Official location (URI) of this "security.txt")
Example: Canonical: https://www.example.com/.well-known/security.txt
Encryption keys: Location of OpenPGP public keys and other public keys that can be used when reporting vulnerabilities, etc.
Example: Encryption: https://example.com/pgp-key.txt
Recruitment information: Location of the vendor’s security-related personnel recruitment details, etc.
Example: Hiring: https://example.com/jobs.html
Policy: Location of the vendor’s security policy, etc.
Example: Policy: https://example.com/disclosure-policy.html
Preferred language: Accepted language of the security reports
Example: Preferred-Languages: en, es, fr

There are websites [5] that support the creation of "security.txt", and you can easily try to create a "security.txt." In the "security.txt" form, "contact" and "expiration date" are the only required fields, reminding us that not a few people, just as we feel every day, seek for "current" and correct contact information when contacting other organizations. The optional item of employment information is also unique and may be a way for organizations to seek out researchers. In any case, we feel that this method can easily indicate the effective collaboration partners at the vendor (developer organization) to security researchers and other vulnerability finders as well as coordinating organizations around the world. We also thought it advantageous to be able to add more information as the vendors' security and vulnerability response gets matured.

RFC9116 was officially published in April 2022, and few organizations in Japan have yet adopted it. How about adopting "security.txt" as a first step for vendors to properly connect with security researchers and vulnerability reporters of good will?

Noriko Totsuka (Translated by Takumi Nakano)

戸塚紀子（Noriko Totsuka）

Noriko Totsuka has worked for a vendor PSIRT for many years. In April 2021, she joined JPCERT/CC Early Warning Group and has been in charge of coordinating vulnerability-related information mainly with overseas vendors.