Keep a dependency scanning PoC away from production by giving the tool read only access to selected repositories, running tests on throwaway branches, switching off any automatic pull requests or merges, using short lived scoped tokens, and writing down a revoke date on day one.
The risks are ordinary ones
A trial tool is software you do not yet trust. The risks are simple: it holds credentials to your code, it may write to repositories if allowed, and it may keep data after the trial. Each has a plain control.
The checklist
| Control | What to do |
|---|---|
| Read only access | Grant read permission on named repos only, never the whole organization |
| No write by default | Turn off automatic fix pull requests, comments that change files, and any merge rights |
| Throwaway branches | Run seeded tests and fix loop tests on branches that are deleted after |
| Scoped tokens | Use a dedicated service account, not a person's token |
| Expiry | Set tokens to expire at the end of the trial, or earlier |
| Separate runner | If the tool runs in CI, use a runner with no deploy credentials |
| Log review | Check audit logs for what the tool accessed |
| Revoke on exit | Remove the app, token and webhook on the end date |
Read only first, write later
Opt into write features one at a time, on one repo, with a human reviewing every change. If you want to test automated fix pull requests, that is a separate, deliberate step. Our post on piloting automated fixes on one repo first walks through it.
CI is the sensitive spot
A scanner step in CI runs inside your pipeline, often next to secrets. Put the trial job in a separate workflow with minimal permissions. It should not have deploy keys, cloud credentials or the ability to push. If the scanner needs a token to reach its service, store it as a CI secret scoped to that job only.
One more habit: pin the scanner's version or image digest for the trial. A tool that updates itself in the middle of your test makes results harder to compare and gives a changed binary access to your pipeline.
Do not scan what you cannot explain
Leave out repositories with regulated data, customer code you hold under contract, or anything where nobody can tell you whether a third party is allowed to see the dependency list. Ask first. This post is not legal advice, so involve the right people for those cases.
What to log
- Which accounts were granted access, when, and by whom.
- Which repositories were connected.
- When access was removed, and who confirmed it.
- Any request from the tool for broader permissions, and what you decided.
That log doubles as evidence if an auditor or customer later asks how you handled a trial. See also least privilege for a scanner pilot.
What to do if the tool asks for more access
Say no and ask why. Often there is a narrower option, such as a single repository permission instead of an organization one. If the feature truly needs write access, test it later, after the core questions are answered.
At the end
On the exit date, remove the integration, revoke tokens, delete trial branches, and ask the vendor in writing to confirm deletion of your data. Then check, rather than assume, that access is gone.
Try it yourself
Open the demo to see a check that reports on a pull request without changing code, which is the read only behavior you want during a trial.
Click through it at your own pace, or open it full screen.
Quick check
Is read only access enough to be safe?
It removes the write risk, but the tool can still read code and metadata. Scope it to chosen repos and limit the time.
Who should hold the trial token?
A dedicated service account owned by the PoC owner, with an expiry date, not a personal token.
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
