Skip to main content
VulnScan can run from the CLI in CI/CD pipelines to identify vulnerabilities before applications are released. The most common model is to scan a staging or preview deployment after the application has been built and deployed.

​
When to Integrate VulnScan

Use CI/CD integration when:
  • The application has a stable staging or preview environment.
  • Development teams want web/API security feedback before release.
  • Release governance requires security test evidence.
  • JSON/CSV output should be imported into issue tracking or data platforms.
  • Important endpoints should be scanned after selected builds.
Avoid scanning production on every commit unless traffic, scope, and timing are carefully controlled.
  1. Build the application.
  2. Deploy to staging or a preview environment.
  3. Run smoke tests.
  4. Run the VulnScan CLI against the staging URL.
  5. Export JSON/CSV into the build artifacts directory.
  6. Import results into issue tracking or report storage.
  7. Optionally block release on Critical or new High findings.

​
CLI Example

vulnscan scan --target https://staging.acme.com --output ./security-reports --format json,csv --lang en
API with token: 
vulnscan scan --target https://api-staging.acme.com -H "Authorization: Bearer $VULNSCAN_API_TOKEN" --output ./security-reports --format json,csv
Multiple targets: 
vulnscan scan --target-file ./ci-targets.txt --output ./security-reports --format json,csv

​
GitHub Actions

name: Security Scan

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  vulnscan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run VulnScan
        env:
          VULNSCAN_TOKEN: ${{ secrets.VULNSCAN_TOKEN }}
        run: |
          ./vulnscan scan \
            --target https://staging.acme.com \
            -H "Authorization: Bearer $VULNSCAN_TOKEN" \
            --output ./security-reports \
            --format json,csv \
            --lang en

      - name: Upload reports
        uses: actions/upload-artifact@v4
        with:
          name: vulnscan-reports
          path: security-reports/

​
GitLab CI

vulnscan:
  stage: test
  script:
    - ./vulnscan scan --target https://staging.acme.com --output ./security-reports --format json,csv --lang en
  artifacts:
    when: always
    paths:
      - security-reports/

​
Jenkins Pipeline

pipeline {
  agent any
  stages {
    stage('VulnScan') {
      steps {
        sh './vulnscan scan --target https://staging.acme.com --output ./security-reports --format json,csv --lang en'
      }
    }
  }
  post {
    always {
      archiveArtifacts artifacts: 'security-reports/**', fingerprint: true
    }
  }
}

​
Release Gates

A practical starting policy:
  • Block release on Critical findings.
  • Require security approval for new High findings.
  • Allow Medium/Low findings when remediation is tracked.
  • Always archive JSON/CSV for traceability.
Start in warning-only mode for the first few sprints if the pipeline and target scope are still being tuned.

​
Secret Handling

  • Store tokens in the CI/CD secret store.
  • Do not print tokens in logs.
  • Use staging-specific tokens.
  • Revoke tokens when the pipeline no longer needs them.
  • Grant only the permissions required for testing.

​
Web UI Consistency

When the CLI uses the same workspace configuration as the Web UI, pipeline scans can be persisted to the same database. Security teams can then review pipeline results beside manual scans and scheduled scans.