Der umfassende Leitfaden zur Verwaltung von Ruby-Gem-Abhängigkeiten

Ruby verfügt, wie andere Programmiersprachen auch, über ein ganzes Ökosystem aus Open-Source-Bibliotheken von Drittanbietern, die als Gems oder manchmal als Ruby-Gems bezeichnet werden. Diese Gems werden von der Community entwickelt und sind auf RubyGems.org verfügbar, der offiziellen Registry für Ruby-Bibliotheken. Wie in anderen Open-Source-Ökosystemen können Bedrohungsakteure gezielt Schadcode veröffentlichen oder Code, der Hintertüren oder das Abgreifen von Zugangsdaten enthält. Daher ist es entscheidend, Ruby-Gems aus dem Open-Source-Bereich sorgfältig zu verwalten und zu überprüfen.

In diesem Artikel gehe ich die Konzepte und Tools des Ruby-Abhängigkeitsökosystems durch und beantworte einige häufig gestellte Fragen von Ruby-Entwicklerinnen und -Entwicklern.

Die Programmiersprache Ruby

Vielleicht haben Sie schon von Ruby on Rails (RoR) gehört, dem beliebten Webentwicklungs-Framework, das maßgeblich zum Erfolg und zur Popularität von Ruby beigetragen hat. RoR basiert auf Ruby, einer dynamischen, plattformübergreifenden und interpretierten Sprache. Ruby-Quelldateien sind leicht an der Dateiendung .rb zu erkennen.

Was sind Ruby-Gems?

Gems sind paketierte Quellcode-Bibliotheken, die modular und unabhängig sind und sich problemlos in verschiedenen Projekten wiederverwenden lassen.

Was ist RubyGems und wie unterscheidet es sich von Bundler?

RubyGems ist die zentrale Paket-Registry, in der Ruby-Gems von Drittanbietern aus dem Open-Source-Bereich bereitgestellt werden. Außerdem ist es der offizielle Paketmanager für Ruby, der bei der Verwendung über die Befehlszeile als gem bezeichnet wird.

RubyGems ermöglicht Entwicklerinnen und Entwicklern auf hervorragende Weise den Zugriff auf ein Ökosystem mit Hunderttausenden von Open-Source-Bibliotheken, die sie in ihren Projekten einsetzen können.

Die gems-CLI von RubyGems ist in einer funktionierenden Ruby-Umgebung bereits vorinstalliert. So können Entwicklerinnen und Entwickler direkt ihre bevorzugten Open-Source-Abhängigkeiten installieren. Zum Beispiel:

1sh
2gem install rails

Die gems-CLI verwaltet Abhängigkeiten jedoch einzeln: Sie ruft sie aus einer Registry ab und installiert sie im Dateisystem, sodass sie verfügbar sind und sich problemlos in Ruby-Codeprojekten importieren lassen.

Das Bundler-Projekt ist technisch gesehen selbst ein Ruby-Gem und wird auch als solches installiert. Es vereinfacht die Installation von Gems und ermöglicht mithilfe einer Manifestdatei namens Gemfile sowie der zugehörigen Lockdatei Gemfile.lock einen deterministischen und konsistenten Abhängigkeitsbaum. Letztere legt die Abhängigkeiten im gesamten Baum fest und sorgt dafür, dass Installationen auch langfristig konsistent bleiben.

Da Bundler ein Gem ist, können Sie ganz einfach damit beginnen:

1sh
2gem install bundler

Mit diesem Befehl steht Entwicklerinnen und Entwicklern das Befehlszeilentool bundler zur Verfügung.

Das Ruby-Gemfile

Die Datei Gemfile ist eine Manifest-Textdatei, in der alle Abhängigkeiten des Projekts sowie weitere Metadaten-Anweisungen beschrieben sind, die das Tool bundler bereitstellt.

Ein einfaches Gemfile sieht so aus:

1ruby
2source 'https://rubygems.org'
3
4gem ‘rails’, ‘4.2.3’
5gem ‘sqlite3’

Das obige Gemfile definiert den Eintrag source, also das Remote-Repository, aus dem Bundler alle Gems herunterlädt. Jede Zeile mit gem definiert eine Open-Source-Bibliothek, die abzurufende Version sowie die Quelle, aus der sie bezogen werden soll.

Das folgende komplexere Beispiel zeigt, wie Ruby-Gems aus verschiedenen Quellen bezogen werden:

1ruby
2
3gem 'nokogiri'
4gem 'nokogiri', git: 'https://github.com/sparklemotion/nokogiri.git', branch: main'
5gem 'nokogiri', github: ‘sparklemotion/nokogiri’
6gem 'nokogiri', path: '/path/to/local/nokogiri’

