Ability to control dependency depth (direct vs transitive dependencies)
- Dominant language
- Go
- Stars
- 9.6k
- Forks
- 954
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 42
Description
Hi Syft team,
We’re using Syft to generate SBOMs (CycloneDX format) from Docker images, JARs, and file systems as part of our compliance workflows. The tool works well — however, we have a critical requirement:
🎯 Goal
We need to control the scanning depth via CLI arguments, so that depending on our compliance use case, we can:
Include only direct dependencies
Or include direct + transitive dependencies
Or optionally exclude system or standard libraries
✅ Why This Matters
Compliance teams often want a narrow view (e.g., only direct dependencies declared in a manifest like pom.xml, package.json, etc.)
Broader scans (e.g., Docker image introspection) result in hundreds of transitive libraries, many of which are not subject to compliance review
Controlling scan scope at the CLI level would make it easy to automate this behavior in CI pipelines
🙏 Request
Could Syft provide a CLI flag to control scan depth (direct, transitive, full), or is there another recommended way to scope the dependency graph at scan-time?
This would significantly improve our ability to integrate Syft into compliance workflows with precise control over SBOM granularity.
Thanks in advance!
Contributor guide
Research direction
Start by reviewing Syft’s CLI options and the scanners for Docker images, JARs, and filesystems, then compare how manifests such as pom.xml and package.json expose direct versus transitive packages. Done means the requested scan scope is consistently defined across formats and exposed through a documented CLI option.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, go
- Domain
- cli, devtools, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100