Gitlab Bot
Monitor, alert, and detect sensitive data in your code for each push or merge request. Get instant feedback on any changes you make in a merge request. The Spectral Bot can be installed directly on organizations, user accounts, groups, and specific projects. It supports both system-level webhooks (GitLab Enterprise) and group-level webhooks.
By default, only single instance of the bot can be deployed to a region. To deploy several bot instances to the same region, contact Support.
Integration Environment Variables
To configure the Spectral Gitlab bot, set these variables in your environment:
Name |
Required |
Description |
---|---|---|
CHECK_POLICY |
Yes |
Determines how the pipeline status should be handled if Spectral finds issues in a merge request. Options based on issue severity: "Fail on any issue", "Fail on low and above", "Fail on medium and above", "Fail on high and above", "Fail on critical only", "Always Pass" |
GITLAB_SELF_HOSTED_DOMAIN |
No |
Provide the domain if you're running a self-hosted GitLab (e.g., https://my-gitlab-domain.com). |
GITLAB_WEBHOOK_SECRET |
No |
A strong secret for securing the webhook. If you use a vault, leave this field empty. |
GITLAB_ACCESS_TOKEN |
Yes, if not using vault |
Generate it in your GitLab profile under Access Tokens, with the "api" scope (leave empty if using a vault). |
VAULT_KEY_GITLAB_ACCESS_TOKEN |
No |
The vault key to retrieve the GitLab access token (e.g., Spectral_GitlabBot_AccesToken). Required if using a vault. |
VAULT_KEY_GITLAB_WEBHOOK_SECRET |
No |
The vault key to retrieve the GitLab webhook secret. Defaults to Spectral_GitlabBot_WebhookSecret. |
VAULT_KEY_SPECTRAL_DSN |
No |
The key in the vault where the Spectral DSN is stored. should be in the format of Spectral_Dsn |
GITLAB_SHOULD_SKIP_PIPELINE |
No |
Specifies whether to skip pipeline creation on push events. Options: true, false. Default: false. |
STRICT_MODE |
No |
If set to true, the check status is based on all issues found in the modified files, even if the issues are old. |
SPECTRAL_TAGS |
No |
Comma-separated list of tags to run Spectral with (e.g., base,iac,audit). |
SPECTRAL_ENGINES |
No |
Comma-separated list of engines to run Spectral with (e.g., secrets,iac,oss). Default: secrets. |
SPECTRAL_DSN |
No |
Your Spectral DSN from SpectralOps (leave empty if using a vault). |
SECRETS_VAULT |
No |
The vault where your secrets are stored. Currently supports aws_secrets_manager. |
CUSTOM_COMMENT |
No |
Custom text to add to the merge request summary (Markdown format). |
SHOULD_SKIP_INGEST |
No |
If set to true, findings won’t be sent to SpectralOps and won’t appear in your dashboard. Options: true, false. Default: false. |
S3_BLACK_LIST_BUCKET_NAME |
No |
Name of the S3 bucket containing the blacklist file. |
S3_BLACK_LIST_OBJECT_KEY |
No |
The S3 object key for the blacklist file. |
CUSTOM_SSL_CERTIFICATE |
No |
The SSL certificate content for on-prem GitLab. Use this variable if not using AWS |
VAULT_KEY_CUSTOM_SSL_CERTIFICATE |
No |
The vault key to retrieve the custom SSL certificate. Defaults to Spectral_custom_ssl_certificate. |
Using a Vault
We recommend to store your secrets in a vault. To do this, set the SECRETS_VAULT environment variable to specify the type of vault you're using.
The AWS Secrets Manager is the only supported vault. Its environment variable is aws_secrets_manager vault.
Set these secrets in your vault:
-
Spectral_GitlabBot_AccesToken (for GITLAB_ACCESS_TOKEN)
-
Spectral_GitlabBot_WebhookSecret (for GITLAB_WEBHOOK_SECRET)
-
Spectral_Dsn (for SPECTRAL_DSN)
If you deploy AWS Secrets Manager with CloudFormation or Terraform An infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share., make sure that the Lambda role can access the secrets using the secretsmanager:GetSecretValue action.
Deploy the Bot
Use CloudFormation, Terraform, or Docker Docker (specifically, Docker Engine) is a software technology providing operating-system-level virtualization also known as containers. to deploy the bot.

-
Make sure the Lambda has these permissions in the AWS account:
Copylambda:GetAccountSettings
cloudformation:DescribeStacks
iam:CreateRole
iam:DeleteRole
apigateway:POST
logs:CreateLogGroup
iam:PutRolePolicy -
Launch the stack. See AWS documentation.
-
Generate a private key in the settings of your new GitHub app.
-
Encode the private key in base64 without line breaks. This is an example command in OpenSSL:
openssl base64 -A -in your-private-key.pem
-
Enter the private key in the GITHUB_PRIVATE_KEY field.
-
For Check Policy, select one of these:
-
Fail on any issue
-
Fail on critical only
-
Fail on high and above
-
Fail on medium and above
-
Fail on low and above
-
Always pass
-
|
Note - If STRICT_MODE is set to true the status check includes all issues found in the modified files. If STRICT_MODE is not set to true, the status check includes only new issues. |

