Scan anything that ships, runs or feeds a build. Treat forks, archived repos, sandboxes and vendored code case by case, and record every exclusion with a reason and a review date. An unexplained gap in scope is a bigger risk than a noisy repository.
Why scope needs a rule
In a big organization, the repository list includes experiments, forks of upstream projects, archived services and personal sandboxes. If the SCA tool scans everything, the noise buries real work. If teams exclude things informally, you lose the denominator that makes coverage meaningful. A written scope rule solves both.
A decision table
| Repository type | Default | Reason to deviate |
|---|---|---|
| Production service | In scope | Never excluded |
| Shared internal library | In scope | Its consumers inherit its risk |
| Build and deploy tooling, CI config | In scope | Feeds the build |
| Active fork carrying your patches | In scope | You ship it |
| Fork kept only for reference | Exclude, review yearly | Upstream owns the code |
| Archived repo | Record, usually exclude | Include if anything still depends on it |
| Sandbox and spike repos | Exclude under an agreed owner and age rule | Include if credentials or data exist |
| Vendored third party code inside a repo | In scope as components | Treat as dependencies, not first party |
Archived repos need one more question
Archived does not mean unused. Ask whether a pipeline, an image or another repo still pulls from it. If yes, its dependencies still reach production. See do archived research repositories need vulnerability rescans and archived GitHub repo dependency, what to do.
Forks
A fork you maintain is your code. A fork you never touch is upstream's code at a past point in time. Two practical rules: scan forks that have commits of your own, and for pure mirrors, scan the consuming project instead, since that is where the package is used.
Sandboxes
Short lived experiments are rarely worth scanning, but they can hold real secrets or connect to real systems. Set an age limit, such as archive or delete after 90 days of inactivity, and require an owner field at creation. Sandboxes that outlive the limit move into scope or get removed.
Record the exclusions
Keep an exclusion register with these columns:
- Repository
- Owner
- Reason
- Approver
- Review date
Review the register quarterly. Anything past its review date returns to scope until someone renews it. The register itself is useful audit evidence that scope was a decision, not an accident.
Measure coverage honestly
Report coverage as repos scanned out of repos in scope, and separately repos excluded out of repos known. Showing both prevents "100 percent" claims that depend on a shrinking denominator.
Automate the edges
- Detect new repositories daily and place them in a default state, either in scope or in review.
- Flag repositories with recent commits that are marked excluded.
- Flag in scope repos with no scan in 30 days.
Related reading: onboarding hundreds of repositories in waves.
Safeguard's asset discovery helps find repositories and services that were never on a list, and the free scan at gold.safeguard.sh/scan shows what a first inventory contains.
Quick check
Should we scan every fork?
Scan forks that carry your own changes or ship in your product. Pure reference mirrors can be excluded with a recorded reason.
Is an archived repo always safe to ignore?
No. If a build or deploy still depends on it, its dependencies still matter.
Last reviewed: 19 October 2026.
