To onboard a new service to security scanning, register an owner, connect the repository, take a first inventory of dependencies and secrets, set a baseline for existing findings, turn on pull request checks for new ones, and record where results go. Done well, it takes an afternoon and needs no security engineer.
Why make it a checklist
New services appear all the time. If onboarding depends on someone remembering, some will never be scanned. A checklist turns it into a step in the service creation template, and makes gaps easy to spot.
The checklist
Ownership
- A named owning team and a backup contact
- A champion or reviewer for security questions
- A CODEOWNERS file so the right people review changes
Inventory
- Repository connected to the scanning system
- Languages and package managers detected
- A software bill of materials generated for the main branch
- Container images and infrastructure files listed, if any
First scan
- Secret scan on the full history, not only the latest commit
- Dependency scan on the lockfile
- Static analysis on first party code, if the team uses it
- Results reviewed with the owner, real versus noise
Baseline
- Existing findings marked as baseline, so the gate only blocks new ones
- Top three baseline items given owners and dates
- Anything unfixable recorded as a time limited exception
Pull request checks
- Scan runs on every pull request
- Blocks only the agreed set: new secrets, new reachable critical findings
- Results appear as one summary comment, not dozens
Operations
- Scheduled rescan so new advisories reach old code
- Alerts go to the owning team's channel
- Service listed in the asset register with its environment and data class
Time estimates
A small service with one language usually takes under an hour once the template exists. The longer steps are reviewing the first findings and agreeing on the baseline, because those need a conversation.
Common mistakes
| Mistake | Fix |
|---|---|
| Scanning only the default branch | Scan pull requests so new code is checked before merge |
| No rescan schedule | New advisories land on old code, so schedule weekly or on advisory feed updates |
| Skipping secret history | Old commits can still leak working credentials |
| No owner on alerts | Alerts to a shared inbox age quietly |
Automate what you can
Put the scan configuration in a template repository or a reusable pipeline definition so every new service inherits it. Add a check that fails if a repository is created without the file. The goal is that onboarding is the default, not an extra step.
Try it yourself
Open the demo to see how a project's components are inventoried, which is the first deliverable on the checklist.
Click through it at your own pace, or open it full screen.
Quick check
Do we need to fix every baseline finding before enabling pull request checks?
No. Baseline the existing findings and gate only on new ones, then reduce the baseline over time with owners and dates.
How often should a stable service be rescanned?
At least weekly, since new advisories appear for code that has not changed.
Safeguard covers SBOM and dependency scanning and asset discovery, and its free scan at gold.safeguard.sh/scan is a quick first inventory.
Last reviewed: 19 October 2026.
