CI/CD pipeline

BreachLens plugs into every stage of a delivery pipeline — from the moment a developer types a line of code, through PR review, build, deploy, and into runtime — with one engine, one correlation graph, and one auto-fix loop. This page maps each stage to the thing you configure there. The differentiator isn’t “runs security in the pipeline” — every vendor does that. It’s that the finding a developer sees as a red squiggly in their editor is the same finding that gates the PR, the same finding the dashboard ranks, and the same finding auto-fix closes. One source of truth, correlated across every stage — not seven tools with seven dashboards.

The map

BreachLens across the CI/CD pipeline: IDE, Commit/PR, Build, Test, Deploy/Run — every stage feeds one correlation engine.

Every stage feeds the same correlation engine, so a commit-stage code finding can be chained to a test-stage exploit proof and a deploy-stage cloud misconfiguration as one scored attack path.

Where you configure each stage

Stage	What runs	Where you set it up
IDE	Inline findings, scan-your-working-copy before push	Install the VS Code extension (also Cursor / Windsurf), connect it to your deployment
Commit / PR	SAST + secret detection, PR check runs, auto-fix PRs	Install the GitHub App with Checks + Pull requests permissions
CI (any stage)	Any tier, gate the build on severity	Generate a pipeline file in Settings → Integrations, or copy a template — GitHub Actions, GitLab CI, Jenkins
Build	SCA, IaC, container CVEs, signed SBOM	Run the CLI in the build job, or add container images / a cloud account
Test	DAST + autonomous pentest with Proof-of-Exploit	Add a web-app target pointed at your staging URL
Deploy / Run	Runtime sensors, continuous posture, attack-paths	See Continuous monitoring

Stage by stage

IDE — shift-left

Security inside the editor, before code is committed. The BreachLens VS Code extension is a thin client — no scanners bundled — so what the developer sees is identical to the dashboard and the PR. The editor and the platform never disagree.

Inline squigglies on the vulnerable line, coloured by real severity
Scan your working copy — an on-demand scan of uncommitted changes (code + secrets + IaC) before you push
Lightbulb actions: open in BreachLens, preview auto-fix as a side-by-side diff, apply it
Opt-in scan-on-save for mapped repos

Set up the IDE extension

Install, connect, and scan without leaving the editor.

Commit / PR — the static gate

When code lands, BreachLens runs SAST + secret detection and reports on the pull request:

PR / MR check runs — green/red status with a clickable deep-link
Inline PR comments — per-finding annotations on the diff, with a one-click Commit suggestion anchored to the exact hunk
Auto-fix PR — opens a separate PR with an AI-generated patch; merging it auto-resolves the original finding

This needs the GitHub App’s Checks and Pull requests permissions — see the permission matrix.

CI — gate the build from any runner

Run a scan and turn the result into an exit code — 0 passes, 1 fails the build — from GitHub Actions, GitLab CI, Jenkins, or any runner. The scan runs server-side; the runner only triggers it, so the job needs no scanners and no language runtime.

GitHub App vs pipeline file

The choice is per repo, never per policy: the rules live in one place (Settings → Policies) no matter which path a repo uses.

Aspect	GitHub App	Pipeline file
Turn it on	install once (org / all repos)	commit `breachlens.yml` per repo
Coverage	every repo, including new ones	only repos with the file
Where the gate runs	server-side PR check	your own CI runner
Works with	GitHub only	GitHub Actions, GitLab, Jenkins, self-hosted / air-gapped
In the repo	nothing	one YAML file to add + maintain

Use the GitHub App for blanket coverage of your GitHub repos — no file, and new repos are gated automatically. Use a pipeline file for GitLab / Jenkins, self-hosted or air-gapped runners, or when the gate must run inside your own pipeline. Mixed estates use both — they share the one org policy. The rest of this section covers the pipeline-file path.

Generate a pipeline file

Fastest path — generate a file. Open Settings → Integrations → CI/CD pipeline file and pick your platform, the scan shape, the severity gate, and whether you’re behind Cloudflare Access. The generator emits a ready-to-paste file plus the exact secrets to add. Nothing is saved, and no secret value is ever written into the file — it references them by name. If your org has a default policy (Settings → Policies), the severity-gate picker can tie the file to it two ways. Match bakes the equivalent fixed severity into the file. Use my org policy sets severity-gate: policy — instead of counting findings locally, the runner asks BreachLens for the verdict on every run, so the pipeline always follows your current policy and can never disagree with the GitHub-App PR check. Change the policy centrally and every pipeline follows it — no file to regenerate. For GitHub Actions, the panel goes a step further: pick a connected repository and it hands you one-click links to commit the pre-filled workflow, mint a scoped token, and open GitHub’s secret and branch-protection settings — with your deployment’s API URL detected for you. The token still goes into GitHub’s own encrypted secret store (a secret value never rides in a URL), so you paste it in the one place it belongs. Prefer to copy from source? The canonical templates — one per platform — all share the same trigger → poll → SARIF → severity-gate contract:

# .github/workflows/breachlens.yml — wraps the published action;
# auto-onboards the repo and uploads SARIF to the Security tab.
- uses: breachlens-dev/breachlens-action@v1
  with:
    api-url:   ${{ vars.BREACHLENS_API_URL }}
    api-token: ${{ secrets.BREACHLENS_API_TOKEN }}
    severity-gate: HIGH