Weitere Informationen zu diesen Quellen finden Sie ausführlich in der offiziellen Git-Dokumentation von Bundler.

Woraus besteht ein Ruby-Gem?

Ein Ruby-Gem ist Ruby-Quellcode in paketierter, modularer Form, der von anderen Ruby-Gems, Ruby-Anwendungen oder allgemein von Nutzerinnen und Nutzern wiederverwendet werden kann, die wie im Beispiel zu Bundler weiter oben über die Befehlszeile damit interagieren.

Ruby-Gems folgen üblicherweise einer Konvention, die Ruby-Quellcode, Tests, möglicherweise ausführbare Dateien im Dateipfad der Nutzerinnen und Nutzer und vor allem eine Spezifikationsdatei für Ruby-Gems umfasst, die als Gemspec bezeichnet wird.

1sh 
2base64ness/
3├─ lib/
4│  ├─ base64.rb
5├─ bin/
6│  ├─ base64ness
7│  ├─ index.html
8│  ├─ robots.txt
9├─ test/
10│  ├─ base64
11├─ base64ness.gemspec
12├─ Rakefile
13├─ Gemfile
14├─ Gemfile.lock
15├─ README.md

Einige Verzeichnisse wie test/ und bin/ sind relativ selbsterklärend: Sie enthalten den Testcode für diese Abhängigkeit und die ausführbare Datei, die mit ihr ausgeliefert und installiert wird. Weitere wichtige Dateien sind Gemfile und Gemfile.lock. Sie haben wir bereits im Zusammenhang mit Bundler kennengelernt, mit dem Ruby-Gems verwaltet werden. Die Lockdatei sorgt dafür, dass Installationen deterministisch und zuverlässig wiederholbar sind.

Die Datei Rakefile gehört zum Open-Source-Projekt Rake, einem Make-ähnlichen Build-Tool für Ruby-Projekte. Daher ähnelt der Name dem von Makefile. Hier ein Beispiel für den Inhalt:

1ruby
2require "rake/testtask"
3
4Rake::TestTask.new do |t|
5  t.libs << "test"
6  t.verbose = true
7  t.test_files = FileList["test/**/*.rb"]
8end
9
10desc "Run tests"
11task default: :test

Die Rakefile importiert die benötigten Klassen aus dem Rake-Gem und definiert eine test-Aufgabe. Wird der Befehl rake test in diesem Verzeichnis ausgeführt, weist er das Programm Rake an, mithilfe eines Glob-Musters alle Testdateien im Ordner test/ zu finden und anschließend auszuführen. Weitere Informationen zum Format der Rakefile finden Sie in der Dokumentation des Rake-Projekt-Repositorys.

Eine weitere neue Datei, die Ihnen möglicherweise im obigen Dateibaum aufgefallen ist, ist die Datei gemspec. Sie trägt oft denselben Namen wie das Paket, zum Beispiel base64ness.gemspec. Die gemspec beschreibt das Ruby-Gem und stellt Metadaten zu dieser Abhängigkeit bereit. Die RubyGems-Registry kann diese Informationen damit erfassen und analysieren und Nutzerinnen und Nutzern anzeigen, die nach Ruby-Gems suchen.

Hier ein Beispiel für das oben erwähnte Ruby-Gem base64 base64ness.gemspec:

1ruby
2Gem::Specification.new do |s|
3  s.name        = "base64ness"
4  s.version     = "1.0.0"
5  s.summary     = "It does magic with base64!"
6  s.description = "This Ruby gem adds extended utilities for base64 encoding and decoding tasks such as making them URL compliant."
7  s.authors     = ["Liran Tal"]
8  s.email       = "liran@snyk.io"
9  s.files       = ["lib/base64.rb"]
10  s.homepage    =
11    "https://rubygems.org/gems/base64ness"
12  s.license       = "MIT"
13end
14

Auf der RubyGems-Website finden Sie eine vollständige Dokumentation zur Specification-Klasse, auf die wir oben Bezug genommen haben. Sie enthält weitere Metadaten zu einem Ruby-Gem, erweiterte Funktionen, mit denen Ruby-Maintainer ausführbare Dateien definieren können, sowie die Möglichkeit, C-Erweiterungen in Ruby-Gems zu bündeln, um durch Cross-Compilation native Module bereitzustellen und vieles mehr.

Tipp: Wenn Sie wissen möchten, was sich in einem bestimmten Ruby-Gem befindet, können Sie es in ein Verzeichnis entpacken und den Quellcode wie folgt untersuchen:

