Basic dependency scanning needs only manifests and lockfiles, the files that list package names and versions. It does not need your source code. Reachability analysis does read code, because it checks whether your code calls the vulnerable function. Ask any vendor which mode it runs and where that code is read.
Two kinds of scan, two kinds of input
Inventory matching. The scanner reads files such as a lockfile or a container image's package database, builds a list of components and versions, and matches that list against advisory data. Your business logic never needs to leave your environment for this step. A software bill of materials (SBOM) is the same idea in a standard format: a list of components, not the code.
Call path analysis. To say that a vulnerable function in a library is actually called by your application, a tool has to read your code and build a call graph. This is more useful for prioritising, since it can remove findings that cannot be triggered. It also means the tool sees your source.
| Capability | Minimum input | Reads source code? |
|---|---|---|
| Component inventory and advisory match | Manifest, lockfile or image | No |
| SBOM generation | Manifest, lockfile or build output | No |
| Reachability analysis | Source plus dependencies | Yes |
| Static analysis of your own code | Source | Yes |
Where the code is read matters as much as whether
Reading source is not a problem if it happens where you want it to. Ask which of these applies.
- In your CI runner. The scanner runs inside your pipeline and sends only results out.
- In a local agent or CLI. Analysis runs on a developer machine or a build host you control.
- In the vendor's cloud. Code or a copy is uploaded and analysed there.
- In a deployment you host. The whole platform runs in your network.
Each is a legitimate design. They carry different risks, and your security team should pick consciously. Cloud analysis raises the questions of copy lifetime, region and who can open the copy. Local analysis moves the question to what results and metadata are sent back.
Questions to put to a vendor
- For each scan type we would enable, what files are read?
- Is any source code transmitted off our network? If yes, is it stored, and for how long?
- Can we turn on inventory scanning first and reachability later, once we are comfortable?
- Do findings include code excerpts, and are those stored or fetched on demand?
- Can analysis run on infrastructure we control?
A staged rollout is a reasonable position. Start with manifest only scanning, review what the vendor holds, then widen access.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings drop once call paths are considered, then ask yourself what input made that possible.
How Safeguard fits
Safeguard covers SBOM and dependency scanning as well as reachability analysis, and it can be deployed as SaaS, private VPC, on-prem or air-gapped. That lets you decide where code is read. You can try the free scan first. For related decisions, see cloud scanning vs hybrid scanning.
Quick check
Does an SBOM contain my source code?
No. An SBOM lists components and versions and sometimes licenses and hashes. It describes what is in the software, not how your own code works.
If a vendor reads my code, is that always a problem?
No. It is a decision to make with eyes open. Know where the code is read, whether a copy is kept, and who can open it.
Last reviewed: 19 October 2026.
