Why Is This Dependency Here? — Bomly
To find out why a dependency is in your project, run bomly explain from the repo root. Bomly resolves the dependency graph, finds the package, and prints the path or paths that introduced it. Add --enrich when you also want license and vulnerability metadata.
This is useful for the small mystery every dependency reviewer knows: a package appears in a lockfile, nobody remembers choosing it, and the answer is somewhere in the graph. It may be direct, transitive, pulled in through multiple routes, or present only because another tool dependency brought it along.
For Go projects, this may sound similar to go mod why. That is intentional. Bomly's explain command takes the same useful question — “why is this dependency here?” — and turns it into a broader dependency review workflow across supported ecosystems, with optional license, vulnerability, reachability, and OpenSSF Scorecard context.
Start with the package name
From the root of a Go project, ask why github.com/spf13/cobra is present:
bomly explain github.com/spf13/cobra --enrich -q<br>Copy
The command resolves the local project, traces dependency paths, and enriches the explained package. --enrich runs Bomly's enabled matchers for external package metadata. Optionally, --matchers +scorecard can be added to opt into the Scorecard matcher specifically; it is not part of the default enrichment set because it adds one lookup per unique GitHub repository.
In Bomly CLI 0.16.0, that command reports:
The real output includes nine paths. The important part is the shape: Cobra is a direct dependency, but it is also present through other tools in the graph. That answers a different question than "is it listed in go.mod?" It tells you what else depends on it, which is usually the more useful review question.
Read the impact section
The Markdown output is handy when you want a review artifact:
bomly explain github.com/spf13/cobra \<br>--enrich \<br>--matchers +scorecard \<br>--format markdown -q<br>Copy
The same run summarizes the review context:
Impact Assessment
- Vulnerabilities: 0<br>- Policy findings: none<br>- Licenses: 1<br>- Project posture: 6.5/10 github.com/spf13/cobra<br>(updated 2026-06-29, scorecard v5.5.1-0.20260519155427-916bfc57fa74)<br>Copy
That is often enough for a local review. You can see the Apache-2.0 license from deps.dev metadata, that no vulnerability matches were found in this run, and that Scorecard has a result for the upstream GitHub repository.
For automation, use JSON and select the fields you need:
bomly explain github.com/spf13/cobra \<br>--enrich \<br>--matchers +scorecard \<br>--json -q |<br>jq '.targets[0].dependency | {<br>name,<br>version,<br>licenses: [.licenses[] | {value}],<br>vulnerabilities: [.vulnerabilities[]? | {id, severity}],<br>scorecard: {<br>repository: .scorecard.repository,<br>aggregateScore: .scorecard.aggregateScore,<br>runDate: .scorecard.runDate<br>}'<br>Copy
That gives you the same data in a shape a script can consume:
"name": "github.com/spf13/cobra",<br>"version": "v1.10.2",<br>"licenses": [{ "value": "Apache-2.0" }],<br>"vulnerabilities": [],<br>"scorecard": {<br>"repository": "github.com/spf13/cobra",<br>"aggregateScore": 6.5,<br>"runDate": "2026-06-29T00:00:00Z"<br>Copy
When the package has advisories
If enrichment finds known advisories, they appear in the same report. For example, this public fixture pins an older golang.org/x/text. Add --analyze when you want Bomly to run reachability analysis too:
bomly explain golang.org/x/text \<br>--url https://github.com/bomly-dev/example-go-gomod \<br>--ref v1.0.0 \<br>--enrich \<br>--analyze \<br>--format markdown -q<br>Copy
The impact section includes the vulnerable package version, license, advisory IDs, and the reachability result:
Impact Assessment
- Vulnerabilities: 2<br>- Policy findings: none<br>- Licenses: 1<br>- Reachability: 2 analyzed (2 unreachable)
| Severity | ID | Reachability | Fixed In |<br>| --- | --- | --- | --- |<br>| HIGH | GHSA-69ch-w2m2-3vjp | unreachable (package) | 0.3.8 |<br>| HIGH | GHSA-ppp9-7jff-5vj2 | unreachable (package) | 0.3.7 |<br>Copy
Reachability is still experimental. Symbol-level reachability is currently supported for Go when the advisory and govulncheck data support it; other ecosystems are currently less precise. Treat reachability as triage context, not as proof that a package is safe or unsafe. If a vulnerable package is present, decide whether to update, investigate further, or document why it is acceptable in your project.
What explain is good for
Use bomly explain when you need to answer a narrow question:
Why is this package here?
Is it direct or transitive?
Which parent packages introduced it?
What license and vulnerability context is attached to this package?
What reachability context is available for the finding?
Does the upstream GitHub repository have Scorecard data?
Use bomly scan when you want the whole graph, bomly diff when you want to review what changed between two states, and --json or Markdown output when another tool needs to consume the result. The nice part...