Before you extract anything, scan the whole monolith for dependencies, known vulnerabilities and reachable code paths, and save the results as a dated baseline. That baseline lets you show later that each extracted service reduced exposure instead of just moving it somewhere else.
Why a baseline first
Fowler describes modernization as deciding how to break a system into smaller parts, then delivering the parts. Without a starting measurement, you cannot tell whether a split helped. A monolith may pull in hundreds of libraries. After a split, each service takes a subset, and some libraries get copied into several services. Without the baseline, the count of findings can go up and look like failure when the real cause is duplication.
The method
- List every build target. Large legacy repos often hold several deployable artifacts, plus old modules that still compile but ship nowhere. Write down which ones are deployed.
- Generate a dependency inventory per artifact. Use lockfiles or the resolved dependency tree, not just the manifest. Transitive libraries are where most findings come from.
- Match components to known vulnerabilities. Record the advisory identifier, severity and whether a fixed version exists.
- Mark exploitation signals. CISA's Known Exploited Vulnerabilities catalog is described by CISA as an input to prioritization, so flag any component with an entry there.
- Run reachability analysis. Note which vulnerable functions the monolith actually calls. This separates urgent findings from background noise.
- Record the owner for each module. See security findings in legacy code nobody owns for how to fill gaps.
- Save the output with a date and commit hash.
What the baseline should contain
| Field | Example use later |
|---|---|
| Component and version | Spot duplicates across new services |
| Advisory IDs | Confirm a fix actually removed a finding |
| Reachable yes or no | Choose extraction order |
| Internet facing yes or no | Set patch urgency |
| Owning team | Route findings |
Pitfalls
Scanning only the container image can miss libraries that are compiled into a fat archive. Scanning only source can miss libraries added at build time. When possible do both, and reconcile the two lists.
Another pitfall is treating dead modules as safe. If a module is in the repository and in the build, scanners will report it. Decide whether to exclude it, delete it, or fix it, and write that decision down. Deleting dead code is often the cheapest remediation.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list shrinks once unreachable findings are separated out. That is the order of work you want before choosing the first slice.
Safeguard offers dependency scanning, SBOM generation and reachability analysis for this baseline step. The free scan at gold.safeguard.sh/scan is a quick way to see a first inventory.
Quick check
How often should the baseline be refreshed?
Take it once before work starts, then rescan on every merge and compare against it at each milestone.
Is a manifest enough to scan?
Not usually. The resolved tree shows transitive libraries that manifests omit.
Sources
Last reviewed: 19 October 2026.
