Rust: Werkzeuge für ein sicheres Dependency Management

Das Ökosystem von Rust ist riesig. Für alle gängigen Problemstellungen gibt es eine Library oder ein Tool. In Rust nennt man diese Software-Pakete Crates. Crates gibt es zum Beispiel für Serialisierung, Regex, Datenbanken, Lineare Algebra, Networking, gRPC, etc. Ein guter Anfangspunkt, um geeignete Crates zu finden, ist blessed.rs, eine kuratierte Liste von erprobten Libraries.

Diese Crates sind transparent im Projektbeschrieb (Cargo.toml) aufgelistet. Zum Verwenden einer Crate ist mindestens der Name und eine Version notwendig. Optional kann man Features ein- oder ausschalten.

[dependencies]
serde = { version = "1.0", features = ["derive"] }
…
actix-web = "4.10"
mongodb = "3.2"

Die Verwendung von spezialisierten Crates macht die Entwicklung schneller, bringt aber auch gewisse Risiken mit sich.

Wie gehen wir mit Schwachstellen in unseren Libraries um?

Unternehmen müssen sich um Schwachstellen aus Libraries kümmern – der Cyber Resilience Act verpflichtet sie sogar dazu (CRA, Anhang I, Abschnitt II). Kommt hinzu, dass viele externe Libraries wiederum Abhängigkeiten haben.

Ein mächtiges Tool, um Schwachstellen in Projekt aufzuzeigen, ist der Advisory-Modus von cargo-deny. Dieses Tool untersucht rekursiv Software-Komponenten und prüft sie gegen eine Advisory Database. Verschiedene Arten von Problemen werden gefunden, zum Beispiel Vulnerabilities, unmaintained Crates, von crates.io entfernte Crates, etc.

Wenn eine Schwachstelle oder ein sonstiges Problem in Abhängigkeiten gefunden wird, gibt es die Möglichkeit, diesem Problem nachzugehen. Dabei kann es je nach Produkt unterschiedliche Lösungsansätze geben. Ein simples Upgrade zu einer aktuellen Version kann das Problem lösen. Es gibt auch die Möglichkeit, die Schwachstelle zu analysieren und zum Schluss zu kommen, dass im konkreten Anwendungsfall die Schwachstelle gar nicht ausgenutzt werden kann.

error[vulnerability]: `idna` accepts Punycode labels that do not produce any non-ASCII when decoded
    ┌─ …./decision_maker/Cargo.lock:172:1
172 │ idna 0.5.0 registry+https://github.com/rust-lang/crates.io-index
    │ security vulnerability detected
    │
    ├ ID: RUSTSEC-2024-0421
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0421
    // Snip
    ├ Announcement: https://bugzilla.mozilla.org/show_bug.cgi?id=1887898
    ├ Solution: Upgrade to >=1.0.0 (try `cargo update -p idna`)
    ├ idna v0.5.0
      └── url v2.5.0
          └── i-slint-compiler v1.6.0
              ├── slint-build v1.6.0
              │   └── (build) decision_maker v0.1.0
              └── slint-macros v1.6.0
                  └── slint v1.6.0
                      └── decision_maker v0.1.0 (*)

Figure 1: «cargo deny» zeigt an, dass die Applikation «decision maker» Slint UI in einer bestimmten Version verwendet. Slint UI verwendet, über einige Rekursionen, «idna». Diese Abhängigkeit hat eine Schwachstelle. Mittels Upgrade zu einer aktuelleren Version kann diese Schwachstelle in der Applikation behoben werden.

Standards erfordern die Pflege einer Software Bill of Materials (SBOM)

Aus Qualitätsgründen oder um Normenkonform zu sein, muss für ein Software-Produkt eine SBOM erstellt und gepflegt werden. Der Cyber Resilience Act (CRA Abschnitt (77)) fordert explizit eine SBOM, um Schwachstellenanalysen durchzuführen. Gängige Formate für eine SBOM sind CycloneDX oder SPDX.

