Use both, in two stages. Start on public or non sensitive repositories while the security review runs, then move to a few private repos once data terms are agreed. Stage one proves the basics quickly. Stage two tests what you actually care about: your languages, your build and your noise.
Why not just one
Public repos need little approval, so you can begin on day one. But they are not representative. Real private code has internal packages, odd build setups, older dependencies and monorepo layouts that expose gaps. Going straight to your crown jewel repos, on the other hand, needs approvals that may take weeks.
The two stage plan
| Stage | Repos | Goal | Approvals needed |
|---|---|---|---|
| 1 | Public or sample repos you own | Install, integrate, check basics | Light, no confidential data |
| 2 | Three to five private repos across tiers | Measure noise, fit, speed | Data terms, access scoping, owner consent |
Stage one steps
- Pick two or three public projects in your main languages, or a sample app.
- Install the CLI, CI step or IDE extension as developers would.
- Check what the tool reports and how long a scan takes.
- Look at the console, roles and audit logs while you are there.
- Note anything that blocks stage two, such as missing SSO or a data question.
A free scan is a quick starting point at gold.safeguard.sh/scan.
Stage two steps
- Choose repos by tier: one low risk, one medium, one with a complex build. Avoid starting with the most sensitive.
- Grant access only to those repos. See least privilege access for a scanner pilot.
- Put the pilot terms in writing. See pilot agreement: what to put in writing.
- Measure the same things you measured in stage one, plus actionable finding rate and developer feedback.
- Delete pilot data at the end and get confirmation.
What to avoid
- Vendor chosen repos only. A fair test uses code the vendor has not seen.
- Skipping private repos entirely. You will meet the problems after purchase.
- Unscoped org wide install just to save time.
- Using real secrets in test files. Use harmless marker strings.
Keep test material consistent
If you compare several tools, run them on the same repos and the same commits. See appsec poc test corpus: how to choose.
Try it yourself
The dependency inventory demo shows the kind of component list a trial on any repo will produce. Look at how entries are grouped and flagged.
Click through it at your own pace, or open it full screen.
Quick check
Is a public repo trial enough to buy?
Rarely. It confirms basics, but private code shows real noise, build fit and speed.
Which private repo should go first?
A medium risk service with a typical build. Avoid starting with your most sensitive repo.
Last reviewed: 19 October 2026.
