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 SCM (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')

📘

Note

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.

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 in the SCM environment.

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

❗️

If a Jit check fails with errors after multiple re-run attempts, notify your security champion.

If a Jit check continues to fail with errors, Jit users with administrator privileges (such as security champions) can bypass branch protection rules by running the command #jit-bypass-commitin a new comment to unlock the option to merge the PR. Note that this may allow vulnerabilities, that would otherwise have been detected, onto the target branch.

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—

📘

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 test used to detect this type of vulnerability.

Description: Information retrieved from security tool 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 can fix the code with Jit automated remediation.
• The developer can ignore the finding.

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 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_ignore_type_in_file
  Ignore any finding of type <finding type> in <filename>; future occurrences will also be ignored.
• #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. 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.