Treat dbt packages as third-party code that runs in your warehouse session. The dbt documentation says dbt Labs hosts the Package hub but does not certify or confirm the integrity, operability, effectiveness, or security of any package. So pin versions, read the macros and hooks before adoption, and keep installs reproducible.
What a dbt package actually is
A dbt package is a dbt project that you pull into yours. You list it in packages.yml or dependencies.yml, run dbt deps, and the files land in a dbt_packages folder. From then on its models, macros, tests and seeds are part of your project.
That matters because macros are code. A package macro can generate any SQL, and your connection runs that SQL with whatever role your profile uses. A helpful utility package and a hostile one look the same to dbt once they are installed.
Where packages can come from
The dbt docs describe several install sources. Each has a different trust story.
| Source | How you pin it | What to watch |
|---|---|---|
| Hub | A required version or version range | Ranges can float to a new release |
| Git | A branch, tag or full 40 character commit | A branch moves; a tag can be re-pointed |
| Tarball | The URL itself | Good for internal mirrors, so the content is yours to vet |
| Local | A path in the repo | Reviewed with the rest of your code |
| Private | A repo on a supported Git provider | Token scope and expiry |
The same page notes that Hub packages need a version, and that a Git package without a revision triggers a warning because it can introduce breaking changes without notice. Silencing that warning is described as not recommended.
A sensible install policy
- Prefer an exact version or a commit hash over a range or branch.
- Commit the generated
package-lock.yml. The docs say that when your package file is unchanged, later runs install from the lock file, so every environment gets the same code. - Upgrade on purpose. The docs name an upgrade option on
dbt depsfor pulling new commits or versions, which makes updates a deliberate review step. - For restricted networks, mirror approved packages as tarballs on an internal service, or host your own Hub, which the docs say is possible in dbt v1.11 and later.
- Keep git tokens narrow. The docs warn that user-bound tokens can break scheduled runs when they expire or when the user loses repo access.
What to review before the first install
Open the package and read three places: the macros folder, the project file for hooks such as on-run-start, and any run-operation entry points. Look for SQL that grants, drops or alters objects, reads from schemas the package has no reason to touch, or calls external functions. Our checklist for adding a new open source dependency applies here too, and so does pinning Python dependencies in data projects.
Try it yourself
Open the demo and look at how a dependency inventory lists direct and transitive packages. A dbt project has the same shape, just in a different file format.
Click through it at your own pace, or open it full screen.
Quick check
Does a package on the dbt Hub mean it has been security reviewed?
No. The dbt docs say the Hub is hosted by dbt Labs, who do not certify the integrity or security of any package. Review it yourself.
Is a Git tag a safe pin?
It is better than a branch, but a full commit hash is the strongest pin because it cannot be moved.
Safeguard can scan dependency manifests, build an inventory and open fix pull requests (off by default). You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