1sh
2gem unpack your-ruby-gem.gem --target /path/to/gem-directory

Die Installation von Ruby-Gem-Abhängigkeiten steuern

Abhängigkeiten lassen sich logisch in bestimmte Kategorien gruppieren. Beispielsweise können Sie Ruby-Gem-Abhängigkeiten für die Produktion sowie Entwicklungs-Gems haben, die Sie nur bei der lokalen Entwicklung installieren.

Um zwischen ihnen zu unterscheiden, können Sie das folgende Gemfile-Manifest definieren:

1ruby
2group :production do
3  gem ‘rails’,
4end
5
6group :development do
7  gem ‘rspec-rails’
8end

Anschließend können Sie Abhängigkeiten mit Bundler nach Kategorie installieren. Der folgende Befehl installiert beispielsweise nur Produktions-Abhängigkeiten:

1sh
2bundle install --without development

Warum benötigen wir eine Gemfile.lock?

Wenn Sie Abhängigkeiten ausschließlich im Paketmanifest Gemfile von Bundler definieren könnten, wären Sie mit den folgenden Einschränkungen konfrontiert:

1. Es werden nur direkte Ruby-Gem-Abhängigkeiten dokumentiert.

2. Für diese direkten Ruby-Gem-Abhängigkeiten wird eine ungenaue und locker definierte Paketversion angegeben. Dabei kann es sich um die neueste Version oder lediglich um die neueste Version innerhalb eines semantischen Versionsbereichs handeln.

3. Selbst wenn Sie diese direkten Ruby-Gem-Abhängigkeiten auf feste Versionen festlegen, kann bei jeder neuen Installation dennoch eine unerwartete Version eines abhängigen Gems aufgelöst werden.

Daraus folgt: Ohne eine Lockdatei, die den gesamten verschachtelten Abhängigkeitsbaum der für Ihr Projekt installierten Ruby-Gems festlegt, würden unvorhersehbare Versionen installiert. Das ist vermutlich das Letzte, was Sie in einer automatisierten CI- oder Build-Umgebung oder bei anderen Ruby-Entwicklerinnen und -Entwicklern möchten, die mit Ihnen am Projekt arbeiten.

Deshalb gibt es die Gemfile.lock:

1ruby
2GEM
3  remote: https://rubygems.org/
4  specs:
5    actioncable (7.0.3.1)
6      actionpack (= 7.0.3.1)
7      activesupport (= 7.0.3.1)
8      nio4r (~> 2.0)
9      websocket-driver (>= 0.6.1)
10    actionmailbox (7.0.3.1)
11      actionpack (= 7.0.3.1)
12      activejob (= 7.0.3.1)
13      activerecord (= 7.0.3.1)
14      activestorage (= 7.0.3.1)
15      activesupport (= 7.0.3.1)
16      mail (>= 2.7.1)
17      net-imap
18      net-pop
19      net-smtp
20
21PLATFORMS
22  aarch64-linux
23
24DEPENDENCIES
25  bootsnap
26  capybara
27  debug
28  importmap-rails
29  jbuilder
30  puma (~> 5.0)
31  rails (~> 7.0.3, >= 7.0.3.1)
32  rails_admin!
33  selenium-webdriver
34  sprockets-rails
35  sqlite3 (~> 1.4)
36  stimulus-rails
37  turbo-rails
38  tzinfo-data
39  web-console
40  webdrivers
41
42RUBY VERSION
43   ruby 3.1.2p20
44
45BUNDLED WITH
46   2.3.18

Sehen wir uns die Spezifikation und das Format dieser Lockdatei für Gem-Abhängigkeiten an:

• Die Direktive GEM leitet den Abschnitt ein, in dem alle Ruby-Gem-Abhängigkeiten in einem verschachtelten Baumformat aufgeführt werden. Darin sind direkte und transitive Abhängigkeiten sowie ihre Versionen zu sehen. Sie werden unter der Direktive specs aufgeführt. Die Direktive remote gibt dem Bundler-Tool an, aus welcher Quelle diese Ruby-Gems für die Installation bezogen werden sollen.

• Die Direktive PLATFORMS enthält eine offene Liste der Zielplattformen, für die native Ruby-Gems erstellt werden müssen, beispielsweise aufgrund der für in C geschriebenen Ruby-Erweiterungen erforderlichen Cross-Compilation-Kette.

• Die Direktive RUBY VERSION ist optional und gibt die Ruby-Runtime-Version an, die beim Erstellen dieser Lockdatei Gemfile.lock verwendet wurde.

