Bandit with Tim Kelsey, Travis McPeak, and Eric Brown

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

For details on how to support the show, you can visit our site at python podcast.com.

Linode is sponsoring us this week. Check them out at linode.com/podcastinet,

and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. And they just doubled the RAM for their introductory level servers, so that $20 will get you even more performance.

We are also sponsored by Sentry this week. Stop hoping your users will report bugs. Sentry's real time tracking gives you insight into production deployments and information to reproduce and fix crashes.

Check them out at getcentury.com,

and use the code podcast and it at sign up to get a $50 credit.

You can also visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch. To help other people find the show, you can leave a review on iTunes or Google Play Music, and tell your friends and coworkers.

And You can also join our forum at discourse.pythonpodcast.com

for your opportunity to find out about upcoming guests, suggest questions, propose show ideas, and interact with other listeners.

And your host as usual is Tobias Macy. Today, we're interviewing Tim Kelsey, Eric Brown, and Travis McPeek about the Bandit project, which is a static analysis engine for finding security vulnerabilities in your Python code. So could you each introduce yourselves? How about you go first, Eric?

So I'm Eric Brown. So I work at VMware as a, senior member of technical staff in which I work,

kind of 5050 between internally a project that,

is a distribution of OpenStack

for VMware, and also upstream, I do quite a bit to various projects,

most of all Bandit, I would say. So and I've had a security background for a number of years, so that's right in line with Bandit and a lot of the security working group that were Tim and Travis and I are a part of. And is that the VMware integrated OpenStack?

Yes. It is.

Yeah. Where I work right now, we're actually in the planning phases of implementing that for our own private cloud.

Oh, nice. Very cool.

Travis, how about you go next?

Hi. I'm Travis McPeek. I'm a senior security architect for IBM Cloud. I've always been interested in security,

and OpenStack just seems like a great place to dive in and do some good work. So I got involved in that a couple of years ago.

And I've been heavily involved in the security project with Tim and Eric and, Rob Clark. And I'm really interested in using tools to find ways to make security problems go away or make them easier to deal with.

And, Tim, how about you?

Hey. So I'm Tim Kelsey.

I'm a cloud security engineer working for Hewlett Packard Enterprises.

I work pretty much the same as Eric. I split my time 5050 between internal

bits and pieces for our Helion branded OpenStack distribution.

A few other bits and bobs and upstream OpenStack contributions

across

a few different projects,

mostly involved with the OpenStack Security Group work,

Bandit, Anchor, and a few other bits and pieces as well. How did you each get introduced to Python?

Oh, so, at my previous,

job, there was motivation

to start a new project with OpenStack as a framework, and by design OpenStack is,

I don't know, like 80% Python, so that's when I had to learn it, and I really grew to love it because I

was a big Java guy for a large number of years, and I really loved

the efficiency of in the syntax of Python. I just,

kind of fell in love with it after a while.

Travis, how did you get introduced to Python?

So I was doing some security testing in a previous role. I wanted to generate packets to trigger what I thought might be an interesting problem with our packet capture reader. And so

Python, it seemed, generated a really nice opportunity to quickly throw something together and play with it. And I ended up using Scappy to to generate the packet capture

fragments that I wanted and actually did find the issue I was looking for. So ever since then, I that initial positive experience I had with Python, I really think it's a great language to prototype things, throw something together quickly, play around with ideas, and and automate a lot of stuff as well. And Tim, how about you?

So I've been using Python for quite a few years, actually.

Before I was in working in the security sector, I actually worked in computer game development,

and the studios that I started working at,

wanted to use Python for

their internal tooling, for back end servers and bits and pieces like that, which is pretty interesting and that was kind of where I got my my first introduction with it. So used it for a few that was let's see now probably a good 4 years ago or something maybe a little longer. So that was quite interesting. We actually ended up porting Python, the the virtual machine, to a number of consoles as well, and Nintendo Wii and a few others. So I've sort of I've been on both sides of Python, both the language,

itself and the CPython implementation as well.

So could 1 or all of you describe what Bandit is and what the inspiration was for creating it?

We do these OpenStack security mid cycles periodically, where the security project comes together. And 1 of the things we were trying to tackle is we saw that developers were consistently making the same kind of mistakes. And these mistakes were so simple that a lot of times you could find them with, like, a simple grip. You could just do a do a certain search pattern and find all the cases where somebody is setting, for example,

overly permissive file permissions.