Use the Spectral Terraform module to deploy AWS resources. Set the value of the integration_type
parameter to github
.
Deploy AWS resources using our Terraform module (set the integration_type parameter value to github).
|
Note -The Terraform deployment is supported starting from Github bot version 2.x. |

Follow the deployment instructions on our DockerHub repo for the GitHub scanner.
Configuring Multiple GitHub Apps with a Single Instance of Spectral Bot

-
Download and unzip the Lambda code:
-
Download the Lambda code as a .zip file.
-
Unzip the downloaded file.
-
-
Add the multi_app.json file to the unzipped directory. Make sure that the frontend and backend lambda functions contain the file in their deployments. This is an example of the multi_app.json file:
Copy{
"github": {
"<app_id>": {
"private_key": ""
}
}
} -
Zip the file and upload it to Lambda:
-
Select all of the files in the unzipped directory.
-
Zip the files again.
-
Upload the new .zip file to AWS Lambda
A serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes..
-

The github object is a dictionary containing all the GitHub Apps. Do these steps for each app:
-
Set the private_key. This is a bse64-encoded string of the GitHub App's private key.
-
Make sure the <app_id> contains the GitHup App ID to configure a specific application.
-
Optional - Set one or more of these optional parameters:
-
check_failure_polic
y: Determines the failure policy for scans from this specific GitHub App. The default value of this parameter is defined by theCHECK_POLICY
Integration Environment Variable. -
spectral_dsn
: Allows splitting scans using a different DSN for this GitHub App. The default value of this parameter is defined by theSPECTRAL_DSN
Integration Environment Variable. -
webhook_toke
n: Allows the use of a webhook secret for this GitHub App. The default value of this parameter is defined by theGITHUB_WEBHOOK_SECRET
Integration Environment Variable. -
secret_vault
: Enables storing secrets (webhook secret, app private key, spectral DSN) in a vault at the app level. When using a vault, you must specify all the keys for the webhook secret, GitHub App private key, and optional spectral DSN.
-
Example multi_app.json Configuration
{
"github": {
"<app_id>": {
"private_key": "",
"spectral_dsn": "",
"webhook_token": "",
"secret_vault": {
"name": "aws_secrets_manager",
"key_webhook_secret": "",
"key_private_key": "",
"key_spectral_dsn": ""
}
}
}
}
Storing Secrets in a Vault
We recommend to store your secrets in a vault. Currently, only AWS Secrets Manager is supported.

-
Set the value of the
Secrets_VAULT
Integration Environment Variable toaws_secrets_manager
. -
Set these secrets in your vault:
-
Spectral_GithubBot_PrivateKey
(forGITHUB_PRIVATE_KE
Y) -
Spectral_GithubBot_WebhookSecret
(forGITHUB_WEBHOOK_SECRET
) -
Spectral_Dsn
(forSPECTRAL_DSN
)
-
-
Set these Integration Environment Variables to create custom secret vault keys:
-
VAULT_KEY_SPECTRAL_DSN
- Spectral DSN key name.
Format: Spectral_Dsn-* -
VAULT_KEY_GITHUB_WEBHOOK_SECRET
- GitHub app webhook secret.
Format: Spectral_GithubBot_WebhookSecret-* -
VAULT_KEY_GITHUB_PRIVATE_KEY
- Private key.
Format: Spectral_GithubBot_PrivateKey-*
Note - In a CloudFormation or Terraform deployment, the role that you create for the lambdas gives permission to perform the
secretsmanager:GetSecretValue
action only for those 3 secrets. -
Exclude Repositories
To prevent the bot from scanning specific repositories you can supply the bot with the list of these "blacklisted" repo URLs.

-
Create a blacklist text file that contain a list of full URLs of repositorie to exclude(for example: https://github.com/expressjs/express). Start each URL on a new line.
-
Define these Integration Environment Variables:
-
S3_BLACK_LIST_BUCKET_NAM
E - the name of the bucket containing the blacklist file. -
S3_BLACK_LIST_OBJECT_KEY
- the object key of the blacklist file
-
Complete the GitHub App Setup
-
Go to the GitHub app settings.
-
Enter the relevant Webhook URL:
-
For AWS Lambda: Append /api/github/event to the ServiceEndpoint output from the stack.
For example: https://<id>.execute-api.<region>.amazonaws.com/prod/api/github/event -
For Docker:
-
-
Save the changes.
Monitoring
We recommend to monitor bot errors. If the bot is hosted by AWS lambda, you can configure CloudWatch alarms. For more information, see AWS documentation.