As software development teams work at an ever-increasing pace, leaving security for seconds is easy. One primary security concern is the accidental inclusion of secrets and passwords in source code, which can lead to severe data breaches if left unchecked. Just look at the high-profile cases of Capital One and Marriott: both companies suffered significant data breaches due to exposed secrets, which compromised millions of personal details, social security numbers, and bank accounts. 

In our previous post, we took a deep dive into an excellent open-source tool called Gitleaks that can help detect any hard-coded secrets before they reach production. In this post, we will show you how to use another great open-source tool, Bandit, to help prevent committing vulnerable code to production. We'll also share how you can automate SAST tests with Jit to make it even easier to secure your code.

How SAST helps developers

Static Application Security Testing, or SAST, is an invaluable tool for developers who want to write clean, secure code. As a developer, you know that writing code is challenging enough without worrying about security vulnerabilities creeping in. SAST helps you find and fix security issues in your code before they become a problem.

‍SAST analyzes your application's source code and identifies potential security vulnerabilities based on predefined rules. It's like having a team of security experts by your side, checking your code for potential issues and alerting you to any problems. You can focus on writing clean, efficient code without worrying about security.

Using SAST can be a game-changer for developers who want to write secure code but may need more security expertise. It helps you identify and fix issues early on in the development process, saving you time and frustration in the long run. Plus, it gives you peace of mind knowing that your code is secure and ready for deployment.

What is Bandit?

Bandit is an open-source SAST that helps identify security issues in Python code using predefined rules. It is part of the OpenStack Security Project and is specifically designed to find bugs in Python code that could lead to security vulnerabilities. 

It is executed from the command line and can be integrated into continuous integration (CI) workflows to provide ongoing security checks as developers write code. Bandit is often used with other security tools, such as PyLint and PyCodeStyle, to provide a more comprehensive security analysis of Python code.

Running Bandit on your application manually

To run Bandit manually on your application, you’ll need to install Bandit first on your system. Do note that this is a different process of running scans and is separate from what Jit offers. 

‍Manually running Bandit means the developer is responsible for maintaining the velocity of scans on a consistent basis. In contrast, using Jit means that you only need to add your repo to the platform, and Jit will sort out all the necessary things you need to check the robustness of your code’s security.

pip install bandit

Once installed, you can use the Bandit command from the command line, followed by the path to the directory or file you want to scan. For example:

bandit /path/to/application

Note: if you are having errors and cannot run bandit but have it installed, prefix your commands with python -m.

For example, Here's an example of insecure code that uses hardcoded credentials, along with some additional potential vulnerabilities:

When you run bandit on this code it should generate a security alert:

bandit issues.py

Here is an example bandit test result based on the above code and command:

To see the complete output, please visit pastebin.

You can find a complete list of the available command line arguments and their meanings in the Bandit documentation.

Bandit output

When you run Bandit on your application, it will produce a report of the results of the security checks it performs. The report includes the following information:

• Code scanned: This section lists the files and directories that Bandit scanned, along with the number of lines of code analyzed.
• Test results: This section lists the individual security issues that were found by Bandit, along with details about each bug, such as the severity level, the type of issue, and a description of each.
• Run metrics: This section provides summary statistics about the results of the Bandit run, including the total number of issues organized by security and confidence level. 

In Bandit, issues are measured by severity and by confidence. Severity is a measure of an issue's potential impact on the application's security. Bandit uses the following levels of severity:

• High: Issues with a high severity level are considered critical and should be addressed as soon as possible.
• Medium: Issues with a medium severity level are considered critical but may not be as urgent as high-severity issues.
• Low: Issues with a low severity level are considered less important and may not pose a significant risk to the application's security.

Baseline

A baseline is a snapshot of the results of a previous security scan, which you can use to compare against the results of a new scan. This allows you to track changes in the security of your code over time, and identify new vulnerabilities that have been introduced.

The command to create a baseline file using Bandit is:

[.code]python -m bandit -r <target_file_or_directory> -f json ><baseline_file>.json[.code]

Where:

• [.code]<target_file_or_directory>[.code] is the file or directory that you want to scan for security issues.
• [.code]<baseline_file>.json[.code] is the name of the JSON file that will be created and will contain the results of the scan.

For example, if you want to scan the file issues.py and create a baseline file named baseline.json, the command would be:

[.code]python -m bandit -r issues.py -f json > baseline.json[.code]

Where:

• issues.py is the file or directory that you want to scan for security issues.
• baseline.json is the name of the JSON file that will be created and will contain the results of the scan.

This command will run Bandit against the specified target file or directory and will output the results in JSON format to a file named baseline.json.

The following command will run Bandit against the target file or directory issues.py and compares the results to the baseline report baseline.json.

[.code]python -m bandit -r issues.py -b baseline.json -f json > change.json[.code]

Here's what each part of the command does:

• python -m bandit: The [.code]python -m[.code] is a command-line option for running a module as a script. In this case, it's used to run the Bandit module.
• -r issues.py: The [.code]-r option specifies the target file or directory that you want to scan for security issues. In this case, the target is issues.py.
• -b baseline.json : The [.code]-b[.code] option is used to specify a baseline report. In this case, the baseline report is baseline.json.

