Skip to content

CI security and dependency review

Workflow trust boundaries

  • Every workflow defaults to read-only contents access. Parse, script, Terraform, lint, archive, and scanner jobs do not receive cloud credentials or write repository contents.
  • Pull request jobs run parsing and offline checks only. BigQuery's warehouse job requires a manual dispatch from main, uses OIDC with id-token: write, and trusts one repository, workflow, ref, and event. Snowflake credentials are exposed only to the main push build; forks cannot receive them through pull request runs.
  • The BigQuery job's identity and target are configured through Terraform-managed repository variables. Verify those variables and WIF conditions against the intended non-production project before enabling the manual build.
  • Snowflake's trusted push workflow still depends on repository branch protection and secret configuration. Require reviewed changes to main, restrict who can change CI secrets, and use a disposable database/schema and auto-suspending warehouse.
  • Actionlint runs on repository workflows. Gitleaks scans checked-out repository files with redacted findings and separately checks synthetic fixtures in a temporary, read-only container mount. Release archive validation creates temporary bundles and verifies checksums without uploading them.

Dependency vulnerability review

  1. Review Dependabot pull requests for direct and transitive changes. Treat a compatible version update and a security advisory as separate review questions.
  2. Check advisories against the exact resolved package version, affected version range, reachable functionality, and available fixed version. Do not merge a lock refresh until its direct requirement remains compatible and the hash lock is regenerated.
  3. Install with --require-hashes, run credential-free dbt parse, and review the normal static checks. Run a warehouse build only against a verified isolated target when authorized and cost-reviewed.
  4. Record the package, advisory identifier, affected version, decision, remediation or accepted exception, owner, and review date in the private release-validation record. Do not copy scanner output containing account details or secrets into the repository.
  5. Revisit accepted exceptions on the next release or by their recorded review date. Escalate known-exploited or reachable critical vulnerabilities for an expedited owner decision.

GitHub settings still required

Repository YAML cannot enforce branch protection, reviewer requirements, protected environments, or secret access policy. The repository owner should protect main, limit who can edit Actions secrets/variables and release tags, and require successful parse, script, security, Terraform, and archive checks before merging or tagging. Review Dependabot PRs and action SHA changes before merge.