Reachability for Ruby Now in Beta

Security teams today are drowning in a sea of new CVEs. Every week brings more disclosures, but few teams have the bandwidth to fix them all. Upgrading dependencies is time‑consuming and risky, often leading to breaking changes that can take days to sort out.

By pinpointing which vulnerabilities can actually be exploited within an application, it allows organizations to prioritize real risks and reduce wasted effort. This approach has already saved teams significant time across JavaScript/TypeScript and Python projects, and today we're excited to make this available for Ruby in beta.

The dynamic nature of Ruby has historically made deep reachability analysis more challenging. Many existing tools struggle to model Ruby’s runtime behavior well enough to guide prioritization. Socket’s reachability engine now applies precise, function-level analysis to Ruby applications, enabling accurate vulnerability triage in even the most complex codebases.

How Reachability Analysis Works#

Socket’s reachability analysis for Ruby builds on function-level call graph analysis. In short, it computes, for each function in your application, which other functions it may call. A vulnerable function is considered reachable if an application function exists that can transitively invoke it.

This analysis technology was developed in collaboration with researchers at Aarhus University, leveraging state-of-the-art academic work. The Ruby analysis builds upon our experience creating function-level reachability engines for other dynamic languages, including JavaScript/TypeScript and Python.

All reachability analyses are designed to be over-approximating. When uncertain, the analysis errs on the side of caution, classifying vulnerabilities as reachable or unknown to ensure that exploitable issues never slip through the cracks.

Learn more about the analysis engines in the Static Reachability Analysis docs.

Reachability Analysis for Ruby#

Ruby presents unique challenges for static analysis. Its dynamic features, such as runtime class modification, are frequently used in meta-programming, a common pattern in many popular Ruby libraries.

Consider this example:

class Greeter
	def self.greet
		puts "Hello, World!"
	end
end

Greeter.greet  # Prints "Hello, World!"

module Modify
	def self.included(cls)
		cls.define_singleton_method(:greet) { puts "Goodbye, World!" }
	end
end

Greeter.include Modify
Greeter.greet  # Prints "Goodbye, World!"

Socket’s reachability analysis for Ruby soundly infers that both implementations of the greet method are reachable. This conservative approach ensures that dynamic behavior in Ruby applications is correctly accounted for, minimizing the risk of overlooking exploitable code paths.

Beta Status#

Our Ruby reachability support is still in beta. Here’s what to expect:

• Coverage of Ruby (gem) CVEs is currently limited, and we’re steadily improving it.
• The analysis may fail to produce results in rare cases due to unexpected conditions, especially for tier 1 scenarios. We’re actively fixing these as they’re discovered.
• Like any static analysis, results may contain false negatives if data flow through certain parts of Ruby’s standard library isn’t yet modeled.

We welcome feedback from the community on any incorrectly classified vulnerabilities.

Getting Started#

You can start using reachability analysis for Ruby today:

• Pre-computed reachability results are available to all customers directly in the Socket Dashboard.
• Full application reachability is available to enterprise customers via the Socket CLI. Run the following command on your project:

socket scan create --reach

For full setup instructions, see the Full Application Reachability docs.

Support for Ruby reachability marks another step toward our goal of bringing precise, function-level analysis to every major ecosystem. We’ll continue expanding language coverage and improving accuracy so teams can spend less time chasing CVEs and more time fixing what’s actually exploitable.