For a new app, switch on dependency scanning and static checks at the first commit, so nothing ever builds up. For a legacy app, start with an inventory and dependency scanning, set a baseline for old findings, and enforce rules only on new code. Same methods, different order.
Why the two cases differ
A new codebase has no history. Every check starts clean, so you can fail builds on any serious finding without argument. A legacy codebase starts with years of accumulated issues. Turning on strict rules immediately produces thousands of findings, blocks every merge and teaches developers to ignore the tool.
Sequence for a new app
- Commit lockfiles and enable dependency scanning before the first release.
- Add static analysis on pull requests with a short, strict rule set.
- Write tests for access rules as each feature lands.
- Add a dynamic scan of staging once there are pages and an API to probe.
- Fuzz parsers when they appear.
- Record the baseline decisions in the repository, so later teams know why.
OWASP notes that static analysis feedback inside the development cycle can save time compared with finding problems later. A new app is where that advantage is largest.
Sequence for a legacy app
- Inventory first. List repositories, runtimes and packages. You cannot test what you cannot find.
- Run dependency scanning and sort known flaws by whether the code reaches them.
- Take a baseline. Record existing findings as accepted debt with an owner and a review date.
- Enforce on new code only. Fail builds only for findings introduced by the change in front of you.
- Burn down by risk, not by count. Fix issues on internet-facing and data-handling paths first.
- Add dynamic testing against a staging copy to learn how the old app behaves from outside.
Comparison
| Step | New app | Legacy app |
|---|---|---|
| First action | Enable scans on day one | Build an inventory |
| Static findings | Block on serious ones | Baseline, then block only new |
| Old dependency flaws | None yet | Rank by reachability, fix in batches |
| Risk of tool fatigue | Low | High unless baselined |
Pitfalls
- Declaring a baseline and never reviewing it. Give each item an expiry.
- Fixing the easiest findings instead of the riskiest.
- Skipping the inventory because the team "knows what is there". Forgotten services are where old flaws hide.
Where Safeguard fits
Safeguard's asset discovery and SBOM support the inventory step, reachability analysis helps rank old dependency flaws, and gates can enforce rules on new changes. Static analysis findings come from your other tools. A free scan is at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate judges the change in front of it rather than the whole history.
Quick check
What is a baseline?
A recorded snapshot of existing findings, accepted for now, so that only new findings fail a build.
Should legacy apps skip static analysis?
No, but run it with a baseline and tuned rules so developers see only new, relevant results.
Sources
Last reviewed: 19 October 2026.
