Back to Cerbi Scanner

Documentation

CI/CD integration

Azure DevOps teams can install Scanner from Visual Studio Marketplace. GitHub Actions and other CI systems run the same Scanner engine through the CLI. Start report-only, then enable a failure threshold when the team is ready.

Azure DevOps Marketplace — recommended for Azure DevOps teams

The free Azure DevOps extension is currently version 1.2.4. Install it from Visual Studio Marketplace, then use CerbiScan@1 in an existing pipeline. The extension is a pipeline wrapper around the same Scanner CLI and does not implement a separate detection engine.

Install Cerbi Scanner from Visual Studio Marketplace

steps:
- task: UseDotNet@2
  displayName: Install .NET 10 SDK
  inputs:
    packageType: sdk
    version: 10.0.x

- task: CerbiScan@1
  displayName: Cerbi logging governance scan
  inputs:
    scanPath: $(Build.SourcesDirectory)
    failOn: none
    jsonOutput: $(Build.ArtifactStagingDirectory)/cerbi/cerbi-results.json
    sarifOutput: $(Build.ArtifactStagingDirectory)/cerbi/cerbi-results.sarif
    markdownSummary: $(Build.ArtifactStagingDirectory)/cerbi/cerbi-report.md
    publishArtifacts: true

Add policyPath: $(Build.SourcesDirectory)/cerbi-policy.yml when the repository carries an explicit policy. For a gate, use a supported threshold such as failOn: high or failOn: error.

Why use the Marketplace path?

For Azure DevOps teams, the Marketplace extension provides the familiar organization-level install and pipeline-task experience while keeping execution on the customer's existing build agent. It is a distribution option, not a different Scanner engine or a Microsoft endorsement of Cerbi.

GitHub Actions

GitHub Actions runs the Scanner CLI directly. There is no separate Cerbi GitHub Action required: set up .NET 10, install the global tool, then invoke cerbi-scanner scan.

name: Cerbi Governance Scan

on:
  pull_request:
  push:
    branches: [main]

jobs:
  cerbi-scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "10.x"

      - name: Install Cerbi Scanner
        run: dotnet tool install --global Cerbi.Scanner --version 1.1.0

      - name: Run Cerbi Scanner
        run: |
          mkdir -p cerbi-results
          cerbi-scanner scan \
            --path . \
            --fail-on none \
            --format json --output cerbi-results/cerbi-report.json \
            --sarif cerbi-results/cerbi-report.sarif \
            --summary cerbi-results/cerbi-summary.md \
            --no-snippets

      - name: Upload SARIF
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: cerbi-results/cerbi-report.sarif
          category: cerbi-governance

Change --fail-on none to --fail-on error when high-severity findings should fail the job.

Reports

FormatTypical use
JSONAutomation, parsing, metrics, and archival.
SARIF 2.1.0Static-analysis and code-scanning ingestion.
MarkdownHuman-readable build and review summaries.
HTMLLocal human-readable report output.

Safe rollout pattern

  1. Run locally or in CI with --fail-on none.
  2. Review false positives, policy gaps, and expected exceptions.
  3. Commit policy/configuration alongside the application.
  4. Only then enable the failure threshold your team actually wants to enforce.

Azure DevOps defaults

The Azure DevOps wrapper keeps source snippets disabled by default for shared CI artifacts, and CerbiShield upload is disabled by default. See Security & privacy for the data-flow details.
NEXTChoose your next proof

Use CerbiStream inside selected applications, Cerbi Gateway at the OpenTelemetry boundary, or both. CerbiShield keeps policy, rollout, violations, audit, and evidence under one governance program.

One initial workload/Customer-hosted in Azure/Existing destinations remain
Scanner CI/CD Integration — Cerbi Docs