CI/CD Integration — CarbonMantis

Why it matters

If it isn't automated, it doesn't happen

Manual, occasional security checks slip. A gate that runs on every pull request makes security testing continuous and non-negotiable — the same way unit tests and linting became table stakes. CarbonMantis gates deterministically on severity and confidence, so builds fail only on issues that are proven and worth blocking a release for. No noise, no flaky gates.

Two ways in

One-step wrappers, or the CLI anywhere

Platform wrappers — next

A published Action, Orb, Pipe, or Component for the leading platforms follows the CLI: add a few lines, set your API key as a secret, and you have a gate. Until they ship, the snippets below run the CLI directly on each platform — the same three commands everywhere.

The carbon CLI

A single static binary that runs on any runner, OS, or shell. If your pipeline can run a command, it can run CarbonMantis — so you're covered even on platforms without a wrapper.

One step on your platform

Copy, paste, gated — three commands on any platform

GitHub ActionsGitLab CIBitbucket PipelinesCircleCIJenkins

# .github/workflows/security.yml — the carbon CLI, no wrapper needed
name: security
on: [pull_request]

jobs:
  carbonmantis:
    runs-on: ubuntu-latest
    steps:
      - run: <install the carbon binary for your runner>   # one static binary
      - run: carbon scan start --config carbonmantis.yaml --wait
      - run: carbon scan gate --fail-on high --min-confidence confirmed
        env:
          CARBONMANTIS_API_KEY: ${{ secrets.CARBONMANTIS_API_KEY }}

# .gitlab-ci.yml
security:
  stage: test
  script:
    - <install the carbon binary for your runner>   # one static binary
    - carbon scan start --config carbonmantis.yaml --wait
    - carbon scan gate --fail-on high --min-confidence confirmed
# CARBONMANTIS_API_KEY set as a masked CI/CD variable

# bitbucket-pipelines.yml
pipelines:
  pull-requests:
    '**':
      - step:
          name: CarbonMantis
          script:
            - <install the carbon binary for your runner>   # one static binary
            - carbon scan start --config carbonmantis.yaml --wait
            - carbon scan gate --fail-on high --min-confidence confirmed
          # CARBONMANTIS_API_KEY from repository variables

# .circleci/config.yml
version: 2.1
jobs:
  carbonmantis:
    docker:
      - image: cimg/base:current
    steps:
      - run: <install the carbon binary for your runner>   # one static binary
      - run: carbon scan start --config carbonmantis.yaml --wait
      - run: carbon scan gate --fail-on high --min-confidence confirmed
workflows:
  security:
    jobs:
      - carbonmantis
          # context provides CARBONMANTIS_API_KEY

// Jenkinsfile
pipeline {
  agent any
  environment { CARBONMANTIS_API_KEY = credentials('carbonmantis-api-key') }
  stages {
    stage('Security gate') {
      steps {
        sh 'carbon scan gate --fail-on high --min-confidence confirmed'
      }
    }
  }
}

And everywhere else

If it runs a command, it runs CarbonMantis

No wrapper for your platform? The CLI has you covered. It's a single static binary with no runtime dependencies — drop it into any build script and gate the same way.

Azure PipelinesTravis CIDroneWoodpeckerBuildkiteTeamCityHarnessself-hosted runners

# any runner, any OS, any shell — one static binary
carbon scan start --config carbonmantis.yaml --wait
carbon scan gate --fail-on high --min-confidence confirmed

How the gate behaves

Deterministic by design

Severity + confidence

Combine --fail-on with --min-confidence so builds break only on issues that are both serious and proven.

Clear exit codes

0 pass · 1 findings above threshold ·2 scan error · 3 config error.

SARIF output

Emit SARIF v2.1.0 — the open standard — as a shareable record of every finding (more below).

See how findings and confidence work and the pay-as-you-scan pricing. Next on the roadmap: gating only the scan units a pull request added or changed — scan units have stable identity, so the diff between two inventories is cheap.

Findings where your team already looks

The gate blocks. SARIF keeps the record.

Failing the build is only half of it. CarbonMantis also emits SARIF v2.1.0, the OASIS-standard format for security results — so every finding can land in the tools your team already uses to review and track security, not just a failed job log.

On GitHub, one step uploads it to Code scanning. Each finding becomes an alert in your repository's Security tab — severity, rule, the affected endpoint, evidence, and remediation — and GitHub tracks it across scans: new alerts are flagged, fixed ones close automatically, and false positives can be dismissed. Every pull request gets a code-scanning check, so nothing new merges unseen.

Because CarbonMantis tests a running app, findings are located by endpoint, not a source line — so they complement source scanners like CodeQL rather than duplicate them. SARIF is an open standard, so the same file also opens in editors (such as VS Code) and feeds other platforms' code-scanning to the extent they support it; the exit-code gate is the universal path everywhere.

# publish results to Code scanning
- uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: carbonmantis-results.sarif

A security gate in every pipeline