Configuring a GitHub integration

Once a GitHub integration is installed, you can fine-tune its behavior to suit your workflow. This guide walks you through each available setting to help you get the most out of the integration.

Overview

The configuration options allow you to control how scanning occurs, define what is scanned, and customize the security rules that apply. These settings ensure the integration fits seamlessly into your development process.

1. Integration status

This setting controls whether a GitHub integration is active.

• Default: Enabled
• What happens when disabled: All scanning activities, including scheduled and pull request scans are paused.
• Recommendation: Leave this enabled unless there's a specific need to pause security scanning.

2. Scheduled scans

Scheduled scans automatically review your main branches for vulnerabilities and misconfigurations.

• Default: Enabled
• Purpose: Ensures continuous security coverage of your production-ready code
• Key Points:
  • Runs daily without manual input
  • Helps maintain long-term code security
  • Ideal for monitoring stable branches over time

3. Pull request scanning

This feature triggers scans on new and updated pull requests, providing immediate feedback to developers.

• Default: Enabled
• What it does:
  • Scans the code introduced in each pull request
  • Posts comments with findings directly in the PR
  • Integrates with GitHub status checks to block insecure merges
• Supported File Types:
  • YAML files (.yml, .yaml)
  • Terraform files (.tf)
  • JSON configuration files (.json)
  • Code security IaC files
• Why it matters:
  • Prevents vulnerabilities from reaching main branches
  • Encourages secure coding practices early in development
  • Promotes developer awareness of potential issues

4. Tolerance for blocking pull requests

This setting controls when pull requests are blocked based on the severity of findings.

• Default: Do not block pull requests
• Options:
  • Only block for critical findings: Pull requests are blocked only when critical severity issues are found
  • Block for high and critical findings: Pull requests are blocked when high or critical severity issues are found
  • Block for medium and above findings: Pull requests are blocked when medium, high, or critical severity issues are found
  • Block for any finding: Pull requests are blocked when any severity of issue is found
  • Do not block pull requests: Pull requests are never blocked based on scan findings
• Best use:
  • Set based on your organization's risk tolerance
  • Consider your team's development velocity and security requirements
  • Align with your overall security posture and compliance needs

5. Profile

The profile defines which security checks are used during scans.

• Default: Your organization's default profile
• Options: Select from existing profiles or create new ones
• Where to manage: Profiles can be configured in the Detection Settings section
• Best use: Align profiles with your organization's risk tolerance and coding standards

Best practices

• Keep the integration enabled to maintain continuous coverage
• Use scheduled scans to monitor your main branches for long-term risks
• Enable PR scanning to catch issues before they're merged
• Set the tolerance for blocking pull requests based on your organization's risk tolerance
• Select an appropriate profile that reflects your team's security needs

These configuration settings are designed to give you control without adding overhead. Once set up, the GitHub integration works in the background, keeping your codebase secure, up to date, and aligned with your security policies.