Yes. An analytics SDK adds third-party code, its own dependencies and an outbound network path to a tool that often runs with developer or CI credentials. It can be acceptable, but treat it like any dependency you must justify, and compare it with a small first-party counter.
What you take on
When you add an analytics package to a CLI you inherit four things.
- Its code. It runs inside your process, with the same file and network access as your tool.
- Its dependencies. Analytics libraries often pull in HTTP clients, queue libraries and more. Each is another maintainer account that could be compromised.
- Its defaults. Some SDKs capture more than you expect, such as machine identifiers, IP addresses or full error text, unless configured otherwise.
- Its endpoint. Your users' data goes to a service you do not run, under its terms.
None of these are reasons to refuse. They are reasons to look.
First-party versus third-party
| Question | Third-party SDK | Small first-party code |
|---|---|---|
| Lines of code in your binary | Many, plus transitive | A few dozen |
| Control over fields sent | Depends on configuration | Total |
| Update burden | Track its advisories | Yours alone |
| Time to build | Fast | A day or two |
| Review by customers | Another vendor to list | One fewer vendor |
Homebrew's public analytics page shows one end of the range: it sends events over HTTPS from a background process with a short timeout, and says failures are silent so analytics never delay the requested operation. That is behaviour small enough to describe in a paragraph, and to review.
A review before you add one
- Read the SDK's dependency list. Run an inventory, not a guess.
- Check which fields it collects by default, and turn off identifiers you do not need.
- Check that it can be fully disabled with a setting and that disabled means no network calls.
- Run your tool with a network capture and look at every request.
- Check how quickly its maintainers respond to security reports.
- Decide where the events go and write it on your telemetry page.
Try it yourself
The demo below shows a dependency inventory for a project. Look at how many packages sit under the one you added on purpose.
Click through it at your own pace, or open it full screen.
Keep the blast radius small
If you do use an SDK, load it lazily, and only when telemetry is enabled. Then a user who opted out does not run the code at all. Pin its version, keep it in the lockfile, and watch its advisories.
Quick check
Does opting out of telemetry remove the SDK's risk?
Only if the SDK is not loaded at all when disabled. A dormant library can still contain a vulnerability, so keep it updated.
Should we build our own counter instead?
For a few events, a small first-party sender is often easier to review. For rich product analytics, an SDK may be reasonable if you complete the review above.
Safeguard's SBOM and dependency scanning can map the transitive packages in a CLI, and the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
