Rank staging and development findings below production by default, but not at zero. Many non production environments hold real credentials, copies of data or a route into production. Decide by what each environment actually contains and connects to, not by its name.
Why environment is an asset fact
Environment is one of the simplest and most useful labels on an asset. It answers a plain question: if this is compromised, does production suffer? The CVSS v4.0 Environmental group exists because the same flaw matters differently depending on where it runs, including the relative importance of the vulnerable system.
But the label has to be true. Teams often set staging up quickly and loosen rules to move fast. Over time it acquires data and access that nobody planned.
A quick audit of a non production environment
Ask five questions.
- Does it hold a copy of real customer or business data?
- Does it hold credentials or tokens that also work in production?
- Is it reachable from the internet?
- Does it share a network, account or identity provider with production?
- Does it build or sign what ships to production?
The answer to each can lift the environment's priority.
What each answer means
| Answer | Consequence |
|---|---|
| Real data copy | Treat as the data label of the real data |
| Shared credentials | Treat as production for secrets exposure |
| Internet reachable | Apply the same exposure logic as production |
| Shared network or identity | Count it as a path into production |
| Builds release artifacts | Treat as high criticality, because it affects what ships |
A build environment is a special case. A flaw in the system that compiles and signs your software can reach every customer, whatever it is called.
A default tiering
Use a starting rule, then adjust:
- Production: by the normal tiering.
- Staging with real data or shared access: same as production.
- Staging with synthetic data and no shared access: one tier lower.
- Development laptops and sandboxes: one tier lower, still fix flaws on a known exploited list.
- Build and release systems: at least the tier of the most critical thing they build.
Fix the cause, not only the finding
If staging holds real data, a better fix than patching is to stop copying real data. Use synthetic data or masked data. Separate credentials so a staging token does nothing in production. Those changes remove whole classes of findings.
Where prioritization often goes wrong
- Teams mute everything outside production, then discover an exploited flaw in staging that shared a database password with production.
- Tags say development, but the service has a public address.
- A retired environment is still running because nobody shut it down.
CISA's Known Exploited Vulnerabilities Catalog lists flaws with evidence of exploitation. A listed flaw on any reachable system deserves attention, whatever the environment label says.
Review cadence
Re-check the five questions when a new integration is added, when a data refresh process changes, and at least once a quarter for staging.
Quick check
Should staging use production data?
Avoid it where you can. Use synthetic or masked data, and treat any real copy at the production level.
Do development laptops count?
They count if they hold credentials that reach production. Check what they can access.
Sources
Last reviewed: 19 October 2026.
