The GitHub App
Install it on one repository
On this path we analyse a pull request when it opens and leave a check run on it — counts, paths and modules, never a verdict. The check run is always neutral: there is no branch of our code that can fail your build. The one thing the App writes is a pull request you review — one instrumentation file, on a branch of its own, opened only when you ask for it in MLReps.
Scope by scope
What your security team will ask
| Permission | Level | What it is for |
|---|---|---|
| contents | write | the tree and the diff — and one file, in a pull request |
| pull_requests | write | our own comment, and the one pull request below |
| checks | write | our own check run. Never anybody else's |
| metadata | read | unavoidable |
Refused permanently: workflow, administration, secrets, actions, members.
We cannot modify your code even if we are fully compromised — the permission does not exist on the installation, and GitHub will show you the same four on its consent screen before you agree to anything.
And afterwards
What we keep
Findings — a path, a line, a rule and a class — and the graph of identifiers and metrics they came from. Never your source, never a diff, never anything a model said about either. Credentials we find in your code are removed before anything is stored or posted. And there is no column anywhere for who dismissed a finding, so that feature cannot be built without changing a schema in public.
What we ask of you
Start with one repository
GitHub will offer you every repository in the organisation on the next screen. Choose one — ideally one with active pull requests and a test suite. You will see what the tool says about code you already understand, which is the only way to judge whether it is worth widening.