Rust: Tools for reliable dependency management

The Rust ecosystem is enormous. There is a library or tool for all commonly encountered problems. In Rust, these software packages are called crates. For example, crates are available for serialisation, regular expressions, databases, linear algebra, networking, gRPC and many more. A good place to start looking for suitable crates is blessed.rs, a curated list of tried-and-tested libraries.

These crates are listed transparently in the project description (Cargo.toml). To use a crate, at least the name and a version are required. Features can be enabled or disabled as desired.

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

The use of specialised crates speeds up development, but also entails certain risks.

How do we deal with vulnerabilities in our libraries?

Companies must address vulnerabilities in libraries – the Cyber Resilience Act even obliges them to do so (CRA, Annex I, Section II). In addition, many external libraries have dependencies themselves.

A powerful tool for identifying vulnerabilities in projects is cargo-deny advisory mode. This tool recursively examines software components and checks them against an advisory database. Various types of issues are found, such as vulnerabilities, unmaintained crates, crates removed from crates.io, etc.

If a vulnerability or other issue is found in dependencies, this problem can be investigated. The solutions may differ depending on the product. Simply upgrading to a current version can resolve the issue. There is also the option of analysing the vulnerability and concluding that it cannot be exploited in the specific use case.

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 indicates that the “decision maker” application uses a specific version of Slint UI. Slint UI uses idna via a number of recursions. This dependency has a vulnerability, which can be fixed in the application by upgrading to a more recent version.

Standards require the maintenance of a Software Bill of Materials (SBOM)

For quality reasons or to comply with standards, a SBOM must be created and maintained for a software product. The Cyber Resilience Act (CRA Section (77)) explicitly calls for a SBOM to perform vulnerability analyses. Common formats for a SBOM include CycloneDX or SPDX.

cargo-cyclonedx is a useful tool for generating a SBOM for Rust projects. It is part of the cyclonedx-rust-cargo metatool. A Rust project lists its dependencies in the Cargo.lock file. The tool examines this file and translates its content into the machine-readable CycloneDX format.

This makes it easy to create a SBOM. Using a tool such as Dependency-Track, this SBOM can be analysed with regard to vulnerabilities or licences.

How do I comply with open source licensing?

The crates used are published under a specific licence. For the closed-source software project outlined here, it is important to ensure compliance with legal requirements regarding open source licensing. Certain licences, such as the MIT licence or the Apache licence family, are very liberal and allow use in closed-source products. In contrast, GPL and its derivatives require that source code containing GPL-licensed code must also be published.

The cargo-deny licence check function can be used to make sure that the product only uses appropriate licences.

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” indicates that the “decision maker” application uses “i-slint-backend-winit”, again via several recursions. The associated licences require that the source code be published or a commercial licence used.

A configuration file specifies which licences are permitted for our product:

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

All other licences are marked as not permitted.

As an alternative to the licence check with cargo-deny, licences can be verified using SBOM. Both the CycloneDX and SPDX formats include the option of displaying licence information. The SBOM can be evaluated with regard to licences using third-party tools or a simple script.

Conclusion: a question of requirements

In Rust, third-party libraries and packages (crates) can be conveniently used in projects. The associated risks (vulnerabilities, licences) can be tracked and managed with easy-to-use tools. Depending on requirements, other similar tools to those mentioned may also be used.

For continuous risk tracking, it is advisable to integrate the tools into the CI/CD pipeline, so that a warning is generated in the event of an error.