Bandit is a tool designed to find common security issues in Python code.

Python Code Quality Authority

Last update: Dec 31, 2022

Overview

A security linter from PyCQA

Free software: Apache license
Documentation: https://bandit.readthedocs.io/en/latest/
Source: https://github.com/PyCQA/bandit
Bugs: https://github.com/PyCQA/bandit/issues
Contributing: https://github.com/PyCQA/bandit/blob/master/CONTRIBUTING.md

Overview

Bandit is a tool designed to find common security issues in Python code. To do this Bandit processes each file, builds an AST from it, and runs appropriate plugins against the AST nodes. Once Bandit has finished scanning all the files it generates a report.

Bandit was originally developed within the OpenStack Security Project and later rehomed to PyCQA.

Installation

Bandit is distributed on PyPI. The best way to install it is with pip:

Create a virtual environment (optional):

virtualenv bandit-env
# Or if you're working with a Python 3 project
python3 -m venv bandit-env
# And activate it:
source bandit-env/bin/activate

Install Bandit:

pip install bandit
# Or if you're working with a Python 3 project
pip3 install bandit

Run Bandit:

bandit -r path/to/your/code

Bandit can also be installed from source. To do so, download the source tarball from PyPI, then install it:

python setup.py install

Usage

Example usage across a code tree:

bandit -r ~/your_repos/project

Example usage across the examples/ directory, showing three lines of context and only reporting on the high-severity issues:

