Add Cargo (Rust) support to dependency scanning auto-remediation

Albina Yusupovarequested to merge
604602-rust-auto-remediation into master

What does this MR do and why?

Auto remediation currently opens merge requests to bump vulnerable dependencies for Bundler, Maven, Gradle, Python, JavaScript and Go projects. This MR extends that support to Rust: cargo (Cargo.toml, Cargo.lock).

The scheduler already iterates over the configured package managers, so the Rails change is limited to:

  • Adding cargo to SUPPORTED_PACKAGE_MANAGERS in Eligibility.
  • Adding a cargo entry to PACKAGE_MANAGER_MAPPING in JobBuilder.
  • Documenting the newly supported package manager.

Nothing else needed wiring: Enums::Sbom already maps Rust to cargo (cargo and rustbinary package types), cargo is already in DEPENDENCY_SCANNING_PURL_TYPES, and Sbom::PurlType::Converter already has a cargo entry.

The cargo updater image was delivered in updater!177 and is released as cargo-updater:0. This MR only enables the Rails side.

How to set up and validate locally

Checkout at this branch and run GDK

  1. Create a blank project

  2. For convenience you can clone this repo: Cargo, or:

    1. Add Cargo.toml and Cargo.lock containing known vulnerable dependencies. The SBOM-based analyzer reads Cargo.lock, so it must be committed.
    2. Add dependency scanning job to your .gitlab-ci.yml.

  3. Attach the auto remediation profile to this project. The feature flag no longer needs enabling, but the profile does have to be attached:

    project = Project.find_by_full_path('<your-project-path>')

profile = Security::ScanProfiles::FindOrCreateService.execute(
  namespace: project.root_ancestor,
  identifier: 'dependency_scanning_post_processing').payload[:scan_profile]

Security::ScanProfileProject.find_or_create_by!(
  security_scan_profile_id: profile.id, project_id: project.id)

    The default profile is enough (severity high, cooldown 7 days, upgrade policy minor). On newer glab versions glab security config enable dependency_scanning_post_processing -R <project-path> does the same thing.

  4. Run a fresh pipeline

  5. After pipeline succeeds, go to Build -> Jobs and ensure there was a "workload" job created by Dependency Management SA. You can expect similar output in the workload job logs:

    I, [2026-07-30T11:39:13.025359 #1]  INFO -- : Update proposed: smallvec 1.6.0 -> 1.15.2 (version_update); type=direct, current=1.6.0, highest_available=1.15.2, latest_resolvable=1.15.2, version_update_scope=patch + minor (major excluded)
I, [2026-07-30T11:39:13.026451 #1]  INFO -- : Starting file updater for package_manager=cargo, directory=/, repo=cargo-ar-e2e/cargo-vuln-demo, dependencies=smallvec
I, [2026-07-30T11:39:13.177448 #1]  INFO -- : Updated 2 dependency file(s) in / directory
I, [2026-07-30T11:39:13.177583 #1]  INFO -- : Updated 2 file(s) across 1 directory(ies)
I, [2026-07-30T11:39:13.178143 #1]  INFO -- : Pipeline complete: 2 files updated, 1 dependencies (0 security)
I, [2026-07-30T11:39:13.178366 #1]  INFO -- : Writing output to /workspace/output.json
I, [2026-07-30T11:39:13.178945 #1]  INFO -- : Output written: 2 files updated, 1 dependencies (0 security)
I, [2026-07-30T11:39:13.179039 #1]  INFO -- : Dependency updater completed successfully
time=2026-07-30T11:39:13.406Z level=INFO msg="Update completed successfully"

  6. After the workloads complete go to the Merge Requests and check that the new MRs have been opened. Using the fixture repo above you get three, one per vulnerable crate, each changing only Cargo.toml and Cargo.lock:

    Security: Update smallvec from 1.6.0 to 1.15.2
Security: Update regex from 1.5.4 to 1.13.1
Security: Update yaml-rust from 0.4.0 to 0.4.5

    image image

    Note: you can expect the dependency to be bumped to the latest minor version, not to the exact fix version.

    Check that the MR is linked to the correct vulnerability.

References

Edited by Albina Yusupova

Merge request reports