And so we're sitting there at the mid cycle, and Jamie Finnegan, who's not on the call today, but extremely crafty guy and my ex boss and Tim's current boss, kinda just got quiet and we were we were sort of wondering, you know, what's going on with Jamie. I think at some point he left the room and came back and pulled an all nighter and came back with the initial version of Bandit, which instead of doing GREPS, was a much more elegant solution that we'll get into in a little bit.

And how did you each get involved with the project?

So back in, I think it was February of 2015,

there just happened to be a security mid cycle in the Bay Area. So I was like, oh, cool. I'll go to check this out. And that's where I met Travis, Jamie, Tim, and Rob, and many of the others, and first got exposed to Bandit, and was, like, very interested from the start because I knew there wasn't many linters out there for security wise for Python, and so I thought it had real value.

Yeah. This is actually the first security linter for Python that I've come across. I've seen some for a few other languages, but this is the first 1 for Python that I've found.

I think there might have been an older 1, like, I think, rats was another 1, but I think it's unmaintained now.

So I was just gonna say,

I sort of joined the project really very early on. So Bandit, as, Travis already mentioned, actually started life basically within the HPE security team before we pushed it out to

a sort of an open source project. And so we've been working on it really right from the word go,

helped to design it and steer it in the direction it's gone in. And, yeah, it's it's really interesting. I love anything

I guess at heart I'm kind of lazy because I'm a programmer and I think most programmers are,

and we like to automate stuff. If we can script it, then great. So why not,

security? You know, this this was something that that really appealed to me as a project.

Plus, I'm kind of a language geek, so I like to, play with some of the technologies that we've used here.

Travis, how'd you get involved?

I was actually in the room, at that mid cycle that I was talking about when Jamie came back.

And I I immediately saw that this is a much better way of solving the problem than grepping. And then, actually, at the time, I wasn't working for HP. I joined soon after, and the first project that Jamie gave me was to to grab the ball with the simple proof of concept he put together at the mid cycle and really extend it into something useful that we could build a process around.

And at what stage of the development process would somebody want to use Bandit?

I think all stages of the development process are are fair game for Bandit. Ideally, we really want developers to try their code with Bandit to make sure that they've at least looked at it and understand what they're doing prior to trying to send it for review. 1 of the things we've also done is introduce a process around running Bandit in a gate. So for those that don't know, a gate is basically a check set of processes that can run against code prior to it being merged into the code base. In this case, we're talking about the upstream git repositories.

So the gate basically will run Bandit against the project, make sure that it isn't introducing any new security issues. And if it's okay, it merges. And if it's not, then it flags the review for

more more attention.

And is that gate something that would be run as part of the CI pipeline, or would it be run even prior to it getting pushed to the repository?

The gate gets run-in both of those capacities.

So when you push your so a developer is free to run bandits on their code locally, but also when they push their patches

to the centralized repository for the project,

that causes the the gate process

to begin. The gate will run automatically,

assess the code, and flag up any issues

immediately.

And that's,

that patch sits in a kind of pending state until those issues are resolved before it's merged into the project's repository proper. Once it's merged,

the the check can be run again just to make sure that everything is as it should be.

And what kinds of analysis does Bandit do on the source code that it's run against, and what kind of vulnerabilities can it find?

Yeah. I guess I'll take that. So the Bandwidth,

scanner works basically

by analyzing

what's called an abstract syntax tree. It's it's a very typical technique to use for static analysis. And what it does is we we take the internal compiler mechanism from the Python virtual machine itself to produce this abstract syntax tree. Once we have that, and this is literally just a tree of nodes which represent various bits and pieces of code. So when we have that, we can run

various,

checkers and walls across this pattern of nodes, and we can interrogate

the the sort of shape, if you'd like, the way these nodes are linked together, the pattern that's formed, as well as the contents of those

nodes like, for example, function names

or string literals and things of that nature. And we use this to match against various rules. We have a whole library of rules which are based on a kind of a plug in interface, so it's an extensible tool. And we can spot,

all manner of things, really, SQL injection,

hardcoded credentials.

We've even got some stuff for looking at Mako and Jinja 2 templates

and just there's loads of stuff. We've got a whole library of things. And I was noticing when I looked through the documentation a little bit that it's possible to write additional plugins to make it check for anything that's particularly domain specific to a given project or industry as well? Yeah. Absolutely. So we actually have a couple of both Uber

and Lyft are using Bandit internally.

And I know for a fact the Lyft guys have created quite an interesting plug in for detecting

hardcoded secrets by looking at string entropy. Very, very interesting. And that's that's a third party plugin that's been created by a chap at Lyft. What was his name now? Just Ryan Lane, I think. Yes, that's right. Ryan Lane. Yeah. So he's created this this very interesting plug in. But, yeah, absolutely. People are free to extend the tool with whatever they see fit,

