Scanning dependencies needs read access to repository contents and manifests, not write access. Write permission is only needed if you turn on a feature that opens pull requests or commits fixes. Start read-only, add write access later for chosen repositories if you want fix pull requests, and review what the connection can actually do.
Two different jobs
| Job | Needs | Risk if over-permissioned |
|---|---|---|
| Scan and report | Read contents and metadata | Source exposure |
| Open fix pull requests | Write to branches, create pull requests | Unreviewed changes reaching the repo |
| Comment on pull requests | Write pull request comments | Low, but still a write scope |
| Block merges | A status check or required check | Pipeline disruption if misconfigured |
Many connection flows ask for one broad permission that covers all four. That is convenient, and it is worth questioning.
How to scope the connection
- Start read-only. Connect a small set of repositories and confirm the scan works.
- Choose repositories explicitly. Prefer a selected list over "all repositories", especially if your organization contains sensitive code.
- Add write access later, narrowly. If you want fix pull requests, enable them on a few repositories first.
- Keep branch protection on. A fix pull request should still need review and passing checks. Require them in your source control settings, not in the scanner.
- Use a dedicated identity. A named bot or app account makes its actions easy to find in the audit log and easy to revoke.
Fix automation should be opt in
For fix pull requests, the safe default is off. Safeguard's autonomous remediation with fix pull requests is off by default, and every category starts on Manual, so nothing is opened until you choose. Whatever tool you use, ask what the default is and how you change it per repository or category.
Questions to ask a vendor
- What exact permissions does the integration request, and why each one?
- Can we grant read-only first and upgrade later without reinstalling?
- Can we restrict to selected repositories?
- Is every action by the integration shown in our source control audit log?
- How do we revoke access, and what happens to stored data afterward?
Test it in your trial
Connect read-only and run a scan. Then try something that needs write access, such as a fix pull request, and confirm that it fails with a clear message. A tool that works around missing permission is a tool worth another look.
A worked example: phased permissions
A company with 200 repositories wants SCA and is curious about fix pull requests.
Week one: install the integration with read-only access to twelve chosen repositories covering different teams and languages. Scans run, and findings appear. Nothing can change in source control.
Week three: the security lead reviews finding quality and decides fix pull requests are worth testing. A new, separate permission is granted for three repositories owned by a team that volunteered. Branch protection on those repositories requires one human review and passing checks. Fix pull requests are set to manual, so each one is opened only on request.
Week six: the team reviews merged fix pull requests, counts how many needed edits, and decides whether to widen. Write permission stays limited to the repositories that opted in.
At no point did the integration receive more access than the current phase required.
Step by step: audit an integration's permissions
- Open the installed app or token settings in your source control system.
- List each permission, such as contents, pull requests, metadata, and workflows.
- For each one, mark read or write.
- Ask the vendor why each write permission is needed and which feature uses it.
- Remove or downgrade any permission tied to a feature you are not using.
- Check which repositories the installation covers, and reduce to a chosen list if it covers all.
- Confirm in the audit log that actions by the integration appear under its own identity.
- Put a quarterly reminder on the calendar to repeat this review.
Workflows and secrets deserve extra attention
Permission to change workflow files can let an integration alter your pipeline, which may have access to secrets and deployment credentials. If a feature asks for it, understand why. For fork pull requests, avoid giving scan jobs access to secrets, because code from outside contributors should not run with them.
Alternatives to broad write access
You can often get most of the value with narrower options.
| Goal | Narrow approach |
|---|---|
| Scan repositories | Read-only integration, or scan in your CI with a token you control |
| Show results on pull requests | A check run or status, not repository write |
| Fix suggestions | Show the suggested change as a comment or patch for a person to apply |
| Fix pull requests | A dedicated bot account, limited repositories, protected branches |
Data side of the question
Read access means the vendor's system or your runner can see source files. Ask whether scanning needs full source or only manifests and lockfiles. If manifests are enough, you reduce exposure. If your policy keeps code in your own environment, ask whether the scanner can run there and what data is sent back.
Document the decision
Record what was granted, to which repositories, for which feature, who approved it, and when it will be reviewed. That record answers a customer or auditor question about third party access to source control, and it is easy to produce if you keep it up as you go.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice where a human reviews the change before it lands, and which permission that step would need.
Quick check
Is read access to source code a concern by itself?
It can be, depending on your data rules. Ask whether scanning can run from manifests alone or in your own environment.
Should the scanner be able to merge its own pull requests?
Usually not. Keep human review and required checks in your source control settings.
What should I do if a vendor insists on broad write access?
Ask which feature needs it and whether that feature can be turned off. If scanning requires write access you do not want to grant, treat it as a gap in the product.
Last reviewed: 19 October 2026.