• Die Direktive BUNDLED WITH gibt die Bundler-Version an, mit der die Lockdatei erstellt wurde. Entwicklerinnen und Entwickler mit älteren Versionen sollten ein Upgrade in Betracht ziehen, um auf dem neuesten Stand zu bleiben und konsistente, zuverlässige Ergebnisse bei der Installation von Ruby-Gems zu erzielen.

bundler-audit und warum die Sicherheit von Ruby-Gems verbessert werden muss

Ein großartiges Ökosystem bringt große Verantwortung mit sich. Ganz genau. Hier kommt das von der Community getragene Projekt bundler-audit ins Spiel. Es ist ein Ruby-Gem, das die in der Lockdatei des Projekts (Gemfile.lock) aufgeführten Abhängigkeiten scannt und mit einer Datenbank anfälliger Ruby-Gems vergleicht. So meldet es Versionen, bei denen eine oder mehrere Sicherheitslücken gefunden wurden.

Erste Schritte mit bundler-audit zum Scannen nach Sicherheitslücken in Ruby-Gems

Um mit bundler-audit nach Sicherheitslücken zu suchen, installieren wir es zunächst wie jedes andere Ruby-Gem:

1sh
2gem install bundler-audit

Nach der Installation muss bundler-audit Sicherheitshinweise aus Quellen wie der von der Community gepflegten ruby-adivsory-db herunterladen. Diese bezieht ihre Daten wiederum aus GitHub Advisory und der von Google gepflegten Open-Source-Datenbank für Sicherheitslücken:

1sh
2bundler-audit update

Bei erfolgreicher Ausführung sollte der Befehl bundler-audit eine ähnliche Ausgabe wie die folgende anzeigen, die bestätigt, dass alles auf dem neuesten Stand ist:

1sh
2Updating ruby-advisory-db ...
3hint: Pulling without specifying how to reconcile divergent branches is
4hint: discouraged. You can squelch this message by running one of the following
5hint: commands sometime before your next pull:
6hint:
7hint:   git config pull.rebase false  # merge (the default strategy)
8hint:   git config pull.rebase true   # rebase
9hint:   git config pull.ff only       # fast-forward only
10hint:
11hint: You can replace "git config" with "git config --global" to set a default
12hint: preference for all repositories. You can also pass --rebase, --no-rebase,
13hint: or --ff-only on the command line to override the configured default per
14hint: invocation.
15From https://github.com/rubysec/ruby-advisory-db
16 * branch            master     -> FETCH_HEAD
17Already up to date.
18Updated ruby-advisory-db
19ruby-advisory-db:
20  advisories:596 advisories
21  last updated:2022-07-18 13:57:38 -0700
22  commit:66f047bdcb4bbda76857f9ba668b7d71b641b28b

Anschließend können wir bundle-audit ohne zusätzliche Argumente ausführen und nach Sicherheitslücken suchen. Für mein lokales Ruby-on-Rails-Projekt wurde derzeit Folgendes ausgegeben:

1No vulnerabilities found

Das sieht gut aus, kann aber irreführend sein und Sie unnötigen Risiken aussetzen. Tatsächlich handelt es sich um einen falsch negativen Befund, denn für einige der von mir installierten Abhängigkeitsversionen gibt es durchaus Sicherheitslücken.

Bei allem Respekt für die Arbeit der Community am Aufbau von Sicherheitstools: Wahrscheinlich fehlen ihr die Mitarbeitenden und Ressourcen, um eine angemessene Abdeckung von Sicherheitslücken zu gewährleisten. Hier kommt der Sicherheitsscanner von Snyk Open Source ins Spiel.

Snyk bietet ein kostenloses CLI-Tool, das von einem auf Entwicklerinnen und Entwickler ausgerichteten Sicherheitsunternehmen mit einer umfangreichen Datenbank mit Berichten zu Sicherheitslücken in Ruby-Gems unterstützt wird. Sie können es installieren und Ihre Abhängigkeiten scannen.

Ruby-Gems kostenlos mit Snyk absichern

Testen wir Snyk einmal und sehen wir, welche Sicherheitslücken es in unserem Rails-Projekt findet. Wenn Sie wie ich ein M1 MacBook Pro verwenden, führen Sie Folgendes aus:

1sh
2curl https://static.snyk.io/cli/latest/snyk-linux-arm64 -o snyk
3chmod +x snyk
4mv snyk /usr/local/bin

