Safeguard scan has an option to name your organisation's private package namespaces, such as an npm scope, and another to resolve transitive dependencies through deps.dev. Together they make a pipeline scan more accurate for packages you own and for dependencies you did not choose directly.
Why private namespaces matter
A scanner that looks up every package name in public data can mistake your internal package for a public one with the same name. That is the shape of a dependency confusion attack, where an attacker publishes a public package with your internal name and a higher version. Telling the scan which namespaces are yours lets it treat them as private rather than matching them against public advisories.
The usage page lists the option as organisation namespaces, taking a list, with a scope like at mycompany as the example.
safeguard scan --dir . --org-namespace "@mycompany" --output out/
Pair this with registry configuration. A scan option does not stop a build from pulling a public package. Scope your private packages to your own registry in the package manager configuration as well.
Transitive dependencies
Most of what ships is transitive. The usage page documents an option to resolve transitive dependencies through deps.dev, and the CLI also has a resolve command that takes a package URL and returns dependencies and version constraints, including transitive ones.
safeguard scan --dir . --resolve-transitive --output out/
Lock files already list resolved versions for many ecosystems. Where one exists, the scan can read it. Where it does not, resolving fills the gap, with the caveat that a resolved tree can differ from what your build installs.
Trade offs
Resolving through an external service adds a network dependency to the job. On air gapped runners it will not work, so plan for another route there. It can also lengthen scan time on large trees.
Making the choice per pipeline
Use the namespace option wherever you have private packages, without exception. Use resolve when you have no lock file, or when you want a second opinion on the tree. Keep both settings in a shared template so they do not drift between repositories.
Check your result
Scan a repository where you know a private package exists. Confirm it is not reported as a public package with advisories. Then add a lock file and see whether the component count changes.
Reading the results
A transitive finding can be hard to act on, because you do not control the package that pulls it in. Look for the direct dependency at the top of the chain and check whether a newer version of it updates the transitive one. If not, an override or a replacement may be needed, and reachability information can show whether the vulnerable code is used at all.
Quick check
Does the namespace option block dependency confusion?
No. It improves how the scan treats your packages. Registry scoping in the package manager is what stops the wrong package being installed.
Does resolving replace a lock file?
No. A lock file is the better record of what the build used.
Sources
Last reviewed: 19 October 2026.
