Github Bot
Monitor, alert, and discover sensitive data in your code for each commit. Get instant feedback on any commit you push to your repository. Spectral Bot can be installed directly on organizations and user accounts and grant access to specific repositories.
Integration Environment Variables
| Name | Required | Description | Valid Values | Default | 
|---|---|---|---|---|
| GITHUB_APP_ID | Yes | GitHub app id | - | - | 
| CHECK_POLICY | Yes | If Spectral finds issues in a PR - how should we handle the PR check? The policies are based on the Spectral issue severity - critical, high, medium, low and informational | "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" | - | 
| SPECTRAL_TAGS | No | Include detectors by tag, separated by comma | - | - | 
| SPECTRAL_ENGINES | No | Engines list to run Spectral with, separated by commas | secrets/iac/oss | secrets | 
| SPECTRAL_DSN | No | Your Spectral DSN retrieved from SpectralOps (leave empty if you are using vault) | - | - | 
| GITHUB_WEBHOOK_SECRET | No | The GitHub app webhook secret, any strong secret would be fine (leave empty if you are using vault) | - | - | 
| GITHUB_PRIVATE_KEY | No | GitHub app private key base64 encoded (leave blank if stored in vault) | - | - | 
| SECRETS_VAULT | No | The vault you're storing your secrets in. Currently | aws_secrets_manager | - | 
| VAULT_KEY_SPECTRAL_DSN | No | The key in the vault where the Spectral DSN is stored. should be in the format of Spectral_Dsn-* | - | - | 
| VAULT_KEY_GITHUB_WEBHOOK_SECRET | No | The key in the vault where the GitHub webhook secret is stored. should be in the format of Spectral_GithubBot_WebhookSecret-* | - | - | 
| VAULT_KEY_GITHUB_PRIVATE_KEY | No | The key in the vault where the GitHub private key is stored. should be in the format of Spectral_GithubBot_PrivateKey-* | - | - | 
| CUSTOM_COMMENT | No | Add a custom text to the pull request comment and check summary - Markdown format | - | - | 
| SHOULD_SKIP_INGEST | No | If set to true- findings won't be sent to SpectralOps and won't be seen in your dashboard | true/false | false | 
| GITHUB_SHOULD_POST_REVIEW_COMMENTS | No | Should review comments be posted on PR files where Spectral has identified issues | true/false | false | 
| GITHUB_SHOULD_SKIP_CHECK | No | Disable GitHub check creation | true/false | false | 
| S3_BLACK_LIST_BUCKET_NAME | No | Name of the bucket containing the blacklist file | - | - | 
| S3_BLACK_LIST_OBJECT_KEY | No | Blacklist file S3 object key | - | - | 
| STRICT_MODE | No | If set to true - issues from changed files in the PR will fail the check even if the issues are in lines that hasn't been modified | true/false | false | 
| HOME | No | If the environment does not automatically set this variable, specify a path to an existing location that has write permissions. For example, in AWS Lambda, where this variable is not preset, assign it the value /tmp | ||
| GITHUB_SELF_HOSTED_DOMAIN | No | Provide the domain if you're running a self-hosted Github (e.g., https://my-github-domain.com). | ||
| CUSTOM_SSL_CERTIFICATE | No | The SSL certificate content for on-prem Github. Use this variable if not using AWS Secrets Manager for the certificate. | ||
| VAULT_KEY_CUSTOM_SSL_CERTIFICATE | No | The vault key to retrieve the custom SSL certificate. | Spectral_custom_ssl_certificate | 
Setup Github App
First you will need to create a new GitHub app.
- If you are installing on an organization account use this link.
- If you are installing on your personal GitHub account use this link.
You then have to choose between installing on
- 
All repositories 
 This applies to all current and future repositories owned by the resource owner.
- 
Only select repositories 
Confirm your choice and move on to deploy the bot. After the bot is deployed you will need to return to the GitHub app settings and complete the setup. See the "Complete the GitHub App Setup" section below for details.
Deploy the bot
Deploy using one of the following methods:
Cloud Formation
Next we'll deploy the lambda to your AWS account. These permissions are required:
lambda:GetAccountSettings
cloudformation:DescribeStacks
iam:CreateRole
iam:DeleteRole
apigateway:POST
logs:CreateLogGroup
iam:PutRolePolicy
Go ahead and launch the stack
- 
To fill in the GITHUB_PRIVATE_KEY field, you'll need to generate a private key in your new GitHub app's settings and encode it with base64 without line-breaks: openssl base64 -A -in your-private-key.pem
- 
The options for the "Check Policy" field are - "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".
 This is for reference if you want to change it after deployment. 