# .gitlab-ci.yml — include the shared job, set two variables.
include:
  - remote: 'https://raw.githubusercontent.com/breachlens-dev/breachlens-action/main/gitlab/breachlens-scan.gitlab-ci.yml'
variables:
  BREACHLENS_REPO_ID: "<your-repo-id>"
  BREACHLENS_SEVERITY_GATE: "HIGH"

// Jenkinsfile — declarative pipeline, curl-based, alpine agent.
// Full template:
// github.com/breachlens-dev/breachlens-action → jenkins/Jenkinsfile
pipeline {
  agent { docker { image 'alpine:3.20' } }
  environment {
    BREACHLENS_API_TOKEN = credentials('breachlens-api-token')
  }
  stages {
    stage('BreachLens scan') {
      steps {
        sh 'curl … /api/repos/$ID/scan; poll; gate'
      }
    }
  }
}

Two shapes belong on different triggers — the generator produces the right one for each:

Code gate — SAST / SCA / Secrets / IaC on push + PR; blocks the merge.
Deployed-app scan — DAST on a schedule; never blocks a PR.

On the GitHub App already? Your repos are scanned automatically on push + PR — you only need a pipeline file when you want the gate to run inside your own pipeline: a branch-protection required check, self-hosted / air-gapped runners, or non-GitHub CI.

Start with severity-gate: none (report-only) so you see findings without breaking builds, then tighten to HIGH or CRITICAL once the team has triaged the baseline.

Build — dependencies, supply chain, IaC

The build stage pulls in third-party code and ships an artifact. BreachLens secures both:

SCA — known-vulnerability + license analysis across common package ecosystems, with function-level reachability on supported languages so you patch what’s actually called first
IaC — Terraform / Kubernetes / CloudFormation / Helm misconfiguration analysis
Container image scanning — CVE detection on built images, with reachability tiering
Signed SBOM — CycloneDX / SPDX bill of materials with verifiable signatures for procurement evidence

Test — dynamic testing and exploit proof

Once built, the running app is tested from the outside in — the noisiest stage of the pipeline, and where BreachLens’s strongest differentiator lives:

DAST — outside-in active scanning (XSS, injection, CSRF, XXE, auth/session flaws), with authenticated form-login and recorded-session modes
Autonomous pentest — multi-tool exploit orchestration that goes beyond detection to exploitation
Proof-of-Exploit — a CONFIRMED finding ships wire-level Request/Response evidence, with a reproducible curl or, for browser-driven exploits, an exploit-replay video. A confirmed finding is never a “maybe.”

Deploy / Run — runtime and posture

Once live, BreachLens keeps watching — runtime sensors, continuous posture, and cross-tier attack paths — and closes the loop with auto-fix PRs, ticketing, and alerts. That’s its own topic:

Continuous monitoring

Event-driven re-scans, scheduled posture, and 24/7 runtime detection — the always-on half of the pipeline.

What BreachLens deliberately does not do

Honest scoping matters in a security evaluation. Three capabilities from the classic toolset are not in BreachLens today — deliberate architectural boundaries, not oversights:

Capability	Why it’s out of scope
IAST (in-app instrumentation agent)	Requires an agent inside the app process. BreachLens is external-scan + thin-client IDE; DAST + autonomous pentest cover the dynamic-testing need with reproducible Proof-of-Exploit.
RASP (in-app runtime blocking)	Also runs inside the app process. BreachLens’s deploy-stage coverage is detection (host / workload sensors), not in-app self-protection.
Just-in-time privileged access	BreachLens has role / capability / scope-based access control, but not time-boxed “grant for 1 hour” elevation.

For the self-hosted, regulated lane BreachLens leads with — deployable in disconnected networks — the runtime-detection tier and external-scan model cover the practical need.

Next steps

Set up the IDE extension

Inline findings and scan your working copy before you push.

Connect your repositories

Install the App for PR checks and one-click auto-fix PRs.

Add a web-app target

DAST and autonomous pentest with reproducible Proof-of-Exploit.

Monitor continuously

Event-driven re-scans and 24/7 runtime detection after deploy.

Getting started

Deployment

Platform

Scanning

AI & identity

Pipeline & monitoring

IDE

Reference

API playground

The map

Where you configure each stage

Stage by stage

IDE — shift-left

Set up the IDE extension

Commit / PR — the static gate

CI — gate the build from any runner

GitHub App vs pipeline file

Generate a pipeline file

Build — dependencies, supply chain, IaC

Test — dynamic testing and exploit proof

Deploy / Run — runtime and posture

Continuous monitoring

What BreachLens deliberately does not do

Next steps

Set up the IDE extension

Connect your repositories

Add a web-app target

Monitor continuously

​The map

​Where you configure each stage

​Stage by stage

​IDE — shift-left

Set up the IDE extension

​Commit / PR — the static gate

​CI — gate the build from any runner

​GitHub App vs pipeline file

​Generate a pipeline file

​Build — dependencies, supply chain, IaC

​Test — dynamic testing and exploit proof

​Deploy / Run — runtime and posture

Continuous monitoring

​What BreachLens deliberately does not do

​Next steps

Set up the IDE extension

Connect your repositories

Add a web-app target

Monitor continuously

The map

Where you configure each stage

Stage by stage

IDE — shift-left

Commit / PR — the static gate

CI — gate the build from any runner

GitHub App vs pipeline file

Generate a pipeline file

Build — dependencies, supply chain, IaC

Test — dynamic testing and exploit proof

Deploy / Run — runtime and posture

What BreachLens deliberately does not do

Next steps