Skip to content

Cargo Package Scanner

The Cargo package scanner automatically detects and extracts all third-party dependencies declared in your Rust projects that use Cargo as their package manager.

What It Does

Default file: Cargo.toml

When you enable the Cargo scanner during SBOM creation, CAST SBOM Manager will:

  • Find all Cargo manifest files (Cargo.toml and Cargo.lock) throughout your codebase
  • Extract declared dependencies from multiple dependency sections
  • Parse version specifiers to capture exact and flexible version constraints
  • Process lock files to capture exact resolved versions
  • Handle Git-based dependencies from GitHub and GitLab repositories
  • Support workspace configurations with centralized dependency management

Cargo.toml vs. Cargo.lock

The Cargo scanner processes two types of files, each serving a different purpose:

  • Cargo.toml - Declares dependencies with flexible version constraints (e.g., "1.0", "^1.5")
  • Cargo.lock - Contains exact resolved versions (e.g., 1.0.197)

If both are present, Cargo.lock provides more precise version information for your SBOM. The scanner processes both files independently, so you'll see entries from both if they exist in your project.

What Gets Detected

The Cargo scanner identifies dependencies from two types of files:

Cargo.toml

From Cargo.toml files, the scanner extracts:

  • Direct dependencies only - the dependencies you explicitly declare
  • Dependencies from the [dependencies] section
  • Development dependencies from the [dev-dependencies] section
  • Build dependencies from the [build-dependencies] section
  • Target-specific dependencies from [target.*.dependencies] sections
  • Workspace dependencies from [workspace.dependencies] section
  • Git-based dependencies from GitHub or GitLab

Supported formats:

Simple version:

toml
serde = "1.0"

Inline table with version:

toml
tokio = { version = "1.28", features = ["full"] }

Package aliases (uses real crate name):

toml
my_alias = { package = "real-crate-name", version = "2.0" }

Git dependencies:

toml
my_crate = { git = "https://github.com/org/repo" }

Version handling:

  • All version constraints are captured exactly as declared in the TOML file
  • Examples: "1.0.5", "^1.0", "~1.0", ">=1.0, <2.0" are all recorded as-is
  • Crates without version specifiers are recorded without a version
  • Git-based dependencies use org/repo as the name and may not have a version

Cargo.lock

From Cargo.lock files, the scanner extracts:

  • All resolved external crates - both direct and transitive dependencies
  • Exact locked versions for each external crate
  • Crates from crates.io (the Rust package registry)
  • Crates from Git repositories (renamed to org/repo)

The lock file provides a complete snapshot of every external crate used in your project, ensuring reproducible builds.

External vs. Local:

  • Only external crates with a source field are included
  • Local path-based crates (workspace members without a source) are excluded
  • This focuses the SBOM on third-party dependencies

Note: Unlike Gemfile.lock which only captures direct dependencies, Cargo.lock includes both direct and transitive dependencies (dependencies of your dependencies).

How It Works

Cargo.toml Processing

When scanning a Cargo.toml file, the scanner:

  1. Parses the TOML file structure
  2. Processes multiple dependency sections in order of precedence:
    • [dependencies] - Production dependencies
    • [dev-dependencies] - Development and testing dependencies
    • [build-dependencies] - Build script dependencies
    • [target.*.dependencies] - Platform-specific dependencies
    • [workspace.dependencies] - Shared workspace dependencies
  3. For each dependency:
    • If it's a simple string value, uses it as the version constraint
    • If it's an inline table, extracts the version field
    • If the inline table has a package field (alias), uses that as the real crate name
    • If it has a git or path field containing a GitHub/GitLab URL, extracts org/repo as the crate name
    • Creates a dependency entry with the crate name and version constraint as declared

Workspace support:

  • Workspace dependencies defined in [workspace.dependencies] are collected
  • Local dependency sections take precedence over workspace definitions
  • This matches Cargo's dependency resolution behavior

Error handling:

  • If the TOML file has parse errors but contains usable dependency tables, processing continues
  • If the file has parse errors and no usable dependencies, an error is raised

Cargo.lock Processing

The Cargo.lock file is a TOML file with a [[package]] array:

toml
[[package]]
name = "serde"
version = "1.0.197"
source = "registry+https://github.com/rust-lang/crates.io-index"

The scanner processes this format by:

  1. Parsing the TOML structure
  2. Reading the [[package]] array
  3. For each package entry:
    • Checks if it has a source field (external dependency)
    • If the source starts with git+, extracts GitHub/GitLab org/repo
    • Uses the extracted org/repo as the crate name for Git dependencies
    • Extracts the exact version value
    • Creates a dependency entry
  4. Deduplicates entries based on name, version, and source
  5. Filters out local crates (no source field)

Git source handling:

  • Git sources are identified by git+ prefix in the source field
  • Example: git+https://github.com/tokio-rs/tokio?branch=master#abc123
  • The scanner extracts tokio-rs/tokio as the crate name
  • This provides clearer identification of the dependency's origin

What It Doesn't Detect

The Cargo scanner focuses on external crates managed by Cargo. It does not detect:

  • Local workspace crates - Internal crates within your project (workspace members without a source) are excluded
  • Local path dependencies - Path-based dependencies that don't point to GitHub/GitLab
  • System libraries - Native C/C++ libraries linked via build scripts
  • Procedural macros as separate components - They're included as regular crate dependencies
  • Manually copied Rust code not declared in Cargo.toml
  • Embedded or copy-pasted code from open source projects

For complete open source detection including undeclared components and copied code, enable the OSS Knowledge Base scanning option in the Scanners step, which analyzes actual file content to identify all open source usage.