Change-Based Security Tests in Pull-Requests

The developer creates the pull request

Code-layer security requirements run when a developer creates a pull request via CLI, IDE or — as in this example — GitHub. In this scenario, the developer makes code changes that contain the Python code security vulnerability below.

import subprocess
output = subprocess.check_output(f"nslookup2 {domain}", shell=True, encoding='UTF-8')



In this scenario, branch protection rules are configured to prevent merging if the Jit Security check fails. Jit Security acts as a parent check that only succeeds when all other Jit checks in the pull request are also successful.

The welcome message displays

The developer views the welcome message in the pull request conversation. This message presents the security plan and its constituent security requirements— which are automatically implemented by Jit. Each developer in the monitored organization receives this message a single time.

Welcome message in GithubWelcome message in Github

Jit checks run

Jit listens to pull requests and examines their content. If the code language is supported, Jit automatically implements the relevant security requirements— which run as GitHub actions. In this example, Jit runs Bandit, OWASP Dependency Check, and Gitleaks.

The Python Code Scanning (Bandit) check fails. Branch protection rules require this check to pass before the pull request can be merged. As a result, the option to merge is disabled.

Jit Security - ChecksJit Security - Checks

The developer views the security finding

Jit displays any security requirement findings in the pull request conversation using a common, unified format. For each finding, Jit presents the following—

Jit Security Review with commentsJit Security Review with comments


Finding format

Sample of flagged code

Security tool: The security tool that produced this finding.

Type: This information varies by security tool. In this example, it is the specific Bandit (Python code scanner) test used to detect this type of vulnerability.

Description: This information varies by security tool. In this example, it is description text for the Bandit test used to detect this type of vulnerability, retrieved from Bandit's documentation.

Severity: The severity level of this finding.

Learn more about this issue This is a link to documentation on the security finding type.

The developer addresses the finding

When the Jit Security check fails, developers are advised to address the finding in order to eliminate any security issues or risky misconfigurations. Here are the options—

The developer fixes the code with Jit automated remediation

In some cases, developers can fix the security issue or IaC misconfiguration instantly with automated remediation within the scope of the pull request. For further information, see Jit automated remediation.

The developer ignores the finding

Developers have the option to circumvent branch protection rules if they have reason to believe the finding is a false positive or intend to resolve the issue at a later time. To ignore the finding, the developer can issue one of three commands inside a comment. See them below.


Jit Bot commands

  • #jit_ignore_fp <description>
    Ignore and mark this specific single instance of a finding as “false positive.”
  • #jit_ignore_accept <description>
    Ignore and mark this specific single instance of a finding as “accept risk.”
  • #jit_undo_ignore
    Undo the ignore command.

If Slack integration is configured, a Slack notification is sent to the security champion with a link to review the ignored pull request in GitHub. At this point, the security champion may choose to DM the developer to discuss the issue. For instructions on integrating with Slack see Integrating With Slack,

The developer merges the pull request

When all findings have either been fixed or dismissed, successful status checks enable the option to merge.

Pull Request checks passPull Request checks pass

Did this page help you?