Secure an Airflow Git Dag bundle by protecting the branch Airflow tracks, keeping repository credentials in a connection instead of bundle settings, and leaving versioning on so every run records its commit. Whoever can push to the tracked ref can run code on your workers.
What a Dag bundle is
The Airflow docs define a Dag bundle as a collection of one or more Dags plus their supporting files. A local bundle points at a directory and does not support versioning, so tasks always run the latest code. A Git bundle fetches Dags from a repository and does support versioning.
A Git bundle is configured with a tracking reference, which can be a branch, a tag or a commit SHA. Optional settings include a connection id for credentials, a repository URL, a subdirectory and sparse directories.
Why it is a security boundary
Dag files run as code. The Airflow security model says Airflow does not sandbox Dag author code. So the tracked ref is effectively a deployment pipeline: a push to it becomes code execution on your workers after the next refresh.
Checklist
- Protect the tracked branch. Require pull request review, restrict force pushes, and limit who can merge.
- Consider tracking a tag or commit for production, so changes need a deliberate promotion rather than any merge.
- Keep versioning enabled. The docs say each Dag run records the Git commit it was created with, so a rerun can use the exact same code. Disabling bundle versioning removes that trail.
- Do not put credentials in bundle settings. The docs say to use a connection and a secrets backend instead.
- Mind config exposure. Bundle settings are exposed through the config API when config exposure is enabled, and anyone who can read the config sees those values verbatim.
- Narrow the checkout. Use the subdirectory or sparse directory settings so the processor sees only what it needs.
- Use a deploy credential with read only scope, tied to a service identity rather than a person's account.
- Decide the refresh interval deliberately. A short interval speeds up mistakes as well as fixes.
- Scan the repository for dependency changes and committed secrets in your normal review flow.
- Check impersonation settings. If you use run as user, the docs say shared group permissions and an appropriate umask are needed, and describe this as a temporary approach.
Dev versus production
Local bundles are fine for development. In production, a local directory without versioning means no record of which code ran. Prefer a versioned Git bundle.
Quick check
Where should the repository token live?
In an Airflow connection referenced by the bundle, with a secrets backend. The docs say not to put credentials in bundle settings.
Does a Git bundle record what code ran?
Yes, when versioning is on. Each Dag run records its commit.
Safeguard policies and gates can check dependency changes in a Dag repository on each pull request. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