Ein nützliches Tool, um eine SBOM für Rust-Projekte zu generieren ist cargo-cyclonedx das zum Metatool cyclonedx-rust-cargo gehört. Ein Rust-Projekt listet seine Abhängigkeiten in der Datei Cargo.lock. Das Tool untersucht nun diese Datei und übersetzt deren Inhalt in das maschinenlesbare CycloneDx-Format.

Damit kann eine SBOM leicht erstellt werden. Mit einem Tool wie zum Beispiel «Dependency Track» kann diese SBOM bezüglich Schwachstellen oder Lizenzen analysiert werden.

Wie halte ich Open-Source-Lizenzierungen ein?

Die verwendeten Crates sind mit einer bestimmten Lizenz veröffentlicht. Für das dargestellte, Closed-Source-Software-Projekt, gilt es sicherzustellen, sich bezüglich der Open-Source-Lizenzierung im legalen Rahmen zu bewegen. Gewisse Lizenzen, wie die MIT-Lizenz oder die Apache-Lizenzfamilie, sind sehr liberal und erlauben die Verwendung in Closed-Source-Produkten. Wohingegen GPL und davon abgeleitete Lizenzen verlangen, dass Quellcode, der GPL-lizenzierten Code enthält, wiederum veröffentlicht wird.

Um zu überprüfen, ob das Produkt nur geeignete Lizenzen verwendet, kann man den License Check von cargo-deny verwenden.

error[rejected]: failed to satisfy license requirements
  ┌─ registry+https://github.com/rust-lang/crates.io-index#i-slint-backend-winit@1.6.0:4:12
  │
4 │ license = "GPL-3.0-only OR LicenseRef-Slint-Royalty-free-1.2 OR LicenseRef-Slint-commercial"
  // Snip         
  │
  ├ GPL-3.0 - GNU General Public License v3.0 only:
  ├   - **DEPRECATED**
  ├   - OSI approved
  ├   - FSF Free/Libre
  ├   - Copyleft
  ├ LicenseRef-Slint-Royalty-free-1.2 is not an SPDX license
  ├ LicenseRef-Slint-commercial is not an SPDX license
  ├ i-slint-backend-winit v1.6.0
    └── i-slint-backend-selector v1.6.0
        └── slint v1.6.0
            └── decision_maker v0.1.0

Figure 2: «cargo deny» zeigt an, dass die Applikation «decision maker», wiederum über einige Rekursionen, «i-slint-backend-winit» verwendet. Die zugehörigen Lizenzen fordern, dass der Source Code veröffentlicht wird oder dass eine kommerzielle Lizenz verwendet wird.

In einer Konfigurationsdatei steht, welche Lizenzen für unser Produkt erlaubt sind:

allow = [
  "MIT",
  "BSD-3-Clause",
  "Apache License 2.0",
]

Alle anderen Lizenzen werden als nicht erlaubt markiert.

Alternativ zum Lizenz-Check von cargo-deny können die Lizenzen mittels SBOM überprüft werden. Sowohl das CycloneDX-Format als auch das SPDX-Format haben die Möglichkeit, Lizenzinformationen darzustellen. Mit Werkzeugen von Drittanwendern oder einem einfachen Script, kann die SBOM bezüglich Lizenzen ausgewertet werden.

Abschluss: eine Frage der Anforderungen

In Rust können Bibliotheken und Pakete von Drittanbietern (Crates) komfortabel in Projekten verwendet werden. Die Risiken, die damit einhergehen (Schwachstellen, Lizenzen), kann man mit leicht einsetzbaren Werkzeugen nachverfolgen und damit im Griff behalten. Je nach Anforderung können auch andere, aber ähnliche Werkzeuge wie die genannten zum Einsatz kommen.

Für ein kontinuierliches Nachverfolgen von Risiken, bietet es sich an, die Werkzeuge in die CI/CD-Pipeline einzubauen, so dass, im Fall eines Fehlers eine Warnung generiert wird.