Dadurch wird die eigenständige Snyk-Binärdatei heruntergeladen, ausführbar gemacht und in Ihrem Pfad verfügbar gemacht. Falls Sie eine andere Installationsmethode benötigen, etwa brew für macOS oder scoop für Windows, lesen Sie die Dokumentation zu den ersten Schritten mit der Snyk-CLI.

Sobald die Snyk-CLI installiert ist, können wir sie wie folgt ausführen:

1sh
2snyk test

Bei der ersten Verwendung wird folgende Meldung angezeigt:

1sh
2`snyk` requires an authenticated account. Please run `snyk auth` and try again.

Geben Sie anschließend snyk auth ein und folgen Sie den Anweisungen: Kopieren Sie eine Authentifizierungs-URL in den Browser und melden Sie sich an oder registrieren Sie sich, um Ihren API-Schlüssel zu erhalten. Schon nach kurzer Zeit kehren Sie zur Eingabeaufforderung zurück und können mit dem Scan fortfahren:

1sh
2snyk test
3
4Testing /home/app/myapp...
5
6Tested 80 dependencies for known issues, found 2 issues, 59 vulnerable paths.
7
8Issues with no direct upgrade or patch:
9  ✗ Information Exposure [Medium Severity][https://security.snyk.io/vuln/SNYK-RUBY-ACTIONCABLE-20338] in actioncable@7.0.3.1
10    introduced by rails@7.0.3.1 > actioncable@7.0.3.1 and 1 other path(s)
11  No upgrade or patch available
12  ✗ Web Cache Poisoning [Medium Severity][https://security.snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.4
13    introduced by capybara@3.37.1 > rack@2.2.4 and 56 other path(s)
14  No upgrade or patch available
15
16Organization:      snyk-demo-567
17Package manager:   rubygems
18Target file:       Gemfile
19Project name:      myapp
20Open source:       no
21Project path:      /home/app/myapp
22Licenses:          enabled

Nun denn: 2 Probleme und 59 anfällige Pfade … offenbar sind wir nicht so sicher, wie wir dachten. Im Moment gibt es anscheinend keine neueren Versionen, auf die sich diese Bibliotheken im verschachtelten Abhängigkeitsbaum aktualisieren ließen. Damit Snyk die Gemfile unseres Projekts fortlaufend überwacht und nach neuen Versionen mit Korrekturen sucht, können wir eine der folgenden Maßnahmen ergreifen:

1. Gehen Sie zu https://apps.snyk.io und verbinden Sie Snyk mit dem Quellcode-Repository auf GitHub oder einer anderen Plattform. So kann Snyk dieses Projekt im Hintergrund überwachen.

2. Führen Sie den Befehl snyk monitor aus. Dabei werden Momentaufnahmen der aktuellen Dateien Gemfile und Gemfile.lock erstellt und kontinuierlich überwacht. Beachten Sie, dass Sie den Befehl in einer CI-Umgebung oder einem automatisierten Build ausführen müssen, damit jedes Mal, wenn diese Ruby-Paketmanifestdateien aktualisiert werden, eine neue Momentaufnahme zur Überwachung an Snyk gesendet wird.

Sollte ich bundle-audit oder Snyk verwenden?

Verwenden Sie beide. Das ist keine diplomatische Aussage, sondern sie ergänzen sich tatsächlich auf folgende Weise:

1. Snyk bietet eine umfangreiche Datenbank mit Sicherheitslücken im Ruby-Ökosystem, die manuell kuratiert und stets aktuell gehalten wird – oft sogar früher als bei bundle-audit und anderen.

2. Bundle-audit führt neben dem Scannen auf Sicherheitslücken weitere Prüfungen durch. So wird beispielsweise überprüft, ob Ihre Ruby-Gems nicht von unsicheren Quellen wie http:// und git:// abgerufen werden. Andernfalls könnten Man-in-the-Middle-Angriffe oder Lockfile-Injection-Angriffe den Quellcode manipulieren, den Sie erhalten und ausführen.

Zusammenfassung

Wir haben uns mit der Verwaltung von Ruby-Gems als Projektabhängigkeiten befasst, erläutert, warum die Verwendung einer Lockfile wichtig ist, und weitere Aspekte sowie empfohlene Best Practices behandelt – etwa Ruby-Abhängigkeiten sicher zu nutzen, indem Sie sie mit Tools wie Snyk und bundler-audit scannen.

Weitere Ruby-Ressourcen:

• Ruby-Gemfile-Sicherheit

• Snyk-CLI für Ruby

Wenn Sie auch JavaScript entwickeln, empfehle ich Ihnen wärmstens, Was ist package-lock.json und wie funktioniert eine Lockfile für Yarn- und npm-Pakete? zu lesen.