Grant a scanner the least access that lets it do the job you turned on, and limit it to named repositories. Read access to repository contents is usually the starting point. Write access, such as opening pull requests or posting checks, should be a separate decision made feature by feature.
What GitHub's own documentation says
GitHub's guidance for apps is direct: GitHub Apps have no permissions by default, and an app's developer should select the minimum permissions required. Permissions are grouped as repository, organization, enterprise or account permissions. When you install an app you see and approve the repository and organization permissions it requested. That approval screen is your control point, so read it.
Match permissions to features
| If you want | The scanner usually needs | Ask about |
|---|---|---|
| Dependency inventory from manifests | Read access to repository contents | Does it clone, or fetch files through the API? |
| Pull request comments or status checks | Write access to checks or pull requests | Can it post without write access to code? |
| Automated fix pull requests | Write access to contents and pull requests | Are they off by default, and do they need review? |
| Alert sync with issues | Issues access | Do you need it, or will a ticket integration do? |
| Org wide discovery | Organization level read | Can it be scoped to selected repositories? |
Treat the table as a prompt for questions, not a spec. Exact permission names change, so check the current list in GitHub's documentation and in the vendor's installation notes.
A staged rollout
- Pilot repositories only. Install on a handful of non-critical repositories, not the whole organization.
- Read only first. Turn on inventory scanning with contents read access.
- Add checks. If you want pull request feedback, grant that one extra permission and review the change.
- Fixes last. Allow write access for fix pull requests only after the team trusts the output, and keep branch protection so a human merges.
- Review quarterly. Re-read the installation's permissions and repository list. Remove what is unused.
Branch protection and required reviews matter here. Even if an app can open pull requests, a person should decide what merges. For choices about credentials and identity, see deploy keys vs GitHub apps vs machine users.
Questions for the vendor
- Which permissions do you request, and why does each one exist?
- Which are optional, and what do I lose by declining them?
- When you add a permission in a new version, how will we be told? GitHub asks installers to approve new permissions, so make sure someone watches for that email.
- How are installation tokens stored, and how long do they live?
- Do you clone code to your servers or read it through the API on demand?
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a pull request check gates a change, then ask which permission that behaviour needs.
How Safeguard fits
Safeguard's autonomous remediation with fix pull requests is off by default, with every category set to Manual, so write actions are your decision. Try the free scan first.
Quick check
Should I install on all repositories?
Start with selected repositories. Expand when you have reviewed what the tool does with its access.
Is read access to contents harmless?
No. It lets the app read your source. That is why you ask where the code is processed and how long copies live.
Sources
Last reviewed: 19 October 2026.