• -f json: The [.code]-f[.code] option specifies the format of the output. In this case, the output will be in JSON format.
• > change.json: The [.code>[.code] operator redirects the output of the command to a file named change.json. It means that the output that is being generated by the command is saved to a file named change.json instead of being displayed in the terminal.

The command compares the results of the current scan to the baseline report. If there are any new or changed issues, they will be reported in the change.json file. Please make sure that the path to the issues.py and baseline.json files are correct and that the files exist in the location you specified, if not you will get an error.

Here’s an example of the JSON generated in change.json

To see the complete output, please visit pastebin.

Version control integration

Bandit settings

Bandit has several settings you can use to customize its behavior when running security checks on your application. These settings can be specified using command line arguments or through configuration files. Here is a list of some available Bandit settings:

• Severity level: using  [.code]--severity-level[.code] {all,low,medium,high} will report only issues of a given severity level or higher. "all" and "low" are likely to produce the same results, but it is possible for rules to be undefined which will not be listed in "low".
• Confidence level: using  [.code]-i[.code], [.code]--confidence:[.code] report only issues of a given confidence level or higher (-i for LOW, -ii for MEDIUM, -iii for HIGH)
• Excluded files: You can use the [.code]--exclude[.code] command line argument to specify files or directories you want Bandit to ignore when running checks. This command can be helpful if you have specific files that you know are irrelevant to security or contain known vulnerabilities that you do not want to report.
• Included files: You can use the [.code]--include[.code] command line argument to specify specific files or directories that you want Bandit to scan. This command can be helpful if you only want to check a subset of your application.
• Configuration files: You can use configuration files to specify settings for Bandit in a more structured way. Configuration files can be specified using the [.code]--ini[.code] command line argument and includes a wide range of options for configuring Bandit's behavior.
• Output format: You can use the [.code]-f[.code] command line argument to specify the structure of the output report that Bandit produces. Bandit supports various output formats, including JSON, XML, and plain text.

For all the available flags for Bandit, run bandit [.code]--help[.code] in your terminal to get the entire list.

Running a SAST test

To run a SAST (Static Application Security Testing) test with Bandit and Jit, you will need to perform the following steps:

1. Configure your Jit account and set up an MVS (Minimal Viable Security) plan for your application. This step will involve specifying the security tools and workflows you want Jit to use when running security checks.
2. Set up a GitHub repository for your application and link it to your Jit account so that Jit can monitor your code changes and run security checks automatically when you create pull requests.
3. Create a pull request in your GitHub repository with the code changes you want to test.
4. Jit will automatically run Bandit, and any other configured security tools on your code change as part of the pull request process.
5. Jit will display the results of the security checks in the pull request conversation, including any issues found and their severity levels. 

Here is an example of how you might use Jit and Bandit to run a SAST test as part of a pull request process:

Using Bandit through Jit

Jit was built to enable developers to easily integrate great open source tools like Bandit into their CI/CD workflows and pipelines. 

Running Bandit with Jit is simple and effective. There’s no need for any additional installation or interaction with Bandit itself. Simply add your repository, and Jit will automatically run Bandit as part of its continuous security checks whenever you create a new pull request in GitHub. You can view the results of the Bandit checks in the pull request conversation, where Jit will display any security findings in a unified format. 

Jit provides some added benefits to adopting the vanilla open source as follows:

• Streamlined integration: Jit makes it easy to integrate Bandit into a continuous integration (CI) workflow, allowing developers to run security checks automatically as they write code. With a few clicks, you can start running security checks automatically as you code. Adding security to your CI process won't slow down your dev velocity, as Jit only runs on the last pull request.
• Centralized management: Jit provides a centralized dashboard for managing product security posture and progress, making tracking security issues and fixing them more straightforward.
• Expert knowledge: Jit includes curated MVS plans to help developers implement best practices for securing their products.
• Simplified developer experience: Jit provides a unified GitHub experience for developers, making it easier to use Bandit and other security tools without disrupting their typical workflow.

‍

Running a SAST Test with Bandit and JIT

Here's how the process of using Bandit through Jit works.

First, create a pull request in GitHub where you'll be making code changes that may contain security vulnerabilities. Jit always listens to pull requests and automatically implements relevant security requirements as GitHub actions.

In this scenario, Jit will run Bandit, OWASP Dependency Check, and Gitleaks on your code changes to ensure they are secure. Bandit is a tool that analyzes your Python code for common security issues, while OWASP Dependency Check looks for vulnerabilities in your project's dependencies. Gitleaks checks your Git repository and history for sensitive data.

If any security issues are found, Jit will display them in the pull request conversation using a clear, unified format. You'll see a report on the issue, including which security tool found it, the issue type, and a description. You'll also see the severity level of the finding and a link to learn more about it.

If the Jit Security check fails, one or more security requirements have not been met. This means you'll need to address the issues before merging the pull request. You have two options: you can fix the code with Jit's automated remediation or choose to ignore the finding if you believe it's a false positive or plan to resolve it later.

Once all findings have been fixed or dismissed, you'll see that the option to merge is now available. The successful status checks have enabled the button. Just click the button, and you're all set! Your code changes will be combined, and you can be confident that they are secure.

By using Bandit with Jit, you can cut out the manual step, and improve the security of your code without slowing down your development. Jit makes integrating security checks into your workflow easy, so you can catch and fix any issues before they become a problem. We also provide a webapp containing a detailed view of the tool scans with logs and possible actions you can take. 

Make security work for you

Security doesn't have to be a hassle. Tools like Bandit help you automate your SAST tests so your team can focus on writing excellent code while ensuring that all vulnerabilities are tracked and solved. By setting up an MVS plan and linking it to your GitHub repository, Jit can automatically run security checks on your code changes as part of the pull request process, providing a streamlined and consistent developer experience. 

With Jit's automated remediation feature, you can even fix security issues within the scope of the pull request, saving time and reducing the risk of introducing new vulnerabilities into your codebase. But enough talk - why don’t you see Jit in action for free?