A good repository scan reads more than source code. It should cover lockfiles for dependencies, source files for code flaws, Dockerfiles, infrastructure files, CI workflow files and config files, plus the git history. Each file type exposes a different class of risk.
File by file
| File type | Examples | What a scan finds |
|---|---|---|
| Lockfiles | package-lock.json, poetry.lock, Cargo.lock, go.sum | Exact versions with known vulnerabilities |
| Manifests | package.json, requirements.txt, pom.xml | Declared dependencies, ranges |
| Source | .py, .js, .java, .go, .rs | Injection, unsafe calls, hardcoded secrets |
| Dockerfile | Dockerfile | Root user, unpinned base, secrets in build args |
| IaC | .tf, Kubernetes YAML, Helm values | Public exposure, privileged workloads |
| CI workflows | GitHub Actions, pipeline YAML | Unpinned actions, broad permissions, secret echo |
| Env and config | .env, application.yml | Committed credentials |
| Git history | All commits | Secrets removed from the tip but still stored |
Why lockfiles come first
A manifest may say a range, while the lockfile says the exact version that was installed. Vulnerability matching needs exact versions. Rust's cargo-audit, for example, reads Cargo.lock for this reason. Without a lockfile the scanner has to resolve versions itself, which can differ from what you ship.
Files people forget
- CI workflow files. They define who can push to production and which third party steps run. Pin external steps to a full commit and limit token permissions.
- Test fixtures and sample configs. They often contain real looking credentials.
- Notebook files and scripts in tools folders.
- Generated code and vendored copies of libraries, which may hide old versions.
What to leave out
Build output and downloaded dependency folders, unless you scan them deliberately. Scanning them adds noise and duplicates findings from the lockfile. Keep the exclusion list short and written down, because an exclusion hides risk silently.
Steps
- List the file types your repository holds using the table above.
- Check that your scanner covers each, and note the gaps.
- Commit lockfiles.
- Review exclusions once a quarter.
- Compare files scanned with files expected after each setup change.
How Safeguard helps
Safeguard offers dependency scanning and SBOMs, reachability analysis, and autonomous remediation with fix pull requests, which is off by default with every category on Manual. The free scan is the easiest first step.
Try it yourself
Click through it at your own pace, or open it full screen.
See which package files the inventory reads and how versions are resolved.
Quick check
Do I need to scan node_modules?
Usually no. The lockfile already identifies the packages, and scanning the folder duplicates results.
Why scan CI workflow files?
They control builds and deployments, and unpinned steps or broad token permissions are a supply chain risk.
Sources
- RustSec cargo-audit README (fetched 19 October 2026): lockfile based auditing.
Last reviewed: 19 October 2026.