for their particular situation or particular code base. And they can turn on or off any of the sort of core plug ins that ship with the tool as well and tailor it to fit their needs, really. So it sounds like it's

even potentially useful beyond just security compliance and basically just for general compliance of various coding standards

or standards, even business specific?

Yeah. I mean, it is. There are other tools to do that, and they and those tools may well be more suitable, things like hate and hacking and things. But Bandit is certainly capable of doing those things, although its specific focus is very much in the security spectrum.

And so as a contrast to some of those other tools, are there any particular facilities that it has that makes it more well suited for doing security checking versus if you were to try and extend those existing tools to the security realm? I would say not necessarily from the technology, but the core developer team, Eric, Travis, and myself, plus Rob and Jamie and the others who are involved in the project, are all very much

focused on security. So when you're submitting patches or seeking guidance, you're gonna get a lot of security know how coming back. You spoke about how it uses the AST to parse the code base. But can you speak a little bit more about how it determines whether a particular segment of code is introducing a vulnerability?

And and what means does it use to determine the severity of that vulnerability?

So each plugin is able to define 2 things, the severity of the issue it's finding and the confidence that it has that it's actually found something. And that's just based on the developer of the plug in understanding the impact of the security thing that's behind it. For each plugin, we have guidance as well that accompanies the plugin and really does a pretty decent job of explaining what is the thing testing, how does it know that it's found it, and are there any further references that somebody that doesn't know about this security issue should read to find out more? I've actually tested it out a little bit on a couple of my code bases, and it does generate a fairly detailed report. I'm curious if there's any particular default formatting that it has that makes it easier to ingest into other tools or if there if it has the facility to customize the output format to make that easier to do and what kinds of uses that information can be put to? Well, there are a number of built in formatters, and the the formatters or the output formatters are,

pluggable too. So I think today we support

JSON, HTML,

CSV,

and standard text, But So, yeah. I mean, definitely with it, JSON or something, you can feed into some other tool that might wanna parse that JSON and do some special things with it. Just to extend the information a little bit. So we we definitely invite other people to write new plugins if they want something in particular. For example, 1 of the things that somebody's been working on is the Jenkins integration, which if at the point that they complete that, they can contribute back to the community. Yeah. So the idea with the output plugins is that we should be as flexible as possible. Bandit serves a dual purpose.

We want it to be a tool in the kit bag for developers, maybe integrated into their IDEs or local tool chains or whatever. But we also want it to be part of an upstream

automatic

scanning process in a CICD pipeline. And to make that work, we need to play nice with the typical tools that would be used to build such a pipeline. Hence, we want to be as flexible as possible in our report output so that you can take that, pause it, and then use it with something like Jenkins or,

is Jarvis another 1? There are a few different tools, but they generally take something akin to an XML or a JSON output and process that. So we want to give you the flexibility to just have whatever

or extend it, you know, with your own specific needs. Yeah. I imagine that it would be potentially useful useful as well in the context of compliance monitoring using a tool such as Nessus or NEXPOSE.

Yeah, absolutely. Anything that can read in the input,

and make sense of it, you know, in any of those formats, is more than capable to glue together to make that pipeline happen.

And what kinds of information are exposed in that report? Does it include something like the particular region of the code that potential vulnerability is located and any, you know, maybe even some potential advice as to how to remedy that vulnerability?

So, yeah, the the code,

report indicates

a few things. So we give you the file that we discovered the issue in, the line number,

so as a developer, you can go straight to it. We also give you a few lines of context.

So and that that's configurable, but sort of 4 or 5 lines of code from around the vicinity of the issue. Again, just as an aid to helping a developer pinpoint where the problem is. And in addition to that, we'll give each issue that we discover a severity rating and a confidence rating. And these ratings are really determined by the test author. A general rule of thumb for the confidence

factor, which is probably the fuzziest, is if you're sure

that you have

discovered

the issue you think you have. So looking at the AST, particularly

in a very dynamic language like Python, it kind of maybe looks like this is the correct issue, but you may not be completely sure. So if you're sure if you think that more often than not you will produce a genuine result rather than a false positive, then you'll give it a slightly higher, sort of a medium confidence. If you're absolutely sure that that you've found what you're looking for, you'll give it a high confidence. And if you're, you know, 5050,

then it'll have a low confidence.

And and people who run the the tool can filter

to cut out,

results that fall below a confidence threshold. And similarly with the severity.

So the severity is

an indication of how much of

a a problem this issue might actually be,

based on the security expertise of the author that wrote that particular test.

