A vulnerability count should be tagged by environment and reported by group, usually production first, then pre-production, then development and build tooling. One blended number hides how much exposure actually faces users or holds live data, and it moves for reasons unrelated to risk.
The blending problem
Development dependencies, test images and ephemeral preview environments often outnumber production assets. Their findings can dominate a total. A team that cleans a test fixture directory sees a big drop that does not change production exposure at all. The reverse also happens: a real production issue gets lost among hundreds of build tool findings.
Tag at the source
Add an environment attribute to each asset, set when it is created, not guessed later. Reasonable values: production, staging, development, build and tooling, and unknown. Treat unknown as a defect to be fixed, in the same way as an unowned asset.
Ways to assign the tag:
- From infrastructure definitions that name the deployment target.
- From cloud account or project naming conventions, if those are enforced.
- From labels on container images and orchestrator namespaces.
- From manifest metadata, such as marking a dependency as a dev dependency.
What to report
| Group | Why show it |
|---|---|
| Production | Direct exposure to users and live data |
| Pre-production | Early warning and release readiness |
| Development | Developer workstation and test exposure |
| Build and tooling | Supply chain risk through the pipeline |
| Unknown | Data quality gap |
Do not rank these as important and unimportant. Build and tooling findings matter because a compromised build can reach production. The point is to keep the groups apart so the reader can see where the exposure is.
Dependencies that cross groups
A package marked as a dev dependency in one place may ship in a production image through a build step. If your data comes only from manifests, you will miss that. Where you can, scan the final artefacts, such as the built container image, in addition to source manifests, so the production number reflects what really ships.
Audit your own number
Take the production group and sample ten assets. Confirm each is really in production and that nothing in production is missing. Then take the unknown bucket and check how large it is. A large unknown group means environment totals cannot be trusted yet.
Keep trends comparable
When you introduce environment tagging, restate prior periods if you can, or add a note on the chart marking the change. Otherwise the first month looks like a sudden fall.
Safeguard does this kind of counting in one place: SBOM and dependency scanning, asset discovery and reachability analysis feed the same inventory, so each number can be traced back to its source. Container image scanning and asset discovery cover what actually runs, which helps check the production group. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should development findings be ignored?
No. Report them separately and prioritise by exposure. Build tooling in particular can affect production.
What if an asset has no environment tag?
Count it as unknown and treat the gap as something to fix, with an owner and a date.
Last reviewed: 19 October 2026.
