Skip to content

Security & Auth

Credential sources

For Google provider auth, SlideFlow reads credentials from:

  1. provider.config.credentials
  2. Provider-specific env:
  3. GOOGLE_DOCS_CREDENTIALS (google_docs)
  4. GOOGLE_SHEETS_CREDENTIALS (google_sheets)
  5. GOOGLE_SLIDEFLOW_CREDENTIALS (shared fallback)

Credential value can be:

  • Path to service-account JSON
  • Raw JSON payload

Recommended: use environment variables in CI and avoid storing secrets in repo files.

Required scopes

Google Slides provider scopes:

  • https://www.googleapis.com/auth/presentations
  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.file

Google Docs provider scopes:

  • https://www.googleapis.com/auth/documents
  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.file

Google Sheets provider scopes:

  • https://www.googleapis.com/auth/spreadsheets
  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.file

Databricks auth

Databricks connectors require:

  • DATABRICKS_HOST
  • DATABRICKS_HTTP_PATH
  • DATABRICKS_ACCESS_TOKEN

dbt Git access

For dbt package URLs with embedded token variable:

https://$DBT_GIT_TOKEN@github.com/org/dbt-project.git

Set DBT_GIT_TOKEN in environment, not in YAML.

Logging hygiene

  • Do not print raw credential payloads.
  • Keep logs at INFO or lower in production.
  • Use --debug only for short-lived troubleshooting sessions.
  • Built-in networked providers/connectors include a Slideflow client identifier where SDK/API support exists, improving service-side auditability.

Registry execution risk

Registry files are executable Python modules. SlideFlow loads them dynamically when --registry or registry: config paths are provided.

  • Only load registry files from trusted repositories and trusted contributors.
  • Treat registry review as code review (not data review).
  • Do not run untrusted registry files in shared CI runners with broad secrets.
  • Prefer least-privilege CI secrets for runs that execute registry code.

CI security posture

The repository includes a dedicated Audit workflow that runs:

  • dependency audit (pip-audit)
  • static security scan (bandit)

Both reports are uploaded as artifacts for triage.

Audit enforcement policy:

  • Audit findings are advisory for all events (pull requests, pushes, schedules).
  • Findings are surfaced as warnings and uploaded artifacts for triage follow-up.
  • Audit workflow is intentionally non-blocking until baseline findings are reduced and a blocking threshold policy is adopted.

Action pinning policy:

  • GitHub-maintained actions are version-pinned by major (@vN) and updated intentionally.
  • Third-party actions follow the same major-version pinning policy with periodic review during release prep.

Use OIDC trusted publishing instead of API tokens.

  1. In PyPI project settings, add a trusted publisher:
  2. Owner: joe-broadhead
  3. Repository: slideflow
  4. Workflow: release.yml
  5. Environment: pypi
  6. In GitHub repo settings, create environment pypi.
  7. Add required reviewers for release protection if needed.
  8. Keep id-token: write enabled in release workflow permissions.

Hardening checklist

  • Secrets only via environment or secret manager
  • No credentials committed to Git
  • Pre-commit hooks installed and passing (uv run pre-commit run --all-files)
  • slideflow validate enforced in CI before build/release
  • Audit workflow reviewed weekly
  • Release branch protections enabled