This page outlines the process for handling security vulnerabilities in Ruby.

The Ruby security team is comprised of some committers and other security specialists.

Release managers and distributors who create and distribute Ruby packages (e.g., package managers in Linux distributions) should subscribe to [email protected] to receive timely updates.

Security vulnerabilities should be reported via a private channel to ensure responsible disclosure and allow time for a fix before public knowledge.

• The primary method for reporting is through HackerOne.
• Reports sent to security at ruby-lang.org will be redirected to HackerOne.
• DO NOT report vulnerabilities via Redmine or GitHub, as they immediately publishes reported problems, which is not suitable for security issues.

Once a report is received on HackerOne, a triage process is conducted to determine if it constitutes a valid vulnerability.

• We generally examine the following sections of a report:
  • Description
  • Proof of Concept (PoC) of vulnerable code
  • Attack surface and exploitation vector
  • Impact for users
• Triage Workflow:
  • Initial Assessment: Reports are checked for fraudulent claims (e.g., AI-generated, copy-pasted). Obvious false claims are rejected immediately (ticket set to N/A or Spam).
  • Investigation: If the report is not obviously false but requires more analysis, the team responds with "investigating" on HackerOne and discusses it internally via a dedicated Slack channel. If a decision cannot be reached, it is escalated to the monthly developer meeting.
  • Classification:
    • If the issue is deemed a non-security bug, the reporter is informed, and they are requested to create a ticket on bugs.ruby-lang.org. The HackerOne ticket is closed as Informative.
    • If the issue is a third-party library's problem, the reporter is informed, and the ticket is closed as Informative.
    • If the report is confirmed as a vulnerability, the HackerOne ticket status is set to Triaged. and the process moves to the next step.

For confirmed vulnerabilities, we create a dedicated Slack channel for private discussion and coordination. External experts may be invited to the channel as needed because we limit #security participants to security operation personnel and Ruby release managers only.

For individual cases, create dedicated channels and discuss there. These dedicated channels should only discuss the relevant case and invite experts and stakeholders such as library maintainers as needed.

Dedicated channel creation is possible using the @h1-channel-creator https://hackerone.com/reports/XXXXXX command in the #security channel.

To manage the vulnerability disclosure process and assign a CVE, we use GitHub Security Advisories. GitHub is a CVE Numbering Authority (CNA), which allows us to request a CVE identification number directly through their platform.

1. Create a Draft Security Advisory: A draft security advisory is created for the vulnerability. This provides a private space to discuss the issue and its potential impact.
2. Request a CVE Number: From the security advisory, we can request a CVE number from GitHub. The request is typically reviewed within 72 hours.

For cases where MITRE is used, please refer to the instructions in the appendix.

For more detailed instructions, see the appendices or refer to the GitHub documentation on security advisories.

The process of resolving the vulnerability is conducted privately.

• This involves discussions with the original reporter on the HackerOne ticket.
• Patches are developed, often using GitHub's private fork feature, to avoid premature disclosure. The final patch is attached to the HackerOne ticket for the reporter to review.
• Patches are created for all affected stable branches.
• Great care is taken to avoid introducing new vulnerabilities or bugs during the fix implementation.

• Draft Announcement: A draft of the security announcement is created as a Security Advisory in the ruby/www.ruby-lang.org GitHub repository.
• Coordinate with Stakeholders: A release schedule is decided (typically Tuesday to Thursday is preferred). An advance notice is sent to [email protected] for coordination with stakeholders like distribution maintainers, service providers, and other Ruby implementations. The notice includes the target component, planned release date, and CVE ID.

Email example

Subject: Advance notice: Security release plan of Ruby 2.6.9 / 2.7.5 / 3.0.3

Hello,

We are planning to make a security release of Ruby on 2021/11/24 night in JST.

They will include two new security fixes:

* CVE-2021-41816
* CVE-2021-41819

Best regards,

That mail is for coordination with the following stakeholders is crucial before public disclosure.

• Distribution maintainers: RedHat and Debian
• Service Providers: AWS, GitHub and CircleCI
• Other Ruby implementations: JRuby and TruffleRuby

On the planned release day, the following steps are taken:

1. The patch is merged into the master branch and then backported to all affected stable branches.
2. The team waits for the CI to build the release tarballs, which are then placed on S3.
3. The security advisory on www.ruby-lang.org is merged and the site is deployed. The Fastly cache is purged as needed.
4. The vulnerability disclosure is shared with the original reporter.

After a vulnerability has been publicly disclosed, notify MITRE to update the CVE entry by following these steps:

1. Navigate to the request form: Open the form at https://cveform.mitre.org/.

2. Complete the form for publication notification:

   • Select a request type: Notify CVE about a publication
   • Enter your e-mail address: [email protected]
   • Enter a PGP Key (to encrypt): Provide the public key for [email protected], which can be found at https://www.ruby-lang.org/security.asc.
   • Link to the advisory: Enter the URL of the security advisory (the corresponding article on www.ruby-lang.org).
   • CVE IDs of vulnerabilities to be published: Provide the CVE ID to be published.
   • Additional information and CVE ID description updates: Add any other relevant details.
   • Date published (e.g., mm/dd/yyyy): Enter the publication date.

3. Submit the form.

To request a CVE ID from MITRE, follow these steps:

1. Navigate to the request form: Open the form at https://cveform.mitre.org/.

2. Complete the form:

   • Select a request type: Request a CVE ID
   • Enter your e-mail address: [email protected]
   • Enter a PGP Key (to encrypt): Provide the public key from https://www.ruby-lang.org/security.asc.
   • "I have verified that this vulnerability is not in a CNA-covered product.": Check this box.
   • "I have verified that the vulnerability has not already been assigned a CVE ID.": Check this box.
   • Vulnerability type: Describe the type of vulnerability (CWE compliant is preferred).
   • Vendor of the product(s): Ruby
   • Affected product(s)/code base: Ruby (specify affected versions)
   • Optional Fields: Fill out the following sections with as much detail as possible:
     • Affected component(s)
     • Attack vector(s)
     • Suggested description of the vulnerability for use in the CVE
     • Discoverer(s)/Credits
     • Reference(s)
     • Additional information

3. Submit and await response:

   • After submitting, a plaintext confirmation email will be sent to [email protected]. No action is needed for this email.
   • Within a few days, an encrypted notification with the CVE ID will arrive at [email protected]. You will need to decrypt it to view the ID.