Before running dbt deps for a new package, check where it comes from, how you will pin it, what its macros and hooks do, and who maintains it. Ten minutes of reading usually answers whether it is safe to add. Record the decision so the next update is a diff, not a debate.
The checklist
1. Source and identity
Is this the package you meant to install? Look for lookalike names on the Hub and in Git hosting. Confirm the organization and repository match the documentation you were following. Typosquatting is a general supply chain tactic, and a short package name is easy to mistype.
2. How it is pinned
Hub packages need a version, and Git packages should use a full commit hash. The dbt docs say prerelease versions are excluded by default, so avoid switching on prerelease installs for production.
3. What it contains
List the macros, models, seeds and tests. A utility package should not need a seed full of data or models in schemas unrelated to its job.
4. Hooks and operations
Search the project file for pre-hook, post-hook, on-run-start and on-run-end entries. See what a dbt macro or hook can do. Anything that grants, drops or alters objects needs a clear reason.
5. Python or external calls
Check for Python models, external functions or anything that reaches outside the warehouse. Python models run on the data platform and declare third party packages, which adds a second dependency tree.
6. Dependencies of the package
Open its own package file. A package that pulls in three more is four reviews, not one.
7. Maintenance signals
Recent releases, open issues about breaking changes, and a named maintainer. Our note on maintainer health signals explains how to read them.
8. Licence
Confirm the licence fits how you will use it.
9. Update plan
Decide who reviews upgrades, how often, and where the lock file change is read. The docs say the package hub does not certify security, so the review is yours.
10. Exit plan
Could you copy the two macros you need instead of installing the whole package? Sometimes vendoring a small macro, with its licence, is lower risk than a dependency.
Recording the decision
Put a short line in your project README or a decision record: package, version or commit, reviewer, date and what you looked at. When the package updates, reviewers start from that line.
Quick check
Is reading the macros really necessary for a popular package?
Popularity is not a review. Reading takes minutes, and the docs state that hub packages are not certified for security.
What if the package has no maintainer activity?
Decide whether you can vendor the pieces you need or accept maintaining a fork.
Safeguard's SBOM and dependency scanning can list what a project pulls in and check it against known advisories. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
