Run a scan on the whole repository
Here's an example of a basic GitLab CI configuration that uses Spectral:
build-job: stage: build script: - curl -L "https://app.spectralops.io/latest/x/sh?dsn=$SPECTRAL_DSN" | sh # This takes your SPECTRAL_DSN from the variables store in Gitlab CI/CD - $HOME/.spectral/spectral scan --ok --include-tags base,audit
It's recommended to verify the digest of a downloaded runnable file before you run it. You can use Spectral's Preflight to verify. Follow this link to see SHA digests of the binary, the download script and the gzip.
Store your SPECTRAL_DSN in Gitlab CI/CD Variables.
tags you want to include in your scan (or any other flag / arg) directly in the YML.
Run a scan focusing on changed files (Docker based)
Gitlab pipeline scanner brings optimal developer experience by focusing on the actual problems in your change set.
There are two running run modes possible for the job:
- On a Merge Request event - when the job runs in a merge request context, the files that have been changed in this merge request are being scanned (it is highly recommended changing the repository configuration so that merges can only be done if the pipeline is successful).
- After a standalone Push - If the job runs without a merge request context, it calculates the diff (changed files) between the last commit, and the last commit before the push, and runs the scan on those files.
The integration is done by a job (defined in
gitlab-ci.yml), running a dedicated docker image called
You can also define the trigger for this job by using the
rules property as shown in the examples below.
NOTE: This is a docker based job, therefore it should run in a GitLab runner using docker executor.
Store the next variables in Gitlab CI/CD Variables:
|GITLAB_TOKEN||Yes||Generate it in your Gitlab profile -> Access Tokens, check the "api" scope (leave blank if you are using vault)|
|SELF_HOSTED_GITLAB_DOMAIN||Yes||if you're running a self-hosted Gitlab provide the domain here. eg. https://my-gitlab-domain.com|
|SPECTRAL_DSN||Yes||Your Spectral DSN retrieved from SpectralOps (leave blank if you are using vault)|
|SPECTRAL_TAGS||No||Tags list to run Spectral with, separated by commas (eg base,iac,audit)|
|SPECTRAL_ENGINES||No||Engines list to run Spectral with, separated by commas (eg secrets,iac,oss). Default is 'secrets'|
|STRICT_MODE||No||If set to true, check status is based on all issues found in the modified files (even if the issues are old)|
Running after merge requests events:
spectral-scan: stage: test # specify which stage the job should run allow_failure: true # should the job fail the whole pipline image: checkpoint/spectral-gitlab-pipeline-scanner:latest script: - /usr/src/app/scanner rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
Running after a direct push to the main branch:
spectral-scan: stage: test # specify which stage the job should run allow_failure: true # should the job fail the whole pipline image: checkpoint/spectral-gitlab-pipeline-scanner:latest script: - /usr/src/app/scanner rules: - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
NOTE: The advanced integration is currently supported only on Standalone GitLab servers.
In case you wish to secure your merge requests without using pipelines, you can use Spectral GitLab webhook scanner.
Updated 4 months ago