bandit examples/*.py -n 3 -lll

Bandit can be run with profiles. To run Bandit against the examples directory using only the plugins listed in the ShellInjection profile:

bandit examples/*.py -p ShellInjection

Bandit also supports passing lines of code to scan using standard input. To run Bandit with standard input:

cat examples/imports.py | bandit -

Usage:

$ bandit -h
usage: bandit [-h] [-r] [-a {file,vuln}] [-n CONTEXT_LINES] [-c CONFIG_FILE]
              [-p PROFILE] [-t TESTS] [-s SKIPS] [-l] [-i]
              [-f {csv,custom,html,json,screen,txt,xml,yaml}]
              [--msg-template MSG_TEMPLATE] [-o [OUTPUT_FILE]] [-v] [-d] [-q]
              [--ignore-nosec] [-x EXCLUDED_PATHS] [-b BASELINE]
              [--ini INI_PATH] [--exit-zero] [--version]
              [targets [targets ...]]

Bandit - a Python source code security analyzer

positional arguments:
  targets               source file(s) or directory(s) to be tested

optional arguments:
  -h, --help            show this help message and exit
  -r, --recursive       find and process files in subdirectories
  -a {file,vuln}, --aggregate {file,vuln}
                        aggregate output by vulnerability (default) or by
                        filename
  -n CONTEXT_LINES, --number CONTEXT_LINES
                        maximum number of code lines to output for each issue
  -c CONFIG_FILE, --configfile CONFIG_FILE
                        optional config file to use for selecting plugins and
                        overriding defaults
  -p PROFILE, --profile PROFILE
                        profile to use (defaults to executing all tests)
  -t TESTS, --tests TESTS
                        comma-separated list of test IDs to run
  -s SKIPS, --skip SKIPS
                        comma-separated list of test IDs to skip
  -l, --level           report only issues of a given severity level or higher
                        (-l for LOW, -ll for MEDIUM, -lll for HIGH)
  -i, --confidence      report only issues of a given confidence level or
                        higher (-i for LOW, -ii for MEDIUM, -iii for HIGH)
  -f {csv,custom,html,json,screen,txt,xml,yaml}, --format {csv,custom,html,json,screen,txt,xml,yaml}
                        specify output format
  --msg-template MSG_TEMPLATE
                        specify output message template (only usable with
                        --format custom), see CUSTOM FORMAT section for list
                        of available values
  -o [OUTPUT_FILE], --output [OUTPUT_FILE]
                        write report to filename
  -v, --verbose         output extra information like excluded and included
                        files
  -d, --debug           turn on debug mode
  -q, --quiet, --silent
                        only show output in the case of an error
  --ignore-nosec        do not skip lines with # nosec comments
  -x EXCLUDED_PATHS, --exclude EXCLUDED_PATHS
                        comma-separated list of paths (glob patterns
                        supported) to exclude from scan (note that these are
                        in addition to the excluded paths provided in the
                        config file) (default:
                        .svn,CVS,.bzr,.hg,.git,__pycache__,.tox,.eggs,*.egg)
  -b BASELINE, --baseline BASELINE
                        path of a baseline report to compare against (only
                        JSON-formatted files are accepted)
  --ini INI_PATH        path to a .bandit file that supplies command line
                        arguments
  --exit-zero           exit with 0, even with results found
  --version             show program's version number and exit

CUSTOM FORMATTING
-----------------

Available tags:

    {abspath}, {relpath}, {line}, {col}, {test_id},
    {severity}, {msg}, {confidence}, {range}

Example usage:

    Default template:
    bandit -r examples/ --format custom --msg-template \
    "{abspath}:{line}: {test_id}[bandit]: {severity}: {msg}"

    Provides same output as:
    bandit -r examples/ --format custom

    Tags can also be formatted in python string.format() style:
    bandit -r examples/ --format custom --msg-template \
    "{relpath:20.20s}: {line:03}: {test_id:^8}: DEFECT: {msg:>20}"

    See python documentation for more information about formatting style:
    https://docs.python.org/3/library/string.html

The following tests were discovered and loaded:
-----------------------------------------------

  B101  assert_used
  B102  exec_used
  B103  set_bad_file_permissions
  B104  hardcoded_bind_all_interfaces
  B105  hardcoded_password_string
  B106  hardcoded_password_funcarg
  B107  hardcoded_password_default
  B108  hardcoded_tmp_directory
  B110  try_except_pass
  B112  try_except_continue
  B201  flask_debug_true
  B301  pickle
  B302  marshal
  B303  md5
  B304  ciphers
  B305  cipher_modes
  B306  mktemp_q
  B307  eval
  B308  mark_safe
  B309  httpsconnection
  B310  urllib_urlopen
  B311  random
  B312  telnetlib
  B313  xml_bad_cElementTree
  B314  xml_bad_ElementTree
  B315  xml_bad_expatreader
  B316  xml_bad_expatbuilder
  B317  xml_bad_sax
  B318  xml_bad_minidom
  B319  xml_bad_pulldom
  B320  xml_bad_etree
  B321  ftplib
  B323  unverified_context
  B324  hashlib_new_insecure_functions
  B325  tempnam
  B401  import_telnetlib
  B402  import_ftplib
  B403  import_pickle
  B404  import_subprocess
  B405  import_xml_etree
  B406  import_xml_sax
  B407  import_xml_expat
  B408  import_xml_minidom
  B409  import_xml_pulldom
  B410  import_lxml
  B411  import_xmlrpclib
  B412  import_httpoxy
  B413  import_pycrypto
  B501  request_with_no_cert_validation
  B502  ssl_with_bad_version
  B503  ssl_with_bad_defaults
  B504  ssl_with_no_version
  B505  weak_cryptographic_key
  B506  yaml_load
  B507  ssh_no_host_key_verification
  B601  paramiko_calls
  B602  subprocess_popen_with_shell_equals_true
  B603  subprocess_without_shell_equals_true
  B604  any_other_function_with_shell_equals_true
  B605  start_process_with_a_shell
  B606  start_process_with_no_shell
  B607  start_process_with_partial_path
  B608  hardcoded_sql_expressions
  B609  linux_commands_wildcard_injection
  B610  django_extra_used
  B611  django_rawsql_used
  B701  jinja2_autoescape_false
  B702  use_of_mako_templates
  B703  django_mark_safe

Baseline

Bandit allows specifying the path of a baseline report to compare against using the base line argument (i.e. -b BASELINE or --baseline BASELINE).

bandit -b BASELINE

This is useful for ignoring known vulnerabilities that you believe are non-issues (e.g. a cleartext password in a unit test). To generate a baseline report simply run Bandit with the output format set to json (only JSON-formatted files are accepted as a baseline) and output file path specified:

bandit -f json -o PATH_TO_OUTPUT_FILE

Version control integration

Use pre-commit. Once you have it installed, add this to the .pre-commit-config.yaml in your repository (be sure to update rev to point to a real git tag/revision!):

repos:
-   repo: https://github.com/PyCQA/bandit
    rev: '' # Update me!
    hooks:
    - id: bandit

Then run pre-commit install and you're ready to go.

Configuration

An optional config file may be supplied and may include:

lists of tests which should or shouldn't be run
exclude_dirs - sections of the path, that if matched, will be excluded from scanning (glob patterns supported)
overridden plugin settings - may provide different settings for some plugins

Per Project Command Line Args

Projects may include a .bandit file that specifies command line arguments that should be supplied for that project. The currently supported arguments are:

targets: comma separated list of target dirs/files to run bandit on

exclude: comma separated list of excluded paths

skips: comma separated list of tests to skip

tests: comma separated list of tests to run

To use this, put a .bandit file in your project's directory. For example:

[bandit]
exclude: /test

[bandit]
tests: B101,B102,B301

Exclusions

In the event that a line of code triggers a Bandit issue, but that the line has been reviewed and the issue is a false positive or acceptable for some other reason, the line can be marked with a # nosec and any results associated with it will not be reported.

For example, although this line may cause Bandit to report a potential security issue, it will not be reported:

self.process = subprocess.Popen('/bin/echo', shell=True)  # nosec

Vulnerability Tests

Vulnerability tests or "plugins" are defined in files in the plugins directory.

Tests are written in Python and are autodiscovered from the plugins directory. Each test can examine one or more type of Python statements. Tests are marked with the types of Python statements they examine (for example: function call, string, import, etc).

Tests are executed by the BanditNodeVisitor object as it visits each node in the AST.

Test results are managed in the Manager and aggregated for output at the completion of a test run through the method output_result from Manager instance.

Writing Tests

To write a test:

Identify a vulnerability to build a test for, and create a new file in examples/ that contains one or more cases of that vulnerability.
Consider the vulnerability you're testing for, mark the function with one or more of the appropriate decorators: - @checks('Call') - @checks('Import', 'ImportFrom') - @checks('Str')
Create a new Python source file to contain your test, you can reference existing tests for examples.
The function that you create should take a parameter "context" which is an instance of the context class you can query for information about the current element being examined. You can also get the raw AST node for more advanced use cases. Please see the context.py file for more.
Extend your Bandit configuration file as needed to support your new test.
Execute Bandit against the test file you defined in examples/ and ensure that it detects the vulnerability. Consider variations on how this vulnerability might present itself and extend the example file and the test function accordingly.

Extending Bandit

Bandit allows users to write and register extensions for checks and formatters. Bandit will load plugins from two entry-points:

bandit.formatters
bandit.plugins

Formatters need to accept 5 things:

manager: an instance of bandit manager
fileobj: the output file object, which may be sys.stdout
sev_level : Filtering severity level
conf_level: Filtering confidence level
lines=-1: number of lines to report

Plugins tend to take advantage of the bandit.checks decorator which allows the author to register a check for a particular type of AST node. For example

@bandit.checks('Call')
def prohibit_unsafe_deserialization(context):
    if 'unsafe_load' in context.call_function_name_qual:
        return bandit.Issue(
            severity=bandit.HIGH,
            confidence=bandit.HIGH,
            text="Unsafe deserialization detected."
        )

To register your plugin, you have two options:

If you're using setuptools directly, add something like the following to your setup call:

# If you have an imaginary bson formatter in the bandit_bson module
# and a function called `formatter`.
entry_points={'bandit.formatters': ['bson = bandit_bson:formatter']}
# Or a check for using mako templates in bandit_mako that
entry_points={'bandit.plugins': ['mako = bandit_mako']}

If you're using pbr, add something like the following to your setup.cfg file:

[entry_points]
bandit.formatters =
    bson = bandit_bson:formatter
bandit.plugins =
    mako = bandit_mako

Contributing

Follow our Contributing file: https://github.com/PyCQA/bandit/blob/master/CONTRIBUTING.md

Reporting Bugs

Bugs should be reported on github. To file a bug against Bandit, visit: https://github.com/PyCQA/bandit/issues

Show Your Style

Use our badge in your project's README!

using Markdown:

[![security: bandit](https://img.shields.io/badge/security-bandit-yellow.svg)](https://github.com/PyCQA/bandit)

using RST:

.. image:: https://img.shields.io/badge/security-bandit-yellow.svg
    :target: https://github.com/PyCQA/bandit
    :alt: Security Status

Under Which Version of Python Should I Install Bandit?

The answer to this question depends on the project(s) you will be running Bandit against. If your project is only compatible with Python 3.5, you should install Bandit to run under Python 3.5. If your project is only compatible with Python 3.8, then use 3.8 respectively. If your project supports both, you could run Bandit with both versions but you don't have to.

Bandit uses the ast module from Python's standard library in order to analyze your Python code. The ast module is only able to parse Python code that is valid in the version of the interpreter from which it is imported. In other words, if you try to use Python 2.7's ast module to parse code written for 3.5 that uses, for example, yield from with asyncio, then you'll have syntax errors that will prevent Bandit from working properly. Alternatively, if you are relying on 2.7's octal notation of 0777 then you'll have a syntax error if you run Bandit on 3.x.

References

Bandit docs: https://bandit.readthedocs.io/en/latest/

Python AST module documentation: https://docs.python.org/3/library/ast.html

Green Tree Snakes - the missing Python AST docs: https://greentreesnakes.readthedocs.org/en/latest/

Documentation of the various types of AST nodes that Bandit currently covers or could be extended to cover: https://greentreesnakes.readthedocs.org/en/latest/nodes.html

Comments

PEP-518 support: configure bandit via pyproject.toml
Thank you for cool lib.

Added support for configuring via pyproject.toml (tool.bandit section). Closes #212, because now all projects have moved from setup.cfg to pyproject.toml.

Parse files the end with .toml as toml and get the tool.bandit section.

Tests included (just inherited from YAML config tests).

Documentation updated, config example included into docs too.

Close #550 as well
opened by orsinium 28
Bandit 1.6.0 no longer respects excluded directories
Describe the bug Prior to the bandit 1.6.0 release, I was using bandit like so:

bandit -r . -x ./mymodule1/tests/,./mymodule2/tests/

However, with bandit 1.6.0 the ./mymodule1/tests/ and ./mymodule2/tests/ directories are included in the results. I have confirmed that you can exclude individual files still, just not directories.

To Reproduce Steps to reproduce the behavior:

Create a directory with a vulnerability in it somewhere

Run bandir -r . -x ./your-new-dir/

See vulnerability results that should be excluded

Expected behavior Bandit should be excluding the directories entirely that are passed as args to the -x flag.

Bandit version

bandit 1.6.0 python version = 3.6.5 (default, Jun 17 2018, 12:13:06) [GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)]
bug
opened by mattjegan 25
Exclude paths in config file ignored if passing specific files to Bandit CLI
UPDATE: please see my below comment for an updated description of the problem.

Describe the bug When using the pre-commit hook, my excluded paths listed in .bandit are still processed by bandit.

To Reproduce Steps to reproduce the behavior:

Create a .bandit config file with exclusions. For example:
[bandit] exclude: ./node_modules/*,./tests/*

Run bandit via command line (bandit -r .), verify exclusions ignored.

Run bandit on all files via pre-commit hook: pre-commit run --all-files bandit

See that excluded files are processed by bandit

Expected behavior I expect the excluded paths to be ignored.

Bandit version

bandit 1.6.0 python version = 3.7.3 (default, May 27 2019, 05:16:50) [Clang 10.0.0 (clang-1000.10.44.4)]
bug
opened by pydolan 18
[docs] Mention `exclude_dirs` option available in TOML and YAML
As discovered in #488 (latest comments) and reported in #528.

Also attempts to improve the documentation code by aligning code block indenting replacing simple code blocks (::) with source code markup code blocks in reStructuredText.

Side Notes

Despite the name, exclude_dirs also recognizes single files, not only directories.

In the long run it may make sense to consolidate the two options exclude and exclude_dirs.
opened by bittner 12
Drop Python 2 Support
Python 2 is well beyond EOL now and will soon be removed from github's workflows

This PR seeks to remove all calls / references and tests that rely on Python 2.

Remove six imports and six.Py2 conditionals

Remove Py2 calls from github workflows

Merged example files (e.g exec-py2.py|exec-py3.py > exec.py)

Removed py2 env from setuptools

Removed py2 env from tox

Resolves: #584
opened by lukehinds 11
Support for pyproject.toml as config file format
PEP 518 specifies a config format that can be exploited by dev tools through designated sections, given their pyPI domain. The toml format is very basic and should allow a simple 1 to 1 mapping of the existing config, since it is more on the minimal side. Given the following .bandit file:

[bandit] targets: src skips: B101,B110

Its section in a pyproject.toml would look like this:

[tool.bandit] targets = ["src"] skips = ["B101", "B110"]

The sole gain of supporting this would be to reduce the amount of additional config files needed for using bandit in a python project that uses PEP 518 in some way from 1 to 0.

Discussions on other tools regarding the same issue:

https://github.com/python/mypy/issues/5205

https://github.com/pytest-dev/pytest/issues/1556

https://github.com/nedbat/coveragepy/issues/664

enhancement
opened by a-recknagel 11
degraded performance in 1.6.0 release

Describe the bug

I have seen a performance decrease in version 1.6.0. I a member of FussyFox and we run thousands of bandit checks a day. I see an increase in timeouts (200s limit) since I upgraded the stack to the 1.6.0 release.

My best guess, it's this commit 7c4b9fa8b8d980a27c53000eb1961d436da7b223 I will further investigate the issue.

The 200-second cap is because the sub process times out. The execution time would be even longer.
bug

opened by codingjoe 11
Logo Proposal: Bandit

Hey, I'm graphic designer and my aim is supporting open source projects and make my portfolio better. So, I can contribute on your project with making logo design. I am waiting your feedback! Have a nice day! :)

Best Regards, Baran Pirincal Visual Communication Designer
enhancement

opened by baranpirincal 11

Tests do not load on Python 3.7 with `importlib-metadata` 5.0.0 and `stevedore` 3.5.1

Describe the bug

Jump to workaround

While the release of stevedore 3.5.1 appears to have resolved the problems reported in #951 and #953 I am seeing a new problem when using the following on Python 3.7:

$ pip list | grep "bandit\|importlib-metadata\|stevedore"
bandit               1.7.4
importlib-metadata   5.0.0
stevedore            3.5.1

I get the following:

$ bandit --version
bandit 1.7.4
  python version = 3.7.15 (default, Oct 14 2022, 02:08:07) [GCC 11.2.0]
$ bandit -r .
[main]  INFO    profile include tests: None
[main]  INFO    profile exclude tests: None
[main]  INFO    cli include tests: None
[main]  INFO    cli exclude tests: None
[main]  INFO    running on Python 3.7.15
[main]  ERROR   No tests would be run, please check the profile.

In comparison in the same directory:

$ pip list | grep "bandit\|importlib-metadata\|stevedore"
bandit               1.7.4
importlib-metadata   4.13.0
stevedore            3.5.1
$ bandit --version
bandit 1.7.4
  python version = 3.7.15 (default, Oct 14 2022, 02:08:07) [GCC 11.2.0]
$ bandit -r .
[main]  INFO    profile include tests: None
[main]  INFO    profile exclude tests: None
[main]  INFO    cli include tests: None
[main]  INFO    cli exclude tests: None
[main]  INFO    running on Python 3.7.15
Run started:2022-10-14 18:09:03.392403

Test results:
        No issues identified.

Code scanned:
        Total lines of code: 1949
        Total lines skipped (#nosec): 0

Run metrics:
        Total issues (by severity):
                Undefined: 0
                Low: 0
                Medium: 0
                High: 0
        Total issues (by confidence):
                Undefined: 0
                Low: 0
                Medium: 0
                High: 0
Files skipped (0):

Workaround

Pinning to importlib-metadata<5 works. If you are using bandit in a pre-commit configuration you can add the following to your hook configuration:

additional_dependencies:
  - importlib-metadata<5

such that a full hook configuration looks something like:

- repo: https://github.com/PyCQA/bandit
    rev: 1.7.4
    hooks:
      - id: bandit
        name: bandit
        additional_dependencies:
          - importlib-metadata<5

Reproduction steps

1. Install `bandit` into a Python 3.7 environment.
2. Attempt to use `bandit` to check code.

Expected behavior

bandit would successfully load tests and use them.

Bandit version

1.7.4 (Default)

Python version

3.7

Additional context

No response

bug

opened by mcdonnnj 10

Add skip configuration to assert_used
Adding this configuration allows the user to skip the assert_used check against some files. This is useful because asserts are very common in test files when using pytest.

Specifying this configuration:

assert_used: skips: ['test.py$', '^test']

would skip all asserts against a test file.

Resolves #346

Thank you for the awesome project and your time!
opened by wilbertom 10
Rename blacklist to banlist within internal modules and documentation
This proposed change replaces the use of the term "blacklist" with a replacement, "banlist".

The change is mostly an internal refactoring task.

Some notes:

I have added a backward-compatibility check in the configuration loader that will patch all "blacklist" settings to "banlist".

If the user already has files that configure using the blacklist keyword, it will continue to work.

The documentation would use blocklist and not refer to blacklist at all

Could the core development team please comment on this proposal?

I would gladly make amendments, continue and extend the testing to have this change merged as I believe it would benefit the Python community not to use the term blacklist in such an important project as bandit.

@ericwb @lukehinds @ehooo @viraptor
opened by tonybaloney 10

some SQL injections not detected

Describe the bug

None of the lines get reported, although each of the foo functions contains an SQL injection

from django.db import transaction, connections, connection


def foo(booking_id: str):
    with transaction.atomic():
        connections['default'].cursor().execute(f'SELECT pg_advisory_xact_lock({booking_id})')


def foo2(booking_id: str):
    with transaction.atomic():
        connection.cursor().execute(f'SELECT pg_advisory_xact_lock({booking_id})')


def foo3(booking_id: str):
    with connection.cursor() as cursor:
        cursor.execute(f'SELECT pg_advisory_xact_lock({booking_id})')


def foo4(booking_id: str):
    with connection.cursor() as cursor:
        cursor.execute(f'SELECT pg_advisory_xact_lock({booking_id}) FROM table')


def foo5(col: str):
    with connection.cursor() as cursor:
        cursor.execute(f'select {col} from table')


def foo6(col: str):
    q = f'select {col} from table'


def foo7(col, booking_id):
    q = f'select {col} from table where id = {booking_id}'

Bandit output:

bandit -r ./injection.py
[main]	INFO	profile include tests: None
[main]	INFO	profile exclude tests: None
[main]	INFO	cli include tests: None
[main]	INFO	cli exclude tests: None
[main]	INFO	running on Python 3.9.14
Run started:2022-12-16 08:57:06.964396

Test results:
	No issues identified.

Code scanned:
	Total lines of code: 20
	Total lines skipped (#nosec): 0

Run metrics:
	Total issues (by severity):
		Undefined: 0
		Low: 0
		Medium: 0
		High: 0
	Total issues (by confidence):
		Undefined: 0
		Low: 0
		Medium: 0
		High: 0
Files skipped (0):

Bandit version: bandit==1.7.4