Split your new findings into two groups: introduced, meaning a recent code or dependency change created them, and inherited, meaning they were already there or became known later through a new disclosure. The split tells executives whether the problem is the process that ships code or the age of what is already running.
Why the split matters
A single "new findings" number blends two different causes with two different fixes.
- Introduced findings point to the development process. The cure is earlier checks, such as a pull request gate or a review rule.
- Inherited findings point to maintenance. The cure is updating, retiring, or replacing older components, and it needs planning rather than a gate.
If you treat both as one problem, you tend to fix the wrong thing. Tightening a gate does nothing for a library that was clean last year and gained a CVE this month.
How to classify each finding
- Record the first seen date for every finding in the scanner or tracker.
- Record the date the vulnerable component first appeared in the codebase, from version control history or an SBOM comparison.
- Record the date the vulnerability was published.
- Classify using those three dates.
| Component added | Vulnerability published | Class |
|---|---|---|
| After publication | Already public | Introduced (the team chose a vulnerable version) |
| Before publication | Published later | Inherited (new knowledge about old code) |
| Before publication | Already public when first scanned | Inherited (scanning gap) |
The first row is the cleanest signal of a process problem. If a team adds a dependency version that was already known to be vulnerable, a check at that moment would have caught it.
What the trend tells you
- A rising introduced share means checks at change time are missing or ignored.
- A rising inherited share means the estate is aging, or disclosure volume is up, or coverage improved.
- A high share of inherited findings in a few services points to ownership gaps there.
Be careful with the last one. Newly scanned systems appear to have a large inherited share on day one. Mark the date a system joined scanning so it does not look like a regression.
How to report it
Keep it to one stacked bar by month, two colors, and one sentence. For example: "Most new findings this quarter were inherited, so we are scheduling upgrades for the three oldest services." Then name the owners and dates in the follow up.
Limits to state honestly
Dates may be missing, especially for old components. Say what percent of findings you could classify, and leave the rest as unclassified instead of guessing. Do not present the split as exact if it relies on partial history.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is an inherited finding the team's fault?
Not necessarily. New disclosures make old code vulnerable overnight. The question is how quickly the organization finds out and acts, which is a separate metric.
Can we skip this if we have few findings?
With small numbers the split is noisy. Review it by hand each quarter instead of charting it.
Last reviewed: 19 October 2026.
