Is there a recommended approach to do SAST (Static application security testing ) and/or SCA ( software composition testing ) over the dbt code or packages used ?

In-Depth Discussions
, ,
1

For large scale use of dbt cloud , it will be important to have automatic way to test the code for security vulnerabilities in code and also in the packages used , is there is a recommended approach here ?

2

Short version: dbt doesn’t ship a security scanner, and none of the mainstream SCA tools understand packages.yml. So you put this together yourself in CI. Here’s how the pieces fit, based on the current docs.

What dbt itself gives you

  • Pinning. dbt deps writes package-lock.yml. Later runs install from the lockfile unless packages.yml / dependencies.yml changes. Commit the lockfile and treat any diff to it as a review event. This is your main supply-chain control for dbt packages.
  • Linting in CI jobs. dbt Cloud CI jobs can run extra commands. On v2 (Fusion) they use the built-in dbt lint, which is SQLFluff-compatible: it reads .sqlfluff, uses the same rule codes and honours -- noqa. That’s linting for style and correctness, not security rules.
  • There’s no documented built-in vulnerability scanning for projects or Hub packages.

SAST over SQL + Jinja

  • SQLFluff with the dbt templater is the only tool I found that actually parses dbt SQL with Jinja. Its rule categories cover structure, references, ambiguity and Jinja conventions. There’s no security or injection category, so you’d have to write custom rules for patterns you care about (e.g. run_query or string-built SQL in macros).
  • SQLFluff’s own security notes are worth reading before you run it in CI. Templating can execute SQL through macros like run_query. The library_path setting can pull arbitrary Python into the linter, so for untrusted branches pass --library-path none on the CLI so a config file can’t override it. They also recommend keeping max_parse_depth / max_parse_nodes enabled.
  • dbt-checkpoint (pre-commit hooks) and dbt-project-evaluator are good governance checks: tests, docs, structure, naming. They’re not security scanners, though.
  • Semgrep: I couldn’t confirm dbt SQL + Jinja support in its language docs, so validate it on your repo before making it a gate. Use it plus a secrets scanner for the Python/YAML/CI-config side.

SCA

  • Python side (dbt-core, adapters, anything in your CI image): every mainstream tool handles it, using requirements.txt / poetry.lock / uv.lock. That includes Snyk, Dependabot, Trivy and osv-scanner.
  • dbt Hub packages: I checked the supported-manifest lists for Snyk, Dependabot, Trivy and osv-scanner. None of them lists packages.yml or package-lock.yml. Hub packages resolve to git repos, not a registry with an advisory feed, so there’s no CVE database to match against anyway.
    • What works in practice: in CI, run dbt deps from the committed lockfile, then scan the installed dbt_packages/ directory as source code (SAST + secrets). Gate PRs on lockfile changes, and only allow revisions someone has reviewed.
    • If you want them in an SCA dashboard, osv-scanner accepts a custom osv-scanner.json with dependencies you’ve extracted yourself. You’d generate that from the lockfile, but expect few to no advisories, for the reason above.

A pipeline that covers it (PR-triggered, dbt Cloud CI job or GitHub Actions):

  1. Fail if package-lock.yml changed without approval from a designated reviewer (e.g. CODEOWNERS).
  2. Run dbt deps from the lockfile, then dbt parse.
  3. Run SQLFluff (dbt templater, --library-path none, restricted warehouse credentials) or dbt lint on v2, plus any custom security rules.
  4. Run dbt-checkpoint / dbt-project-evaluator for governance checks.
  5. Run a secrets scan and SAST over the repo and dbt_packages/.
  6. Run SCA on the Python dependency files.
  7. Run a full scan on a schedule, not just on modified models.

Sources: dbt’s packages docs (lockfile behaviour) and SQLFluff security considerations. Also: dbt Cloud CI jobs docs, SQLFluff dbt templater and rules reference, dbt-checkpoint and dbt-project-evaluator READMEs, and the supported-ecosystem pages for Snyk, Dependabot, Trivy and osv-scanner. New accounts can only post 2 links.

Disclosure: an AI research agent I’m building (OpenAI models) gathered the sources, and Claude helped write this up. I checked the lockfile, dbt lint, SQLFluff security and SCA-tool claims against the docs myself.