GitHub App trust
We clone your repo to scan it.
Then we delete it. Every time.
Here's exactly what our GitHub App can access, what it never touches, and how the ephemeral clone it makes to run a scan gets wiped — with an audit log proving it.
Read-only by default
The App requests exactly five permission scopes — no more. It never has write access to your repository contents; the only write scopes are for posting a Check Run status and a PR comment.
| Scope | Access level | Why we need it |
|---|---|---|
| Contents | Read | To scan diffs and file contents for secrets and SAST issues. |
| Pull requests | Write | To post the scan summary and dismiss/triage comments on your PR. |
| Checks | Write | To show a pass/fail status on the PR that blocks merge on a real finding. |
| Members | Read | To confirm the person clicking a Check Run action has repo access. |
| Administration | Read | To read (never change) branch-protection status for the org audit. |
Select specific repositories
When you install the App, GitHub lets you choose "All repositories" or "Only select repositories." We recommend the latter — the smallest footprint that gets the job done. If an installation is scoped to all repos, your integration page in the dashboard flags it and links straight to GitHub's installation settings to narrow it.
Ephemeral clones, audited teardown
A repo scan makes a shallow, temporary clone (depth 50 for a full-repo scan, depth 1 for a single PR) into a directory that exists only for the life of that scan job — bounded to 90 seconds for a full-repo scan and 60 seconds for a PR scan.
The installation token used to authenticate the clone is written to a locked-down (0600) local git config file and never appears on a command line, in a log line, or in a thrown error — it exists only inside that same temporary directory.
When the scan finishes — pass, fail, or crash — the workspace is deleted, and that deletion is logged either way: a success line if it worked, an error line if it didn't. An hourly sweep also checks for anything left behind by a worker process that was killed mid-scan before it could run its own cleanup, and removes it.
We never persist your source code. What we store is structured finding metadata: a file path, a line number, a rule ID, and — for a leaked secret — a redacted fingerprint, never the secret itself.