Sure, pythons can be dangerous in real life — but vulnerabilities in your Python code can bite, too.

When Kevin London, principal full stack engineer at Chow Now, was on the lookout for examples of dangerous Python functions for a talk, he came across Bandit.

Bandit is a stand-alone tool that helps analyze the security of Python source code by checking for common flaws. A security linter, Bandit uses the ast module from the Python standard library. It’s the handiwork of the OpenStack Security Group, and you can try it out by cloning the repository at https://git.openstack.org/openstack/bandit.git or check out the README.rst file, which contains documentation on installation, usage and configuration.

Intrigued by what he saw, London later gave another talk titled “Finding Vulnerabilities with Bandit,” For that talk, he ran an experiment with Bandit, finding that of the 16 open-source Python projects he scanned, 11 had a potential security issues plus nine fixes/pull requests and another six issues.

“I did not expect the results I found, no,” London told Superuser over email. “I chose popular projects and I assumed that all the vulnerabilities would have been found already by the nature of having so many eyes on the project. I had an illusion of security and safety. I think that’s why I felt surprised by how common security issues were in these projects.”

What’s next

London kept rooting around with Bandit and filed a few items he’d hoped to see in future versions — both of which were later incorporated.

“One of the cool things we’ve noticed while working on Bandit is that people play with it and then come up with some really great ideas for improvement or new features,” says Travis McPeak, security architect at Hewlett-Packard Helion and member of the OpenStack security team. In London’s case, McPeak says both of those “awesome ideas" were implemented within a month or so. “We love to see this level of participation — it leads to really cool enhancements, so please keep it coming.”

London also spoke to few appsec professionals who mentioned that one of the challenges they found with Bandit is the signal-to-noise ratio for real projects. “They want to get Bandit, or a tool like it, to a place where they can give it to developers and, for them, it’s not there yet,” he says.

McPeak responds that Bandit is designed to be useful for at least a few different workflows: penetration testing, developers, and automated gate testing.

“Although these are all security related uses, they are different at least in regards to false-positive vs. false-negative tolerance. For example, for the penetration testers workflow, it’s pretty easy to skim through what are obviously false positives but you really don’t want to miss any potentially good leads. Gate testing, on the other extreme, is a workflow where you really want to be sure about all of the issues you find.”

So the security team designed mechanisms to make this easier: filtering and profiles. Filtering allows a quick way to set a threshold of confidence and severity. In a gate, for example, we might recommend that a “medium or higher” filter be set for severity and confidence. This means Bandit will only return results where it’s fairly sure that a fairly severe issue has been found. Full customization can be done currently with profiles, although we’re in the process of revamping this to make it easier for our users, as this has been identified as a pain-point in the past. Stay-tuned for a much better way of doing this early this year, McPeak adds.

In the future, London says he’d also like to see documentation or links to documentation for every flaw found so it can be a learning experience. “That’s one of the areas where I’ve found Bandit most valuable – it’s taught me more about vulnerabilities I was not previously exposed to, such as XML attacks,” he says.

That’s fairly common feedback, McPeak says, so the team updated Bandit from 0.14 to include documentation for each plugin. One of the sections in the standard plugin documentation format includes links to relevant reading.

London says that security can be a snake in the grass.

“Security can be tricky. It’s hard to keep up with all the trends and news,” he says. “It’s challenging to read the documentation and keep it all in your head when you’re working on something. Looking at code that says something like tempfile.mktmp() doesn’t set off alarms because it looks like a perfectly sane call. Unfortunately, it’s a deprecated and dangerous function. It’s also something that projects can get right 80 times and get wrong once. It only takes one time for an attacker to use it.”

Get involved

McPeak says the team is eager to hear from anyone trying to use Bandit and encountering issues.
Bring feedback or questions on #openstack-security on irc.freenode.net or on the Openstack-dev
mailing list with the [bandit] tag.

Cover Photo // CC BY NC