Handle it as one incident with three tracks. First find every place the affected library or its wrapper is used. Then fix each track in its own way: a version bump in Go or Rust, a library or image update in C++. Finally prove the fix by checking resolved versions, not by trusting the ticket.
Step 1: find where it lives
The same upstream bug can reach you under different names. A C library may appear as a system package, a vendored copy, a Rust -sys crate, or a Go module that uses cgo. Advisory databases name packages per ecosystem, which is why ecosystem names differ for Go, Rust, NuGet and others.
Search each track:
| Track | Where to look |
|---|---|
| Go | go.mod and go.sum, then the binary build info |
| Rust | Cargo.lock, plus any -sys crate that bundles the C source |
| C++ | Conan or vcpkg files, FetchContent calls, submodules, base images |
For Go, go mod why and graph show who pulls in a module. For Rust, use the tree command, as in cargo tree invert.
Step 2: decide urgency
Ask whether the vulnerable code is reachable in each product and whether the product is exposed. Reachability analysis narrows a long list to the findings that matter first. See govulncheck reachability.
Step 3: fix each track
- Go: raise the module to the fixed version, run the tests, review go.sum. See patch a vulnerable dependency step by step.
- Rust: use a precise update for the one crate, as in cargo update precise. If a requirement blocks it, edit Cargo.toml.
- C++: bump the pinned version in the lockfile or baseline, or update the system package and rebuild the image. Follow the C and C++ update checklist.
Step 4: prove it
- Rebuild from a clean cache.
- Check the resolved versions in the built artifact, using
go version -mfor Go binaries and the lockfile for Rust. - Rescan and confirm the finding is gone.
- Record the decision, owner and date, including any product you accepted risk on.
Step 5: look back
Keep one owner for the whole incident, even when three teams do the work. Without that, each track closes on its own schedule and nobody checks the combined result.
After the incident, ask which track was slowest and why. Often it is the C++ one, because versions were not recorded. Fix the record, not just the bug.
Where Safeguard fits
Safeguard's dependency scanning, reachability analysis and SBOM generation work across these ecosystems, and autonomous remediation can raise fix pull requests once you turn it on, with every category on Manual by default. Try the free scan at gold.safeguard.sh/scan.
Quick check
Why not fix all three the same way?
The version is recorded and updated differently in each ecosystem, and C libraries may also come from the OS or an image.
How do I know a fix really shipped?
Check the resolved version in the built artifact or image after a clean rebuild, then rescan.
Last reviewed: 19 October 2026.
