A supply chain security platform usually needs read access to repositories and manifests, read access to container registries, and a way to see build results. Write access, such as opening fix pull requests, should be a separate, optional grant. Start read-only and add scopes only when a specific feature needs them.
Why access is the first review question
Your security team will ask what the tool can see and what it can change. That is the right instinct. A platform sits next to your source code and your pipelines, so a loose grant becomes a new risk. The goal is the smallest set of permissions that still gives a complete inventory.
The access ladder
Think in four rungs. Each one adds capability and risk.
| Rung | What it grants | Typical use |
|---|---|---|
| 1. Manifests only | Upload lockfiles or SBOMs yourself | Quick trial, no repository access |
| 2. Repository read | Read code and manifests via an app install | Continuous inventory, reachability |
| 3. CI integration | A scoped token to post results or fail a build | Gates on pull requests |
| 4. Repository write | Create branches and pull requests | Automated fix proposals |
Many teams stop at rung 3 for the first quarter. Rung 4 is worth enabling later, one repository at a time, with branch protection still requiring human review.
Questions to ask before you grant anything
- Can we scope the install to named repositories instead of the whole organization?
- Is the credential a short-lived app token or a long-lived personal token?
- Does the tool store source code, or only extracted metadata such as package names and versions?
- Where is data processed and kept, and how do we delete it?
- Is every action the platform takes written to an audit log we can export?
- Can we revoke access in one step and confirm nothing else holds a copy of the credential?
Write the answers down. They double as the vendor section of your own security review, and a buyer reviewing you may ask the same questions about your suppliers.
Safer ways to connect
- Prefer an app or OIDC based connection over a personal access token tied to one employee. When that person leaves, the token should not become a hidden dependency.
- Keep secrets for the platform in your CI secret store, never in repository files.
- Run the first scan against a non-production fork if the real repository is sensitive.
- Review the granted scopes after 30 days. Remove any that were never used.
What you can learn without any access
You can learn a lot from a manifest alone. A lockfile lists exact versions of direct and transitive packages. The npm documentation says that, as of npm v7, lockfiles include enough information to gain a complete picture of the package tree. Uploading a lockfile or an SBOM is a low-risk way to judge match quality and noise before you connect anything.
A worked example
Take a hypothetical team of forty engineers with sixty repositories. The security lead wants a platform evaluated, and the platform engineer wants the smallest possible blast radius. They agree on a staged plan.
In week one they upload lockfiles from six representative repositories by hand. No credentials are shared. They learn how accurate the inventory is and how noisy the findings are. In week two they install the platform's app on six named repositories with read only scope, and compare the results with the manual uploads. In week three they connect one CI pipeline with a token scoped to a single project and watch where it posts results. Only after the quarter ends do they discuss write access, and then for two repositories where the owners volunteer.
At every stage someone can answer the question what could this credential do if it leaked, and the answer stays small.
Reviewing a request for more access
When a vendor or a team asks for a wider scope, use a short form. Fill it in before approving.
| Field | Example answer |
|---|---|
| Feature that needs it | Opening fix pull requests |
| Scope requested | Write to branches and pull requests in two repositories |
| Why a narrower scope will not work | Creating a branch needs write access |
| Compensating control | Branch protection requires one human review, no direct merge |
| Expiry or review date | Review in 90 days |
| Revocation steps | Remove the app from the two repositories, rotate related secrets |
If the requester cannot fill in the compensating control, the answer is not yet.
What to log and watch
Turn on audit logging on the source host for the platform's identity. Review three things monthly: which repositories it touched, which API calls it made that you did not expect, and whether any token was used from an unfamiliar network location. A quiet log is the goal.
Offboarding the integration
Plan the exit when you plan the entry. If you stop using the platform, you should be able to remove the app, revoke tokens, delete stored data on request, and confirm in writing. Ask the vendor for its deletion process before you sign, and test it on a trial account if possible.
Special cases
- Private forks and sensitive repositories. Exclude them from the first phase.
- Monorepos. A single install grants access to everything in the repository, so check path level controls.
- Contractors. Do not let a vendor integration be configured from a personal account of a contractor who may leave.
- Self hosted source control. Check what network paths are required and whether they widen your exposure.
Try it yourself
Click through it at your own pace, or open it full screen. Open the demo and look at how much can be built from dependency data alone, without any access to source code.
Safeguard supports a free scan at gold.safeguard.sh/scan, which is a good rung 1 test. Its SBOM and dependency scanning, policies, and fix pull requests (off by default, every category on Manual) map onto the ladder above, so write scopes stay your decision.
Quick check
Does a platform need to read my source code?
Not always. Dependency matching works from manifests and lockfiles. Reachability analysis needs to see how code calls a library, so it needs more than manifests.
Should the platform be able to merge code?
No. Let it propose changes at most, and keep a human review step in branch protection.
Is read access to my code risky?
It carries some risk, which is why you scope it to named repositories, prefer short lived credentials, and ask how stored data is protected and deleted.
Sources
Last reviewed: 19 October 2026.
