Packaged gem bundles Gemfile.lock, examples, and spec dirs — triggers false-positive vulnerability scans

[tmertens]

Checklist

• I have looked into the Readme and Examples, and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

The published auth0 gem ships a large number of files that are not needed at runtime, including:

• Gemfile and Gemfile.lock (the gem's own development lockfile)
• examples/ruby-api/ (including its own Gemfile / Gemfile.lock)
• examples/ruby-on-rails-api/ (a full Rails app, including its own Gemfile)
• spec/ (test suite and fixtures)
• .github/, .devcontainer/, .bundle/, Guardfile, Rakefile, Dockerfile, and other developer-only files

This happens because auth0.gemspec sets:

s.files = `git ls-files`.split("\n")

which pulls in every tracked file in the repository rather than only the files required to load and run the gem.

Impact: false positives in downstream vulnerability scanners.

Enterprise vulnerability scanners such as AWS ECR, Snyk, Trivy, and Grype parse Gemfile.lock files found anywhere in a container image or installed gem path. Because the published auth0 gem ships multiple Gemfile.lock files (the gem's own plus the ones inside each example app), scanners report vulnerabilities in dependencies such as activesupport, rails, sinatra, puma, etc. — none of which are actual runtime dependencies of the auth0 gem.

Consumers of the gem then have to triage, suppress, or justify these findings for every new scan, even though the flagged dependencies are never loaded in production.

Secondary impact: unnecessarily large gem footprint. The current 5.18.1 release packages a full Rails example application into every install.

Reproduction

1. gem install auth0 (or install via Bundler).
2. Locate the installed gem: gem which auth0 | xargs dirname | xargs dirname (or bundle info auth0 --path).
3. In that directory, observe the presence of Gemfile, Gemfile.lock, examples/, spec/, .github/, .devcontainer/, etc.
4. Run a vulnerability scanner (e.g. trivy rootfs, snyk test, or push a container using the gem into ECR) and observe findings reported against dependencies declared only in Gemfile.lock or in examples/ruby-on-rails-api/Gemfile.

Equivalently, inspecting the source: git ls-files in this repo currently returns ~385 files, almost all of which are included in the published gem.

Proposed resolution

Change auth0.gemspec to use an explicit allow-list for s.files rather than git ls-files, so only the files required at runtime are packaged:

• lib/**/*.rb
• LICENSE
• README.md
• CHANGELOG.md
• auth0.gemspec
• .version

Also drop s.test_files (RubyGems has deprecated it, and there is no reason to ship specs in the packaged gem) and scope s.executables to bin/* only if any runtime executables exist (currently there are none intended for end users).

This eliminates the false-positive scanner findings at the source, shrinks the gem significantly, and aligns with current RubyGems packaging guidance.

Happy to open a PR implementing this — filing the issue first per the contribution guidelines.

Additional context

Related RubyGems guidance: https://guides.rubygems.org/specification-reference/#files

ruby-auth0 version

5.18.1

Ruby version

3.1.7