Some things are very are very slight, some things are particularly

problematic,

and you really shouldn't be doing those things. And these 2 slide as if you like, the severity and the confidence,

they're orthogonal to each other, so you can have a high risk but low confidence issue or vice versa, and you can filter on both factors independently.

And are there any plug ins or services that allow for automatically pulling in different CVEs as they become available?

There's no services that will automatically do that for you. However, if there's something so a CVE is a little different. That's an issue in a particular software product. Bandit actually would be more geared towards finding potential CVEs. However, if there's something for example, there was an issue in blast a while backward, you could set a debug mode and that was actually how

got hacked was with this Flask issue. So we saw that in the news, recognized that this is, an issue that Bandit could detect, and then wrote a plug in around it. So from then on, anybody that had that certain Flask issue exposed in their code, Bandit was able to find it. Given that, it definitely seems

that Bandit is 1 dependency that is important to keep up to date because you wanna make sure that you get those vulnerability checks and keep them up to date as possible as you're continuing to scan your code. Absolutely. And sometimes we have to revisit some of the plugins that, you know, may be false positives at this point because as Python ages, they they do tend to go back and fix, you know, certain modules that had vulnerabilities before. So sometimes we need to lessen the severity or or maybe lessen the confidence depending on Python version, things like that. What are some of the biggest design and implementation difficulties that have been encountered in the process of creating Bandit?

Initially, I did a lot of work to kind of roll out Bandit in the gates of other OpenStack projects.

And I'd say the big maintenance issue was the configuration, and it was mainly through this file called the bandit.yml.

And so inside this YAML file, there are profiles where each project could customize what plugins were scanned and optionally choose that command line level, and then, but there was a bunch of other things in there that was

more, like, default settings for each plugin or customization of each plugin, and unfortunately, this Bandit Yam became It was very large. It would frequently change with every Bandit release,

and so rolling that out to, you know, numerous OpenStack projects got very difficult,

level where a lot of these command line switches could be used instead to specify what plugins I wanna use to scan with, what severity I care about, and what confidence I

I'd agree with you absolutely, Eric. I think that that config file was definitely our biggest

challenge

in terms of sort of engineering that we put into Bandit. That might sound kind of strange, but it was more maintaining

the compatibility

with people that were using earlier versions of Bandit and older config setups and making that continue to work with the the new system that we put in, the config less system. I guess, as all engineers know, the bane of legacy support is a problem, and it's

it certainly got to us when we had to do this.

And has Bandit uncovered any severe security issues in the OpenStack project that you're able to share with us? It has actually uncovered some what were defined to be critical issues in in several of the projects. I don't wanna name specific issues because I think I don't wanna detract from the the appearance of security entities projects. I think the important part is that Bandit is actively run against projects and is finding issues, and that these issues can be fixed rather than actually making it into a production OpenStack release. Sure. Bandit also has been run against Python libraries in general, and there's been a few CVEs submitted. Again, I'm not gonna call out specific ones, but there's been a few CVEs submitted across the board in the wider Python community as a result of Bandit scanning.

So how does Bandit compare to similar tools in other languages such as Brakeman and Ruby?

So, I'm I'm not really a Ruby developer, so I'm not completely familiar with Brakeman. Man. Although, I had a look at their information,

and it sounds like they're doing a very similar job to Bandit. It's a very specific

tool with Ruby for Ruby in the same way that Bandit is built with Python for Python. And it's it also processes the AST,

and it does some of the some similar work to the way that Bandit works, although obviously there are differences for the specifics,

Ruby typically being used for web applications.

Bandit is a I feel a lot more free form and it's sort of a general security tool rather than a more web app focused tool, though that might not be fair on Brakeman. As I say, I'm not a Ruby developer. I'm also not a Ruby developer. I haven't played around with Brakeman too much. But 1 of the things I can say is Bandit is, compared to other static analysis tools, Bandit is not static analysis. 1 of the things we specifically call out is that it's a linter, which means it's a little bit more simple.

And that that comes with benefits and also drawbacks. So there are some issues in code that we just can't detect. For example, if input comes from a file or from a user or a network connection, we're never gonna know about it because we're not even tracking the source of an input. We just look at the line of code in an individual kind of in a back end. End. But what that comes with is that it runs very quickly, it doesn't take a lot of resources, and it it can be run as a result of the small footprint, it can be run pretty frequently and and integrated into more places. And I also say it generates a lot less false positives than other similar tools.

Yeah. So I I guess I would say Bandit is probably I don't know. Maybe I'm being a little bit generous here. But I think it's kind of a half and half between static analysis

and linting. Because we do process

