Does an import at the top of an Airflow DAG file run code?

Yes. A DAG file is an ordinary Python program, and Airflow evaluates it to discover your DAGs. Any import at the top of the file executes that package's module code at parse time, outside any task. A newly added dependency is therefore trusted code on the parsing path, not only on the worker.

Why this matters for dependency review

Most teams think of a dependency as something a task uses when it runs. For top-level imports, the code runs earlier and more often. The Airflow best practices page says top-level imports "might take surprisingly a lot of time and they can generate a lot of overhead", and it advises keeping top-level code minimal. Its guidance is that you should not run database access, heavy computation or networking at the top level.

The same page offers a quick test to see what counts as top-level code: add print statements and run the file with Python. That test makes the point. If running the file with Python executes something, then so does parsing it.

Two consequences follow:

• Import side effects run on whichever component parses DAG files, and they run repeatedly, not once per task.
• A package that does work on import (reading environment variables, opening connections, phoning home for configuration) does that work from a place that often holds broader access than a single task worker.

The second point is a design caution, not a claim about any one package. Check what your own environment gives the parsing component, because that varies by deployment.

Move imports into the task

The docs recommend moving expensive imports inside the callable that needs them. For security this has a second benefit: the package is only loaded in the task that uses it, which narrows where the code runs.

from airflow.sdk import dag, task

@dag
def example():
    @task
    def build_report():
        import pandas as pd   # loaded only when this task runs
        return pd.DataFrame().shape

    build_report()

example()

A review checklist for DAG pull requests

1. List every new top-level import in the diff.
2. For each one, ask whether it must be at the top. Most can move into a task.
3. Check that no top-level line makes a network call, reads a secret, or touches the metadata database.
4. Confirm the package is pinned in your requirements or constraints file.
5. Run the file locally with Python and watch for output or delays.

Where a scanner helps

A dependency scanner tells you whether an imported package has known advisories. It does not tell you whether the import runs on the scheduler path. Reachability analysis can narrow that for vulnerable functions, but the placement decision, top-level versus inside a task, is a code review habit.

Safeguard's dependency scanning and reachability analysis can flag vulnerable packages and whether your code reaches the affected function, which helps you rank fixes. You can try it with the free scan at https://gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen. Notice how findings in code paths that are never called drop down the list.

Quick check

Sources

• Airflow best practices

Last reviewed: 19 October 2026.