On day one, confirm ten things: an owner, a lockfile, strict installs in CI, update automation, a pull request scan, a merge gate, an approved registry, a pinned base image, an SBOM and a place for exceptions. If a template created the service, most should already be true.
Why a checklist when a template exists
Templates drift, and teams skip them. A short checklist gives each new service a ten minute check that nothing was lost or customized away. It also works for services created without a template, which is how you find out they need one.
The ten items
| # | Item | How to verify |
|---|---|---|
| 1 | Named owner in the catalog | Owner field is a team, not a person who left |
| 2 | Lockfile committed | File exists and matches the manifest |
| 3 | Strict install in CI | CI uses the strict command, such as npm ci for Node, which per npm's docs errors when lock and manifest disagree |
| 4 | Update automation on | Config file present and a test pull request opens |
| 5 | Dependency scan on pull requests | Open a test pull request and see the result |
| 6 | Merge gate required | Branch rules require the scan check to pass |
| 7 | Approved registry only | Clean install works without personal configuration |
| 8 | Base image pinned and current | Tag plus digest, and a scan result for the image |
| 9 | SBOM generated per build | Artifact is attached to the build |
| 10 | Exception path known | README links to how to request one |
A ten minute walkthrough
- Open the repository and read the first commit. Is the lockfile there?
- Open the CI configuration and find the install step.
- Open a throwaway pull request that adds a known old dependency version. Does the scan flag it and does the gate block it?
- Check the branch rules for a required check.
- Try a fresh clone in a clean container. Does the install succeed?
- Find the SBOM artifact on the latest build.
Step 3 is the one that proves the control works. A check that cannot fail is not a control.
What to do with gaps
Record each gap as a ticket with an owner and a date. Do not mark the service ready for production with open items 2, 5 or 6. Those three catch the most common failures.
For services that are deliberately off the path, write the reason in the repository and add an expiry. The same discipline applies to templates; see secure defaults for internal developer platforms.
Make it automatic
A checklist you run by hand is a starting point. Turn it into a scheduled check against every repository in your catalog, and report the services that fail. That turns a day one habit into a standing guardrail. See how to measure paved road adoption for reporting ideas.
Where Safeguard fits
Safeguard covers several of these items directly: SBOM and dependency scanning, policies and gates for pull requests, asset discovery for services without an owner, and continuous monitoring after release. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the inventory and imagine it as the output of checklist item 9, then look for anything you would not expect in a brand new service.
Click through it at your own pace, or open it full screen.
Quick check
Which three items matter most?
Lockfile, a scan on pull requests and a required merge gate. Together they catch the most common failures.
Does a service need an SBOM on day one?
Generating one per build from the start is cheap and gives you an inventory when the first advisory arrives.
Sources
Last reviewed: 19 October 2026.
