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_MODE
is 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
.zip
file. - Unzip the downloaded file.
- Download the Lambda code as a
-
Add
multi_app.json
:- Place the
multi_app.json
file 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
.zip
file to AWS Lambda, ensuring themulti_app.json
file 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.json
The 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 toCHECK_POLICY
. Refer to the table above for possible values.spectral_dsn
: Allows splitting scans using a different DSN for this GitHub App. It defaults toSPECTRAL_DSN
.webhook_token
: Allows using a webhook secret for this GitHub App. It defaults toGITHUB_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 toGITHUB_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 ofSpectral_Dsn-*
VAULT_KEY_GITHUB_WEBHOOK_SECRET
- GitHub app webhook secret, should be in the format ofSpectral_GithubBot_WebhookSecret-*
VAULT_KEY_GITHUB_PRIVATE_KEY
- Private key, should be in the format ofSpectral_GithubBot_PrivateKey-*
VAULT_KEY_CUSTOM_SSL_CERTIFICATE
- (Optional) - key for vault containing self signed certificate. Default value isSpectral_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
Errors
metric for the lambda and click onSelect Metric
. - Set the statistic to be
Sum
and select the required period for the threshold measuring. - Under conditions, choose
static
threshold, chooseGreater
, and set the threshold value to at least 1. ClickNext
. - Insert to Emails be to be alarmed. Click
Next
, name the alarm and clickNext
again. - 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
HOME
environment variable is set to/tmp
in the lambda configuration (See Integration Environment Variables section).
Updated 3 months ago