Difference between revisions of "Security/Projects/Bandit"
(→Bandit Baseline Gate) |
Eric Brown (talk | contribs) m |
||
Line 27: | Line 27: | ||
This option works well for projects that already have clean Bandit runs. To set up a full run Bandit gate for an OpenStack project, follow these steps: | This option works well for projects that already have clean Bandit runs. To set up a full run Bandit gate for an OpenStack project, follow these steps: | ||
− | # (optional) Add a Bandit config for your project. This determines what bandit checks will run on the project. Some checks might not make sense for the project, or the test doesn't pass when you first enable it | + | # (optional) Add a Bandit config for your project. This determines what bandit checks will run on the project. Some checks might not make sense for the project, or the test doesn't pass when you first enable it. |
# Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot. | # Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot. | ||
# Add a tox environment to run Bandit. Keystone's is here: [https://review.openstack.org/#/c/171772/2/tox.ini tox.ini] in the [testenv:bandit] section | # Add a tox environment to run Bandit. Keystone's is here: [https://review.openstack.org/#/c/171772/2/tox.ini tox.ini] in the [testenv:bandit] section | ||
Line 41: | Line 41: | ||
This is the best option for projects which may have some legacy Bandit findings. Just because a project has some pre-existing security issues doesn't mean Bandit can't help prevent new ones! To set up a Bandit Baseline gate for an OpenStack project, follow these steps: | This is the best option for projects which may have some legacy Bandit findings. Just because a project has some pre-existing security issues doesn't mean Bandit can't help prevent new ones! To set up a Bandit Baseline gate for an OpenStack project, follow these steps: | ||
− | # (optional) Add a Bandit config for your project. This determines what bandit checks will run on the project. Some checks might not make sense for the project, or the test doesn't pass when you first enable it | + | # (optional) Add a Bandit config for your project. This determines what bandit checks will run on the project. Some checks might not make sense for the project, or the test doesn't pass when you first enable it. |
# Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot. | # Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot. | ||
# Add a tox environment to run the Bandit basline. To do this we'll add two targets: | # Add a tox environment to run the Bandit basline. To do this we'll add two targets: | ||
Line 50: | Line 50: | ||
==Profiles== | ==Profiles== | ||
− | By default Bandit runs all plugins that it finds in the plugins directory. While this may be useful for doing a thorough manual review, for use cases such as automation and gate testing, this is probably overkill. Luckily, Bandit allows a user to create profiles which run or exclude specific tests. | + | By default Bandit runs all plugins that it finds in the plugins directory. While this may be useful for doing a thorough manual review, for use cases such as automation and gate testing, this is probably overkill. Luckily, Bandit allows a user to create profiles which run or exclude specific tests. |
Once a profile has been created, you can run it by using the "-c" command line option to point to the config file which contains your profile and "-p" to point to the specific profile you'd like to use. | Once a profile has been created, you can run it by using the "-c" command line option to point to the config file which contains your profile and "-p" to point to the specific profile you'd like to use. |
Revision as of 17:46, 7 March 2016
Contents
Overview
Bandit is a security linter for Python source code, utilizing the ast module from the Python standard library.
The ast module is used to convert source code into a parsed tree of Python syntax nodes. Bandit allows users to define custom tests that are performed against those nodes. At the completion of testing, a report is generated that lists security issues identified within the target source code.
Bandit is currently a stand-alone tool which can be downloaded by end-users and run against arbitrary source code. As it matures and is proven to be useful, we see it being a possible addition to OpenStack CI gate tests with non-voting and eventually voting capabilities.
Bandit can be obtained by cloning the repository at https://git.openstack.org/openstack/bandit.git. The README.rst file contains documentation regarding installation, usage, and configuration.
Contributing
Bandit makes use of the OpenStack CI infrastructure provided through OpenStack:
- Read-only OpenStack git repository: https://github.com/openstack/bandit
- Browsable OpenStack git repository: https://git.openstack.org/cgit/openstack/bandit/
- Launchpad bug reporting and tracking: https://launchpad.net/bandit
- Gerrit endpoint for git repository: ssh://[username]@review.openstack.org:29418/openstack/bandit.git
- Gerrit reviews: https://review.openstack.org/#/q/project:openstack/bandit,n,z
An easy way to contribute is to write a plugin/test that will allow Bandit to identify more security issues. Extensions and improvements to the underlying framework are also welcomed, although we'll be attempting to maintain stability in the interface that is presented to plugins.
See Development Workflow for information on the general contribution/review workflow.
Gate Testing with Bandit
Bandit can help maintain the security of OpenStack projects when it's used as a gate test. Projects such as Keystone have created a gate test which runs Bandit to ensure that common security code mistakes are not introduced when code is modified. New: you now have two ways to set up a Bandit gate and we'll cover the steps for both below.
Full run Bandit gate:
This option works well for projects that already have clean Bandit runs. To set up a full run Bandit gate for an OpenStack project, follow these steps:
- (optional) Add a Bandit config for your project. This determines what bandit checks will run on the project. Some checks might not make sense for the project, or the test doesn't pass when you first enable it.
- Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot.
- Add a tox environment to run Bandit. Keystone's is here: tox.ini in the [testenv:bandit] section
- Add the Bandit job to the list of jobs for your project in OpenStack Infra. Keystone implemented this change here: jenkins/jobs/projects.yaml
- Add the Bandit gate to your project section in OpenStack Infra. For an example, here is Keystone's job: zuul/layout.yaml. Note: for Keystone Bandit is currently set up as non-voting. This means that failures in Bandit won't cause Jenkins to reject the change. This has the advantage that it will never cause your change to fail, but it also doesn't allow Bandit to prevent anything. To make the Bandit check voting set "voting: true".
- Modify the "check" section of your project in OpenStack infra to run Bandit as a check. For an example see this change: Keystone add Bandit check.
- Run this way for a while and then make it voting!
Steps 1-3 should be done in one commit for your project, and steps 4-6 will be a separate commit for OpenStack Infra. If you have any questions or comments please contact tmcpeak in #openstack-security on Freenode IRC.
Bandit Baseline Gate
This is the best option for projects which may have some legacy Bandit findings. Just because a project has some pre-existing security issues doesn't mean Bandit can't help prevent new ones! To set up a Bandit Baseline gate for an OpenStack project, follow these steps:
- (optional) Add a Bandit config for your project. This determines what bandit checks will run on the project. Some checks might not make sense for the project, or the test doesn't pass when you first enable it.
- Add "bandit" (the package name on pypi) to the test-requirements.txt file. While running Bandit only actually requires the bandit package, it's easiest for now to just leave it in with the rest of the test requirements. This file lists the requirements for creating the virtual environment Bandit runs in and gets updated automatically in most projects by the OpenStack proposal bot.
- Add a tox environment to run the Bandit basline. To do this we'll add two targets:
- a standalone target "codesec" codesec tox target which is useful for developers to check their changes
- a "linters" target: linters tox target. By adding a linters target, we're extending our linters to run Bandit in addition to the normal flake8 tests.
- In both cases the arguments for 'bandit-baseline' should be identical to what you want to pass into Bandit. For example, if you created a config file above, you'll want to specify it with '-c myconfig.yaml'. In the example above we're running: 'bandit-baseline -r bandit -ll -ii' which tells Bandit (and bandit-baseline) to run scan the 'bandit' directory recursively and filter medium+ severity and confidence issues.
- Change the the OpenStack infra zuul/layout.yaml for your project to use 'python-jobs-linters' instead of 'python-jobs' like we did for the Bandit project itself here: zuul layout change example. This enables your project to use the 'linters' target in your python-jobs gate instead of just flake8. Note: if you do this you'll have a voting Bandit gate. You should make sure you're comfortable with Bandit and how it works before changing this.
Profiles
By default Bandit runs all plugins that it finds in the plugins directory. While this may be useful for doing a thorough manual review, for use cases such as automation and gate testing, this is probably overkill. Luckily, Bandit allows a user to create profiles which run or exclude specific tests.
Once a profile has been created, you can run it by using the "-c" command line option to point to the config file which contains your profile and "-p" to point to the specific profile you'd like to use.
TODO
TODO is now tracked using blueprints in Launchpad: https://blueprints.launchpad.net/bandit
Projects using bandit
Project name | Disabled checks | Voting gate? | Comments |
---|---|---|---|
oslo.messaging |
|
No | https://review.openstack.org/239437 |
oslo.utils |
|
No | https://review.openstack.org/239666 |
Team
Bandit is a tool from the OpenStack Security project.
Core project team:
- Jamie Finnigan (chair6)
- Travis McPeak (tmcpeak)
- Tim Kelsey (tkelsey)
- Eric Brown (browne)
- Ian Cordasco (sigmavirus24)
- Stan Pitucha (viraptor)