> ## Documentation Index
> Fetch the complete documentation index at: https://docs.breachlens.app/llms.txt
> Use this file to discover all available pages before exploring further.
# CI/CD pipeline
> Where BreachLens plugs into each stage of your pipeline — from the editor to runtime — and exactly what to configure at each one.
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
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](/ide/vscode) (also Cursor / Windsurf), connect it to your deployment |
| **Commit / PR** | SAST + secret detection, PR check runs, auto-fix PRs | Install the [GitHub App](/scanning/repositories) 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](https://github.com/breachlens-dev/breachlens-action) — GitHub Actions, GitLab CI, Jenkins |
| **Build** | SCA, IaC, container CVEs, signed SBOM | Run the CLI in the build job, or add [container images](/scanning/containers) / a [cloud account](/scanning/cloud) |
| **Test** | DAST + autonomous pentest with Proof-of-Exploit | Add a [web-app target](/scanning/domains) pointed at your staging URL |
| **Deploy / Run** | Runtime sensors, continuous posture, attack-paths | See [Continuous monitoring](/pipeline/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
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](/scanning/repositories#permissions-in-plain-terms).
### 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.
```mermaid theme={null}
flowchart TB
subgraph gh ["GitHub App — install once"]
A([App]) --> R1[repo A]
A --> R2[repo B]
A --> R3["new repo ✓"]
end
subgraph pf ["Pipeline file — per repo, any CI"]
P1["repo X · yml"]
P2["repo Y · yml"]
P3["repo Z · yml"]
end
gh -->|PR check| POL["Settings → Policies
org default policy"]
pf -->|"gate: policy"| POL
```
| 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](https://github.com/breachlens-dev/breachlens-action) — one per platform — all share the same trigger → poll → SARIF → severity-gate contract:
```yaml GitHub Actions theme={null}
# .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
```
```yaml GitLab CI theme={null}
# .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: ""
BREACHLENS_SEVERITY_GATE: "HIGH"
```
```groovy Jenkins theme={null}
// 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:
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
Inline findings and scan your working copy before you push.
Install the App for PR checks and one-click auto-fix PRs.
DAST and autonomous pentest with reproducible Proof-of-Exploit.
Event-driven re-scans and 24/7 runtime detection after deploy.