How users sign in to BreachLens and how BreachLens reaches your code are separate questions with separate credentials. This page is about the second one. For the first — including GitHub Enterprise Server and the code-host-as-IdP anti-pattern — see Authentication.
Permissions, in plain terms
BreachLens reads your code through a GitHub App installation, not through your login. The two grants are unrelated:
When you install the App, GitHub shows you exactly what it asks for. Here’s what each permission is actually used for:
Add a repository
Open Repositories → Add repository and pick the path that fits how the repo is hosted.- From GitHub (App)
- By URL (PAT)
- From CI (CLI)
The one-click path for GitHub.com. Choose From GitHub and install the BreachLens GitHub App on the org or account that owns the repos.When GitHub asks which repositories to grant, you set the scope:
All repositories
New repos appear in BreachLens automatically — connect once, never return to GitHub. Read-only by default. Best for most teams.
Only select repositories
You hand-pick what the App can see. To scan a new repo later, add it to the installation from the Manage on GitHub link in the Add-repository modal.
Granting access is not scanning. The scope only controls which repos appear in the picker — nothing runs until you add a repo here and start a scan.
Run a scan
1
Open the repository
Go to Repositories and click a connected repo to open its detail page.
2
Start the scan
Click Run scan in the top-right. The default tier runs SAST + SCA + Secrets + IaC in parallel — for a typical small-to-medium repo, findings land in under a minute (roughly 15–45 seconds in our testing; large monorepos take longer).
3
Watch it, or walk away
A live progress panel shows phase, elapsed time, and findings as they land. Need to stop a run? Every running or pending scan has a Cancel control — on the progress panel, on the global Scans page, and on each repo’s Scans tab. Cancelling releases the job cleanly and marks it cancelled; you can re-run any time.
Gate pull requests (optional)
With the App’s Checks and Pull requests permissions granted, BreachLens posts a Check Run on every PR to a connected repo. A PR that introduces a new Critical/High finding fails the check, and — where a fix is available — the check comment carries a one-click Commit suggestion anchored to the exact diff hunk.Triage what matters
Open Findings, then filter by Severity: Critical, High and Has attack path: yes — that narrows a raw finding count down to what a real attacker could chain. Click any row to open the detail drawer: AI-suggested fix, reachability tier, attack-path context, and Generate auto-fix PR.How dependency (SCA) fixes work
Dependency findings get a deterministic fix — no AI. When a vulnerable package has a fixed release, BreachLens opens a PR that bumps its version in your manifest:package.json, composer.json, requirements*.txt, or go.mod. Scanners usually report the lockfile (package-lock.json, composer.lock, go.sum), so the fix targets the sibling manifest that generates it, and the PR is labelled manifest-only — regenerate your lockfile after merging so the resolved version updates. A package that isn’t declared directly in the manifest (pulled in transitively by another package) can’t be bumped this way; the drawer tells you when that’s the case rather than opening a PR that wouldn’t help.
Next steps
Scan GitHub posture
Check the account’s own configuration — branch protection, required reviewers, Dependabot alerts — across every repo, public and private.
Fit it into your pipeline
Where every tier plugs in — IDE, PR checks, CI gate, build, test, runtime — and what to configure at each.