Before a new system takes production traffic, confirm it has an inventory of its components, a clean scan with no unreviewed high-risk findings, owners for what remains, approved exceptions with expiry, and a recorded baseline you can compare against later. Treat go-live as a change that needs security sign-off like any other.
Why a baseline helps
A baseline is the recorded state at the point you accepted the system: what is in it, what was found, and what was decided. Without it, later findings have nothing to be compared against, and auditors cannot tell what you knew at launch.
NIST SP 800-53 baseline configuration asks for a current baseline, maintained under configuration control and updated when components are installed or upgraded. Its impact analysis control asks that changes be analyzed for security and privacy impacts before implementation. A new system is the largest change of all.
The checklist
| Check | Evidence |
|---|---|
| Component inventory exists | SBOM for each application, image digest list |
| Dependencies scanned | Dated scan report |
| Images scanned | Report per image, base image noted |
| Code and config reviewed | Static analysis results, configuration review notes |
| Exposure mapped | List of public endpoints and ports |
| High and critical findings resolved or approved | Tickets, exceptions with expiry |
| Owners assigned | Named owner per component and per finding |
| Monitoring on | Scheduled rescans and advisory watching enabled |
| Rollback tested | Record of a rollback rehearsal |
| Sign-off | Approver name, role and date |
Sign-off rules
Decide before the project starts what blocks go-live. A simple rule: no unresolved critical findings in internet-facing components unless an approver outside the project accepts them in writing with an expiry. Pre-agreed rules prevent last-minute bargaining.
Record the baseline
Save, with a date, the inventory, scan results and decisions. Store them with the change record. Later you can answer questions like "was this library present at launch" and "did we know about this flaw".
After go-live
Go-live is the start, not the end. Turn on continuous monitoring, because a clean scan on launch day says nothing about a flaw published next week. Set the first review at a short interval, then settle into your normal cadence. Compare new findings against the baseline to see what changed.
Containers and images
For container-based systems, the base image is part of what you ship. Record the image digest, scan it, and note how base image updates will be handled. Rebuild rather than patch in place where your platform allows.
Where tooling helps
Safeguard scans container images, dependencies and code, generates SBOMs and applies gates that can hold a release when findings break policy, which fits a go-live check.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how an image is broken into layers and findings, the inventory you would save as part of the baseline.
Quick check
Do all findings need fixing before launch?
No. High and critical ones in exposed components should be fixed or formally accepted. Lower ones can follow normal deadlines.
Who signs off go-live?
Someone accountable for the system and independent of the build team for higher risk systems, with security consulted.
Sources
Last reviewed: 19 October 2026.
