Treat the whole repository as one inventory. Find every manifest and lockfile for each language, scan them together on each pull request, and gate on new findings rather than the full backlog. Per-language tools still help for depth, but one combined result is easier to own.
Why mixed repos go wrong
Each ecosystem has its own audit command: govulncheck for Go, composer audit for PHP, NuGet audit during restore for .NET, and so on. Teams often wire up one and forget the rest. The gaps are the languages nobody owns.
Step 1: inventory the files
Search the repository for the files that matter:
| Language | Look for |
|---|---|
| Go | go.mod |
| Rust | Cargo.lock, Cargo.toml |
| .NET | csproj, packages.config |
| PHP | composer.lock |
| Ruby | Gemfile.lock |
| Swift | Package.resolved, Package.swift |
| Java and Kotlin | pom.xml, Gradle build files |
Do this in nested folders too. Monorepos hide tools in subdirectories, and a scan that starts only at the root will skip them. See our guide on which files to commit.
Step 2: make builds honor the lock files
- Ruby: frozen mode in CI. See Bundler frozen mode.
- PHP: install, not update, on deploy.
- Rust: the locked option on cargo commands.
- Swift: resolve with the force resolved versions option.
- Go: leave the default readonly mode on.
Step 3: scan everything in one place
Run one dependency scan that covers all detected ecosystems, and publish a single report. If you also keep native audits, treat them as a second opinion, not the system of record.
Step 4: decide what blocks a merge
- Block on new critical findings introduced by the pull request.
- Report, but do not block, on the existing backlog.
- Give each finding an owner by language, so it lands with the right team.
- Use reachability to order the backlog, since a reachable flaw outranks one in code your project never calls.
Step 5: keep watching
Advisories arrive after merge. Re-scan on a schedule, so code that did not change still gets checked against new data.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what the gate blocks and what it lets through, and note that the decision is based on what the pull request adds.
Quick check
Do I need a separate CI job per language?
Not for the report. A single scan over the repository gives one result. You may still run native audits for extra detail.
Should the first run block the build?
No. Start in report mode, clear the worst items, then gate on new findings only.
Safeguard's SBOM and dependency scanning, reachability analysis and pull request gates are built for this workflow, and the CLI installs with curl or PowerShell. Begin with the free scan.
Last reviewed: 19 October 2026.