- 
If STRICT_MODEis set to true the status check considers on all issues found in the modified files, even if the issues are old. Otherwise, only new issues will be counted for the status.
Terraform
Deploy AWS resources using our Terraform module (set the integration_type parameter value to github).
NOTE: Terraform deployment supports deployment of GitHub bot 2.x versions and above.
Docker
Follow the deployment instructions in our DockerHub repo.
Configuring Multiple GitHub Apps with a Single Instance of Spectral Bot
To enable multiple GitHub Apps with a single instance of the Spectral bot, you need to configure the multi_app.json file located in the root directory.
Steps for AWS Lambda Deployment
- 
Download and Unzip Lambda Code: - Download the Lambda code as a .zipfile.
- Unzip the downloaded file.
 
- Download the Lambda code as a 
- 
Add multi_app.json:- Place the multi_app.jsonfile into the unzipped directory.
 
- Place the 
- 
Re-zip and Upload: - Select all the files within the unzipped directory.
- Zip the files again.
- Upload the new .zipfile to AWS Lambda, ensuring themulti_app.jsonfile is included.
 
Important Note
For AWS Lambda, ensure that both the frontend and backend Lambda functions contain the multi_app.json file within their respective deployments.
{
  "github": {
    "<app_id>": {
      "private_key": ""
    }
  }
}
Configuring the github Object in multi_app.json
github Object in multi_app.jsonThe github object is a dictionary containing all the GitHub Apps. For each app, you must set the private_key, which is a base64-encoded string of the GitHub App's private key.
The <app_id> should contain the GitHub App ID, providing configuration for a specific application.
Optional Parameters
In addition to the private_key, you can configure the following optional parameters at the app level:
- check_failure_policy: Determines the failure policy for scans from this specific GitHub App. If not set, it defaults to- CHECK_POLICY. Refer to the table above for possible values.
- spectral_dsn: Allows splitting scans using a different DSN for this GitHub App. It defaults to- SPECTRAL_DSN.
- webhook_token: Allows using a webhook secret for this GitHub App. It defaults to- GITHUB_WEBHOOK_SECRET.
- 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.
- self_hosted_domain: Allows self hosted domain for this GitHub App. It defaults to- GITHUB_SELF_HOSTED_DOMAIN.
Example multi_app.json Configuration
multi_app.json ConfigurationBelow is an example of a complete multi_app.json configuration:
{
  "github": {
    "<app_id>": {
      "private_key": "",
      "spectral_dsn": "",
      "webhook_token": "",
      "self_hosted_domain": "",
      "secret_vault": {
        "name": "aws_secrets_manager",
        "key_webhook_secret": "",
        "key_private_key": "",
        "key_spectral_dsn": "",
        "key_ssl_certificate": "",
      }
    }
  }
}
Using vault
Instead of storing your secrets directly on the configuration of your Lambda, it is recommended for you to use a vault instead.
In order to use a vault, it is needed to set another environment variable called SECRETS_VAULT which contains the type of the vault you are using.
Available values:
- AWS secrets manager - aws_secrets_manager
Currently, we are supporting AWS secret manager, but in the future we are planning to support more vaults.
In your vault, make sure you set the following 3 secrets in your vault:
- Spectral_GithubBot_PrivateKey(for GITHUB_PRIVATE_KEY)
- Spectral_GithubBot_WebhookSecret(for GITHUB_WEBHOOK_SECRET)
- Spectral_Dsn(for SPECTRAL_DSN)
Overriding vault keys
To set up custom secret vault keys, use the following environment variables:
- VAULT_KEY_SPECTRAL_DSN- Spectral DSN key name, should be in the format of- Spectral_Dsn-*
- VAULT_KEY_GITHUB_WEBHOOK_SECRET- GitHub app webhook secret, should be in the format of- Spectral_GithubBot_WebhookSecret-*
- VAULT_KEY_GITHUB_PRIVATE_KEY- Private key, should be in the format of- Spectral_GithubBot_PrivateKey-*
- VAULT_KEY_CUSTOM_SSL_CERTIFICATE- (Optional) - key for vault containing self signed certificate. Default value is- Spectral_custom_ssl_certificate
AWS Secrets Manager
If you are deploying using CloudFormation or Terraform, notice that the role created for the lambdas would give permission to perform 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.
To supply such list, you'll need to define two new environment variables:
- S3_BLACK_LIST_BUCKET_NAME - the name of the bucket containing the blacklist file
- S3_BLACK_LIST_OBJECT_KEY - the object key of the blacklist file
The blacklist file should be a text file containing a list of full URLs of repositories that has to be excluded (such as https://github.com/expressjs/express), with line breaks separating between them (each URL in a new line).
When the bot notices that the repo needed to be scanned is contained in the blacklist it would stop the execution and a check wouldn't be created.
If a problem occurs while fetching the blacklist, a failed check is created with an appropriate log in order to be able to know that a given push has not been scanned.
NOTE: Only single instance of the bot can be deployed to a region, if you wish to deploy several bot instances to the same region please contact customer support.
Complete the GitHub App Setup
After deployment is completed, go back to the GitHub app settings page.
In the Webhook section configure the Webhook URL, Webhook secret, and set the Webhook to active. 
AWS Lambda
To build the webhook URL append /api/github/event to the ServiceEndpoint output from the stack:
https://<id>.execute-api.<region>.amazonaws.com/prod/api/github/event
Docker
To build the webhook URL append /events/github to the URL for your container:
https://<container-domain>/events/github
Save your changes to complete the process.
Monitoring
It is highly recommended monitoring the bot errors. It can be done easily if the bot is hosted using AWS lambda through CloudWatch alarms.
To create an alarm do the following:
- In Cloudwatch, click on Create Alarm, and thenSelect Metric.
- Select the Errorsmetric for the lambda and click onSelect Metric.
- Set the statistic to be Sumand select the required period for the threshold measuring.
- Under conditions, choose staticthreshold, chooseGreater, and set the threshold value to at least 1. ClickNext.
- Insert to Emails be to be alarmed. Click Next, name the alarm and clickNextagain.
- Go over the summary, and if everything makes sense to you - click OK.
That's it 💪
Now all commits for the selected repositories are protected!
Upgrading the bot
For major updates please follow the breaking changes instructions.
With lambda
To upgrade the bot, you need to upload a new zip version to lambda under "Code" tab, make sure to upload the new versions to both frontend and backend lambdas.
With Docker
To upgrade the bot, you need to deploy a new Spectral GitHub bot image from docker hub.
Breaking changes
Learn about breaking changes that were introduced in the Spectral GitHub bot.
Upgrade from 1.x to 2.x
The Spectral GitHub bot is versioned.
We recommend upgrading from v1.x.x to v2.x.x due to major performance and resource utilization improvements.
Note: v1.4.2 is the latest version on the old generation of spectral bots. 
v2.x.x changes:
- Improved performance.
- Improved logging.
- Fix bug - Decrease the number of lambda invocations.
- Fix bug - Decrease lambda invocations payload size.
- Fix bug - Issues with scanning first commit on a repository.
- Fix bug - Issues when running "re-check" scan on main branch.
Before upgrading to a new Spectral GitHub bot version, you should follow the required change instructions below:
Lambda and Docker:
Remove the empty environment variable if it exists. The new bot does not treat empty environment variables as non-existent.
Go to lambda backend/frontend -> Configuration tab -> environment variables -> edit and remove all the variables with empty values.
Environment Variables name changes:
- APP_ID->- GITHUB_APP_ID
- WEBHOOK_SECRET->- GITHUB_WEBHOOK_SECRET
- PRIVATE_KEY->- GITHUB_PRIVATE_KEY
- SHOULD_POST_REVIEW_COMMENTS->- GITHUB_SHOULD_POST_REVIEW_COMMENTS
- SHOULD_SKIP_GITHUB_CHECK->- GITHUB_SHOULD_SKIP_CHECK
- SPECTRAL_DSN_VAULT_KEY->- VAULT_KEY_SPECTRAL_DSN
- PRIVATE_KEY_VAULT_KEY->- VAULT_KEY_GITHUB_PRIVATE_KEY
- WEBHOOK_SECRET_VAULT_KEY->- VAULT_KEY_GITHUB_WEBHOOK_SECRET
- REPOS_BLACKLIST_BUCKET_NAME->- S3_BLACK_LIST_BUCKET_NAME
- REPOS_BLACKLIST_OBJECT_KEY->- S3_BLACK_LIST_OBJECT_KEY
Lambda only:
- Upload the new zip files frontend and backend
- Update runtime settings to work with Node.js 20.x on Lambda's frontend and backend.
- Under "runtime settings" change the handlers
- On frontend from "src/frontend.app" to "index.handler"
- On backend from "src/backend.app" to "index.handler"
 
- Make sure that the HOMEenvironment variable is set to/tmpin the lambda configuration (See Integration Environment Variables section).
Updated about 2 months ago