some bits and pieces that you would associate with static analysis, and we do do some stuff that is just plain linting. But we've tried to make it as fast and as lightweight as possible because of this desire to have a rapid iteration and to integrate with CICD pipelines and bits and pieces as well. So what's on the road map for the future of Bandit?

At this point, we're we're really focused on bringing Bandit to every OpenStack project. So the gate process that I had mentioned earlier, we really wanna make sure that each OpenStack project has a gate that runs Bandit to ensure that no new issues that Ben is able to detect are introduced into the code base. And then once that's established, then we'll really have a full scope protection of everything in OpenStack, which is, I'd say, kind of the goal of our project from the beginning. Yeah. I would agree that broad phase adoption is definitely the next step for us. Looking farther afield, we do have some sort of engineering ideas around

multi threading for higher performance gains

and also doing some more interesting things to track variables

and,

sort of verging on something akin to tank tracking, but, it's still very much in the design stage at the moment.

So are there any questions that I didn't ask that you guys think I should have or anything else that you wanna mention before we move on? So for anybody who wants to keep in touch with you guys or follow what you're up to, what would be the best way for them to do that? So we are all members of the OpenStack Security Group, and most of the work that's been done around Bandit has been done under the auspices of that group. So

best way to get in touch would be to jump into the OpenStack

Security,

IRC room. That's OpenStack Security on Freenet

Freenode.

We have a weekly meeting as well, which is actually

on a Thursday at,

well, my yeah. 1700 UTC. Or to, you know, jump in on the mailing lists and, yeah, just reach out to us. We're happy to talk or to accept patches or discuss ideas or whatever. For anybody who wants to follow you specifically, is there any best way for them to do that? Yeah. So I guess you could reach out on my Twitter handle, which is Calidus, spelled c4,

double l, I d u s,

and that's on Twitter. But, generally, I hang out in the IRC rooms in OpenStack, so that's probably the best place. And, Travis, how about you? I'm at travismcpeek

on Twitter, and I'm also on IRC. So if you wanna come have a more direct chat, IRC is probably the easiest way to do that. I'm tmcpeek on on IRC.

So with that, we'll move on into the picks. For my picks today, I'm going to choose the toggle time tracker. It's online service that has associated mobile apps, and it's just a really simple and easy to use time tracker for if you need to keep track of how much time you're spending on a project or anything like that. Supports labeling and, you know, segregating the time entries by projects,

So pretty useful. And I'm also gonna choose the any dot do to do list. I had used it a while back, stopped using it for a while just because it didn't quite fit my needs, and then revisited it recently. And they've made a lot of improvements,

so definitely worth checking out. It's a pretty well designed interface, both on web and mobile, very simple but flexible for your use cases. So worth taking a look at. And Tim, what do you have for us?

So I guess keeping in the theme of web applications,

I would choose If Then That, which is a pretty cool online portal

for automating all kinds of things. It takes inputs from a whole bunch of places, and it can trigger events on a whole bunch of other places. And it's pretty cool for scripting up little automations and things that will work with

those, Internet of Things lights and stuff like that. It's it's a pretty cool toy. So for me, I I have to promote Slack as a, instant messaging tool. We use it internally on VMWare, and I'm just I love it. I think it really makes my life more productive. Not mention it has all kinds of hooks to add bots, and other cool things. Yeah. I'll second that choice. Yeah. Slack is pretty awesome.

And it even has an IFS than that plug in, so Alright.

I'm gonna have to try that.

And, Travis, what do you have? Sure. I've got 3 media selections.

For the books, I've just finished the Brilliance trilogy by Marcus Sege or Sacge. I'm not sure how you pronounce his name. I'm not generally into science fiction, but the way that he did 3 books, but the way that he writes them and and builds the story and the characters was really great. I just started playing Uncharted 4, which so far is amazing on the PlayStation 4. Oh, yeah. For security related,

content, I really like the Risky Business podcast. It's probably the most informative 45 minutes I spend all week in terms of security related topics. Sorry to plug another podcast.

No. Absolutely.

I've

I've plugged my fair share as has my cohost and a number of our guests. So they're they're a great media. And, you know, the more of them there are, the better. Okay. Cool. Well, I appreciate you all taking time out of your day to tell us more about your work on Bandit and how it can be used to make our code more secure. So thank you very much, and I hope you enjoy the rest of your days. Thanks, Bryce. Thanks, Bryce.

The Python Podcast.init

Summary

Brief Introduction

Interview with Eric Brown, Travis McPeak and Tim Kelsey

Keep In Touch

Picks

The Python Podcast.__init__