> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/supported-languages/supported-languages-list/python.md).

# Python

Snyk support for Python with Snyk Code and Snyk Open Source, including SCM import, CLI and IDE testing, and supported versions

## Applicability and integration

{% hint style="info" %}
Snyk supports Python for Snyk Code and Snyk Open Source.
{% endhint %}

Available integrations:

* SCM import
* CLI and IDE: test or monitor your app

## Python for Snyk Code

For an overview of the supported security rules, visit [Python rules](https://docs.snyk.io/scan-fix-and-prevent/scan-with-snyk/snyk-code/snyk-code-security-rules/python-rules).

For Python with Snyk Code, Snyk supports Python versions up to `3.12`. Snyk Code does not support language features introduced in newer versions.

For Python with Snyk Code, Snyk supports the following file format: `.py`

Available features:

* Reports
* Interfile analysis

### Supported frameworks and libraries

For Python, Snyk supports the following frameworks and libraries:

{% columns %}
{% column %}

* AioHTTP
* aiofiles
* anthropic
* argparse
* AWS Lambda
* bottle
* CherryPy
* Django
* defusedxml
* fastapi
* fastMCP
* flask
* flask\_pymongo
* google.cloud.bigquery
* google\_generativeai
* grpcio
* httpx
* huggingface\_hub
* aiopg
* LangChain
* LangChain LiteLLM
* ldap3
* libxml
* lxml
* mistralai
* modelcontextprotocol/python-sdk
* mongoengine
  {% endcolumn %}

{% column %}

* openai
* pandas
* paramiko
* peewee
* pickle
* PyYAML
* pyca/cryptography
* pymongo
* pymssql
* pyramid
* psycopg
* python-ldap
* Python Standard Library
* requests
* sqlite3 (or pysqlite2)
* sqlalchemy
* turboGears
* urllib
* werkzeug
  {% endcolumn %}
  {% endcolumns %}

Snyk Code treats data returned through LangChain LiteLLM as untrusted, so it reports model output that reaches a sink the same way it reports any other untrusted input.

### Serverless support

Snyk Code analyzes Python functions that run on AWS Lambda. Snyk resolves handlers from AWS SAM and Serverless Framework configuration files, so it analyzes the function entry point as application code instead of skipping it.

Snyk treats the event data that reaches a handler as a taint source. Injection, path-traversal, and related findings then reflect data entering the function from the service that triggered it. Snyk supports the following triggers:

* Amazon API Gateway
* Amazon DynamoDB
* Amazon EventBridge
* Amazon Kinesis
* Amazon S3
* Amazon SNS
* Amazon SQS

Snyk treats the handler event as untrusted as a whole, rather than tracking individual fields in it.

### Directory layout

Snyk Code relies on Python projects to follow a standard directory layout for accurate analysis. Specifically, Snyk Code expects Projects to be compatible with [`setuptools` automatic discovery](https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#auto-discovery), which identifies packages and modules automatically based on the directory structure. This includes support for `__init__.py` files to ensure that symbols defined in package initialization files are imported correctly, leading to a more accurate and deeper analysis.

Snyk Code supports both `src-layout` and `flat-layout`. When your Project follows these conventions, Snyk Code can trace code effectively and provide accurate results.

### Template file analysis

Snyk Code parses template files and follows data from your application code into the template, so it reports a cross-site scripting vulnerability that becomes exploitable only where the template renders its output.

For Python, Snyk Code supports the following template engines:

* Jinja2

For file extensions and the full set of supported language and template engine combinations, visit [Template file analysis](/supported-languages/technical-specifications-and-guidance.md#template-file-analysis).

## Python for Snyk Open Source

{% hint style="info" %}
Some Python Projects can contain dependencies that require specific versions of Python. Therefore, the version of Python used when scanning can affect the dependency tree that Snyk generates.
{% endhint %}

For Python with Snyk Open Source, Snyk supports the following Python versions: `2.7`, `3.7`, `3.8`, `3.9`, `3.10`, `3.11`, `3.12`, `3.13`, `3.14`, `3.15`

### Supported package managers and registries

* Supported package managers: [pip](https://pypi.org/project/pip/), [Poetry](https://python-poetry.org/), [Pipenv](https://pipenv.pypa.io/en/latest/), and setup.py. Support for [uv](/supported-languages/supported-languages-list/python/support-for-uv.md) is in Early Access and available only with Enterprise plans.
* Supported package registry: [pypi.org](https://pypi.org/)

For Pipenv Projects, Snyk uses Python version information specified in each `Pipfile` to choose the major and minor versions to use in scanning, for example:

```python
[requires]
python_version = "3.8"
```

Snyk ignores specific patch versions and uses a recent patch version from each series.

Snyk defaults to Python `3.10` if the `Pipfile` contains:

* No Python version information
* Only a major version
* An unsupported version

For Poetry Projects, you do not need to specify the Python version. Poetry files contain sufficient information to build a full dependency tree without running native tooling.

### Supported file formats

* For Poetry: `pyproject.toml` and `poetry.lock`
* For pip: `requirements.txt`
* For Pipenv: `Pipfile` and `Pipfile.lock`
* For setup.py: `setup.py`

### Available features

* Automatic and manual Fix PRs (supported only for pip)
* License scanning
* Reports
* Test your app's SBOM and packages using `pkg:pypi` PURLs through the [SBOM test](https://docs.snyk.io/developer-tools/snyk-cli/snyk-cli/commands/sbom-test) CLI command

{% hint style="info" %}
Depending on your plan, some features may not be available. For more information, visit [plans and pricing](https://snyk.io/plans/).
{% endhint %}

### IDE and CI/CD support

If you use a supported IDE to write Python, you must add some configurations to scan Python manifest files properly.

To scan your Projects, you must first install the relevant package manager and ensure that your Project contains the supported manifest files.

Python packages that are operating system-specific and not supported by Linux can be incompatible with Snyk SCM scans and cause errors.

#### Virtual environment configuration

If you use a virtual environment, you must add the following information:

1. In your Snyk integration settings, locate the **Additional Options** field.
2. Add the `PYTHON_PATH` to this field, for example `--command=.venv/bin/python`.

By default, the Snyk IDE integration looks for a `*req*.txt` file in the root of the Project as it is seen in the IDE.

#### Scan multiple directories

If you have manifest files in other directories in the root of the Project, Snyk cannot identify them unless you direct it to.

In your Snyk integration settings, locate the **Additional Options** field. Enable a recursive search and add the `--all-projects` option in the **Additional Options** field.

{% hint style="warning" %}
If each directory needs a different virtual environment, the Snyk scan can fail because it uses a single virtual environment for dependency detection. In such cases, Snyk recommends using the CLI or SCM integration instead of an IDE to gather vulnerability details for all dependencies in each Project directory.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.snyk.io/supported-languages/supported-languages-list/python.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.