Sort your applications into three tiers by what a breach would cost, then assign each tier a fixed testing baseline. Low-risk apps get automated dependency checks. Medium-risk apps add static or dynamic scanning. High-risk apps add manual review and independent testing. The tier, not the app's age, sets the depth.
Why tiering beats one policy for everything
A single policy fails in both directions. Apply the heaviest testing to every app and teams drown in findings and stop reading them. Apply the lightest to every app and the payment service gets the same scrutiny as the lunch menu page.
NIST's Secure Software Development Framework describes practices to reduce the number of vulnerabilities in released software and to limit the impact of those that go unnoticed. Choosing where to spend effort is part of making those practices workable.
Step 1: score each app on four questions
Give one point for each yes.
- Does it handle personal, financial or health data?
- Is it reachable from the internet?
- Would an hour of downtime stop revenue or a customer's operations?
- Does it hold credentials or tokens that unlock other systems?
Score 0 to 1 is Tier 3, 2 is Tier 2, and 3 to 4 is Tier 1. Adjust by hand for contract or regulatory duties, but write down why.
Step 2: assign a baseline per tier
| Tier | Example | Baseline |
|---|---|---|
| Tier 3, low | Internal wiki plugin, marketing microsite | Dependency scanning, lockfiles committed |
| Tier 2, medium | Customer-facing app without payments | Tier 3 plus static analysis on pull requests and a dynamic scan against staging |
| Tier 1, high | Payments, identity, health records | Tier 2 plus manual code review of sensitive paths, authenticated dynamic scans, periodic independent penetration test, fuzzing for parsers |
The point of a table is that nobody renegotiates it per ticket. A new service inherits its tier's baseline on day one.
Step 3: decide what blocks a release
Keep blocking rules proportionate. A Tier 3 app might block only on critical issues with a fix available. A Tier 1 app might block on any high issue in code on a sensitive path. Write the rule next to the tier.
Step 4: review the tiers on a schedule
Apps drift. A prototype gains real customers, an internal tool gets a public endpoint. Re-score every app twice a year and whenever its data or exposure changes. Keep the list in the same place as your inventory so it does not go stale.
Common mistakes
- Tiering by team politics instead of impact.
- Leaving untiered apps. Unscored means unknown, so treat it as Tier 2 until scored.
- Setting a Tier 1 baseline with no one assigned to triage the results.
Where Safeguard fits
Safeguard's asset discovery helps you find what apps and repositories exist, and its policies and gates let you set a different blocking rule per tier. It covers the dependency side of each baseline: SBOM and dependency scanning with reachability analysis. Static, dynamic and manual testing in the higher tiers come from other tools and people. A free scan is at https://gold.safeguard.sh/scan.
Quick check
How many tiers do we need?
Three is enough for most teams. More tiers add debate without changing what anyone does.
Who decides an app's tier?
The app owner proposes, security reviews. Record the reasoning so a later reviewer can challenge it.
Sources
Last reviewed: 19 October 2026.
