Providers
Automated code reviews are supported for the following source code providers:- GitHub
- GitLab
- Bitbucket - coming soon
- Azure DevOps - coming soon
Review Concepts
The following review concepts apply to all supported providers. Review Modes Set the Review Mode to control when Ghost will review code changes.| Review Mode | Description |
|---|---|
Disabled | Code reviews will not run. |
Auto | Code reviews will run automatically when a pull request is created, or when a draft PR is set to ready_for_review. |
Manual | Code reviews will only run in response to slash command comments (e.g. /ghost review). |
| Threshold | Description |
|---|---|
High | Only high severity issues will be reported. |
Medium | Only medium and high severity issues will be reported. |
Low | All security issues will be reported. |
Comment Reviews
Ghost code reviews are “comment” reviews rather than “approve” or “change request” reviews. This means Ghost code reviews do not count toward required approvals for the pull request. Final review decisions are made by a human reviewer on your team.Review Types
Full Review A full review of the code changes in the pull request. A full review will run automatically if Ghost Code Reviews are inauto mode.
A full review can also be triggered manually with the /ghost review command if Ghost Code Reviews are in manual mode.
Check Review
A re-check of all issues from a full review. A check review will run automatically on pull request synchronize events if Ghost Code Reviews are in auto mode.
During a check review, if an issue is no longer present in the code changes, it will be marked as “resolved”. A human reviewer is still required to sign off and resolve the review thread itself.
A check review can also be triggered manually with the /ghost check command.
Issue Review
An issue review is a review of a single issue from a full review.
An issue review can be triggered manually with the /ghost issue <keywords> command.
During an issue review, if the issue is no longer present in the code changes, it will be marked as “resolved”. A human reviewer is still required to sign off and resolve the review thread itself.
Status Checks
Ghost code reviews report status checks to reflect the review status of the code changes.| Review Result | Review Type | Check Status | Reason |
|---|---|---|---|
| No security issues | Full | success | No action required |
| One or more issues | Full | failure | One or more security issues found |
| No security issues | Check | success | All issues resolved |
| One or more issues | Check | failure | One or more security issues found |
| No security issue | Issue | action_required | A full review or check review is required to resolve remaining issues |
| Remaining issue | Issue | failure | One or more security issues found |
Commands
You can use slash commands to trigger several Ghost code review actions:| Command | Description |
|---|---|
/ghost review | Perform a full review of the code changes. |
/ghost check | Re-check issues from a full review (i.e. if there are code changes since the last review). |
/ghost check <keywords> | Check a single issue from a full review (i.e. if there are code changes since the last review). |
/ghost help | Show help for the /ghost command. |
Triggering a full review with the
/ghost review will mark all existing issues as “superseded”, then perform a full
review of the code changes in the current state.Organization Settings
You can configure code review settings for your organization at https://app.ghostsecurity.ai/organization/reviews. Organization-level settings include:- Provider-specific review modes - Configure default review modes for GitHub and GitLab separately
- Minimum severity thresholds - Set default minimum severity levels for each provider
- Webhook secrets - Manage organization-wide webhook secrets (GitLab only)
- Default project exposure - Set the default exposure level for new projects
GitHub
To enable Ghost code reviews for GitHub, an existing GitHub connection in the Ghost platform is required.Configure Organization Settings
Navigate to your organization review settings and configure the GitHub review mode and minimum severity threshold.
GitLab
To enable Ghost code reviews for GitLab, an existing GitLab connection in the Ghost platform is required.Access Token Permissions
To support merge request reviews, the GitLab access token used for the connection needs permission to set commit status. If reviews are enabled and the access token does not have this permission, reviews are tracked but not analyzed for security issues. Using standard GitLab permissions:- Role:
developer - Scope:
api
Configuration Steps
Configure Organization Settings
Navigate to your organization review settings and configure the GitLab review mode and minimum severity threshold.
Generate Webhook Secret
Generate an organization-wide webhook secret in your organization review settings. This secret will be used to validate incoming webhook payloads from GitLab.
Configure GitLab Webhook
Configure the GitLab group webhook (see GitLab Webhook Configuration below for detailed steps).
Webhook Secret Configuration
GitLab code reviews require webhook secrets to validate incoming webhook payloads. Ghost supports two levels of webhook secret configuration: Organization-wide webhook secret:- Configured in your organization review settings
- Applies to all GitLab repositories in your organization by default
- Recommended for most use cases
- Configured per repository for granular control
- Overrides the organization-wide webhook secret when present
- Useful for repositories that require isolated webhook validation
- If a repository-level webhook secret is configured, it will be used to validate the webhook payload
- If no repository-level webhook secret is configured, the organization-wide webhook secret will be used
GitLab Webhook Configuration
Navigate to GitLab Group Settings
Navigate to your GitLab group and go to Settings → Webhooks → Add new webhook.
Add Secret Token
Paste the webhook secret generated in your organization review settings into the Secret token field.
The webhook should be configured at the GitLab group level to cover all repositories within that group. You can also configure webhooks at the project (repository) level if you prefer granular control.