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

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 an email to security at ruby-lang.org or 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, 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
  • Impact for users
• Triage Policy
  • We carefully check for fraudulent reports or re-submissions of old, copied-and-pasted or LLM-generated vulnerabilities.
  • We evaluate how the reported vulnerability affects the CIA Triad (Confidentiality, Integrity, Availability).
  • We refer to the decisions made by other language communities and libraries, such as Python and Go, when assessing vulnerabilities.

The process of resolving the vulnerability is conducted privately.

• This involves discussions with the original reporter.
• Great care is taken to avoid introducing new vulnerabilities or bugs during the fix implementation.
• When creating a patch, make sure that it can be applied to older versions of Ruby.

We used to use MITRE to issue CVEs, but now we use HackerOne (https://hackerone.com/) to issue CVEs.

• Vulnerability date
• Weakness
• Affected versions
  • Use Custom version identifier
• CVSS
• Description

Enter the above information and submit the application to immediately issue a CVE.

After the vulnerability is resolved and CVE is assigned, the release date for the fix is also decided.

If the vulnerability is affected with Ruby interpreter or stdlib without default gems, we need to coordinate the release date with all of branch maintainer. The security team can decide the release date if the vulnerability is for the default gems

We need to announce the affected component, release date to security at ruby-lang.org.

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

• We made a patch for the all of affected versions of component like ruby/*** or Ruby interpreter like ruby/ruby.
• We can create the pull-request for them privately with security advisory feature of GitHub
  • https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability
  • But that feature didn't invoke GitHub Actions. We should test it our local machine.

• We publish a new release of component or new patch-level release of Ruby
• We post an article to the news page on www.ruby-lang.org, and a link to this article is added to the security page on www.ruby-lang.org.
• We also share that disclosure of the vulnerability with the original reporter.
• (Optional) We request to disclosure CVE to HackerOne.

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 security@ruby-lang.org to receive timely updates.