CI Integration

To run a security scan automatically whenever you push code or open a pull/merge request, add a scan trigger step to your CI pipeline. Not only source code but also container images and web services integrate the same way.

Which types are supported

CI triggers are configured per service. The scans you can run and what they scan depend on the service type.

Service type	Scans you can run	Scan target
Source Code (Git)	SAST, SCA, SBOM, IaC, Secret	The Git source at the branch/commit in the request
Container Images	Image SCA, SBOM, Image hardening	A registry image (a specific image, or the latest image automatically)
Web Services (DAST)	DAST	The domain whose ownership is verified

The scan types actually shown are limited to the analyses enabled on that service.

Servers/hosts and SBOM upload are not CI targets

Server / Host and SBOM upload do not support CI triggers. Run these manually or on a periodic scan schedule instead.

Setup steps

Work in the [CI Trigger] menu in the service scope.

Issue a token : Generate an authentication token. The token is shown only once, so copy it immediately. Regenerating a token invalidates the old one instantly.
Enable the trigger and pick scan types : Turn the trigger on and choose which scans run on push. For container image services, you can specify a target image or select the latest image (automatic). With the latest image, CI scans whatever image it just built/pushed each time.
Store it as a CI secret : Register the token as the secret variable VULINDER_CI_TOKEN in your CI tool. Never put the token in code in plaintext.
Add the snippet to your pipeline : Add the tool-specific snippet below to your repository. The [CI Trigger] screen shows the exact inbound webhook URL and snippet for your service.
Commit/push : The pipeline runs, and at that step the scan is automatically queued.

Request contract

The pipeline step calls an inbound webhook. The request does not carry a service ID. The token identifies the service.

Method/address : POST <inbound webhook URL> (format: .../api/v1/webhook/ci/scan). The exact address is shown on the [CI Trigger] screen.
Header : X-CI-Token: <your token>
Body (JSON, optional) : { "branch": "...", "commit": "..." }. If omitted, the service default branch is used.
Response (200) : { "queued": [...], "failed": [...] }, returning the scans that were queued along with any that failed.

Snippets by tool

Reference the token via each tool's secret variable (VULINDER_CI_TOKEN), and replace <inbound webhook URL> below with the address shown on the [CI Trigger] screen.

GitLab CI

vulinder-security-scan:
  stage: test
  image: curlimages/curl:latest
  script:
    - >
      curl -fsS -X POST "<inbound webhook URL>"
      -H "X-CI-Token: $VULINDER_CI_TOKEN"
      -H "Content-Type: application/json"
      -d "{\"branch\":\"$CI_COMMIT_REF_NAME\",\"commit\":\"$CI_COMMIT_SHA\"}"

GitHub Actions

Register VULINDER_CI_TOKEN under Settings > Secrets and variables > Actions, then add .github/workflows/vulinder-security.yml.

name: Vulinder Security Scan
on: [push, pull_request]
jobs:
  trigger-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Vulinder scan
        run: |
          curl -fsS -X POST "<inbound webhook URL>" \
            -H "X-CI-Token: ${{ secrets.VULINDER_CI_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d "{\"branch\":\"${{ github.ref_name }}\",\"commit\":\"${{ github.sha }}\"}"

Jenkins

Register VULINDER_CI_TOKEN as a Secret text credential under Manage Jenkins > Credentials, then add it to your Jenkinsfile.

pipeline {
  agent any
  stages {
    stage('Vulinder Security Scan') {
      steps {
        withCredentials([string(credentialsId: 'VULINDER_CI_TOKEN', variable: 'VULINDER_CI_TOKEN')]) {
          sh '''
            curl -fsS -X POST "<inbound webhook URL>" \
              -H "X-CI-Token: $VULINDER_CI_TOKEN" \
              -H "Content-Type: application/json" \
              -d "{\"branch\":\"${GIT_BRANCH}\",\"commit\":\"${GIT_COMMIT}\"}"
          '''
        }
      }
    }
  }
}

Behavior and limits

Authentication failure : If the token is missing, wrong, or the trigger is disabled, the request is rejected (401). Disabling the trigger blocks inbound requests even with a valid token.
Rate limit : To stop invalid-token spam, requests are limited to 30 per minute per IP.
In-progress scan cap : If a service already has too many scans in progress, requests are briefly rejected (429). CI can simply retry after a short wait. Repeated calls on the same branch in quick succession are automatically deduplicated.
Native repository webhooks : Only the CI pipeline integration is supported today. Native repository Settings webhooks are in preparation.

Next steps

TypeSource Code (Git)Enable SAST, SCA, Secret, IaC, SBOM TypeContainer ImagesRegistry image SCA and hardening Use resultsTriageReview and handle automated scan results Use resultsNotification channelsGet scan completion alerts

Which types are supported​

Setup steps​

Request contract​

Snippets by tool​

GitLab CI​

GitHub Actions​

Jenkins​

Behavior and limits​

Next steps​