This is a joint post with the Ruby Central team. The full report, which includes all of the detailed findings from our security audit of RubyGems.org, can be found here.

Ruby Central hired Trail of Bits to complete a security assessment and a competitive analysis of RubyGems.org, the official package management system for Ruby applications. With over 184+ billion downloads to date, RubyGems.org is critical infrastructure for the Ruby language ecosystem.

Our review, conducted over five engineer-weeks in August and September 2024, uncovered thirty-three issues, including one high-severity finding related to optional StartTLS encryption in the SMTP mailer and a noteworthy medium-risk finding involving a lack of multi-party approval for production deployments. We also found patterns of issues that are not immediately exploitable, but could compound into more serious vulnerabilities if unaddressed; these include overly broad IAM permissions, insufficient role separation, and unnecessary public exposure of services. Our recommendations include fixes and mitigations for identified issues and steps to implement security testing tools like Semgrep, Burp Suite Professional, and Ruzzy.

This blog explores our audit, findings, and key takeaways that impact every Ruby developer who relies on RubyGems.org for their dependencies—from independent developers pulling gems for side projects to enterprises managing mission-critical applications serving millions of users.

“The audit Trail of Bits conducted on RubyGems.org has both given us confidence that we are responsibly maintaining the Ruby packaging ecosystem and provided key insights into where we should invest to take things to the next level.” – Samuel Giddins, Security Engineer in Residence @ Ruby Central

Why RubyGems?

RubyGems.org is the central package repository for the Ruby ecosystem, serving the same essential function as npm for JavaScript or PyPI for Python. As the official distribution platform for Ruby libraries, its security directly impacts millions of applications, from small open-source projects to enterprise systems.

The platform’s architecture follows industry best practices: a three-tier web application built on standard frameworks and libraries, with clear separation between the front end, back end, and database layers. This solid foundation allowed us to focus our security assessment on higher-risk areas like trusted publishing and infrastructure configuration.

Audit scope and findings

Three engineers spent five engineer-weeks reviewing code in the rubygems.org and rubygems-terraform repositories. Our assessment covered web application vulnerabilities, infrastructure configuration, authentication mechanisms, and access controls.

During the audit portion, we focused on answering several questions, including but not limited to:

• Is RubyGems susceptible to common web vulnerabilities such as cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injection (SQLi), and server-side request forgery (SSRF)?
• Can an attacker bypass authentication in the RubyGems web interface?
• Can unauthenticated users perform unauthorized operations in the RubyGems web interface?
• Are access controls properly enforced?
• Are internal and privileged APIs hardened against external and unauthorized access?
• Does RubyGems deserialize untrusted data securely?
• Are secrets managed and stored securely?
• Are AWS services securely configured?

The 33 security issues we identified include a high-severity vulnerability in RubyGems’ email system that could allow the interception of potentially sensitive emails. RubyGems.org uses Rails’ ActionMailer with SendGrid SMTP for email delivery. Currently, the SMTP configuration in config/initializers/sendgrid.rb uses enable_starttls_auto: true, which attempts to establish encrypted communication via StartTLS but falls back to unencrypted transmission if the secure connection fails. This creates a security vulnerability where an attacker positioned between RubyGems’ application server and the SMTP server can perform a downgrade attack by stripping StartTLS commands during the initial handshake or returning unsupported errors, forcing the communication to fall back to an unencrypted channel.

The recommended fix for this issue is to replace enable_starttls_auto with enable_starttls, which enforces strict TLS encryption with no fallback option—if secure transmission isn’t possible, the email won’t be sent at all. For long-term security, we also recommended that the action-mailer-insecure-tls Semgrep rule be implemented in CI systems to catch similar issues.

We also uncovered three interesting issues across the codebase:

• The RubyGems library has functionality that enables deserialization exploitation by storing Marshaled data alongside gem files. This issue doesn’t affect the RubyGems.org service itself (and is therefore informational), but it does provide attackers with an avenue to exploit Ruby users.
• The most widespread issues stemmed from mixing infrastructure as code (IaC) with manual infrastructure changes. Four findings (TOB-RGM-16, TOB-RGM-20, TOB-RGM-21, TOB-RGM-29) reveal how this hybrid approach creates security gaps. While Ruby Central was already migrating to full IaC when our audit began, these findings highlight why organizations should commit fully to automated infrastructure management.
• We also identified several SSRF vulnerabilities. While these issues are individually low severity, they’re still concerning because they’re easily overlooked during development and challenging to remediate properly. The complexity comes from needing to balance security controls with legitimate functionality—simply blocking requests isn’t viable, but allowing them requires careful validation that’s easy to get wrong.

Our recommendations emphasize a two-tiered approach: short-term fixes focused on immediate security hardening (like restricting permissions, enabling MFA requirements, and removing unused resources) and long-term strategic improvements of security practices. The long-term recommendations call for automation, particularly around resource management through Terraform, regular security reviews, and integrating security testing tools.

Evaluating RubyGems against other package managers

Our competitive analysis focused on evaluating RubyGems by comparing it primarily against the Principles for Package Repository Security document with a small emphasis on comparing RubyGems against four other package managers (PyPI, npm, Go Packages, Cargo). We assessed RubyGems’ authentication and authorization mechanisms, command-line tools, and general capabilities. While RubyGems demonstrates comparable functionality to other package managers, we identified 19 specific areas that could be improved.

These enhancements would strengthen RubyGems’ Trusted Publishing infrastructure and expand supported platforms, making it safer and easier for developers to publish and use Ruby packages securely.

Automated testing: Static analysis, dynamic testing, and fuzzing

Our multi-layered security testing approach for Ruby Central combined automated tools with manual analysis. We used Semgrep to perform static analysis, allowing us to catch issues like insecure cookie configurations, unsafe deserialization patterns, and potential AWS infrastructure misconfigurations before they reached production.

We customized Semgrep rules specifically for Ruby Central’s needs and provided them in our report, so they can be integrated into the CI/CD pipeline for continuous security testing. You can read more about our ever-expanding set of custom Semgrep rules in our recent blog post.

For dynamic analysis, we deployed Burp Suite Professional to actively test RubyGems’ web interface, focusing on authorization issues, SSRF vulnerabilities, and API endpoint security. Key extensions like Turbo Intruder helped identify potential race conditions, while Active Scan++ found deeper issues like blind code injection vulnerabilities.

For lower-level security concerns, we used our coverage-guided fuzzer, Ruzzy, to test critical components that handle untrusted input. We particularly focused on the CBOR library used in WebAuthn functionality, where memory corruption bugs could be particularly dangerous.

This comprehensive testing arsenal now gives Ruby Central’s team the tools and knowledge to:

1. Catch security issues during development with automated checks
2. Continuously monitor for new vulnerabilities
3. Test critical components that handle user input
4. Build security testing into their development workflow
5. Scale their security testing as the codebase and associated infrastructure grows

Securing Ruby packages

During this review, we considered how certain recommended security practices, like the requirement for dual approval of production deployments, are not always applicable due to factors like the size of the development team. Because of this, we offered alternative solutions (like enabling “break-glass” access to production resources) while noting their limitations, helping the Ruby Central team find viable solutions to harden their package manager. We hope our work will help protect the millions of developers and companies relying on Ruby packages for their applications. We look forward to working with the Ruby Central team again.

If you’re interested in how we can support your project, please contact us.

*** This is a Security Bloggers Network syndicated blog from Trail of Bits Blog authored by Trail of Bits. Read the original post at: https://blog.trailofbits.com/2024/12/11/auditing-the-ruby-ecosystems-central-package-repository/