No, report them separately and then roll them up with a label. Dependency findings come from components you did not write and are usually fixed by upgrading. First-party code findings come from your own logic and are fixed by changing it. Different owners and timelines make a blended metric hard to act on.
What differs
| Aspect | Dependency findings | First-party code findings |
|---|---|---|
| Source | Third-party packages and their transitive dependencies | Code your team wrote |
| Typical fix | Upgrade or replace a component | Change application logic |
| Disclosure | Public CVE entries | Found by your own analysis |
| Timeline driver | Release of a fixed version | Engineering effort |
| Noise | High, many are not reachable | Varies, often needs triage |
Because the inputs differ, the metrics should too. Time to remediate for dependencies often depends on how fast maintainers publish fixes. For first-party findings it depends on your own backlog.
Metrics for each
For dependencies, track open findings by age, the share with a fix available, reachable findings, and the age of the dependency itself. Dependency update lag is a useful companion.
For first-party code, track findings by weakness type, time to triage, time to fix, and false positive rate. Weakness type matters because repeated patterns point to training or framework changes.
Why a blended number misleads
Suppose dependency findings dominate by count. A blended trend then mostly tracks library updates, and an improvement in code review is invisible. The reverse also happens: a few hard code findings can hide behind a large pile of easy dependency closures.
Separate lines let you see which process is moving.
Steps to set it up
- Tag every finding with its source: dependency or first-party.
- Report open count, age, and remediation time for each source.
- Choose a rollup, such as total open known exploited items, that spans both and is clearly labeled.
- Assign ownership. Platform or service teams usually own dependency upgrades, while feature teams own their code.
- Review the split each quarter.
Gaps to watch
Some issues sit between categories, such as insecure use of a library. Pick a rule: if the fix is a change in your code, it is first-party even when the library is involved. Write the rule down so classification does not drift.
Also watch for code that is vendored, meaning copied into your repository. Treat it as a dependency in reporting, since the fix is an update of the copied code, even though scanners may see it as source.
Executive summary
Two small tables and one sentence: "Dependency findings are driven by upgrade work, and first-party findings by code fixes, and here is what we are doing on each." That tells leaders where effort goes.
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.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the code scan and compare its findings with those in the dependency inventory demo, noting how the fix differs.
Quick check
Where do container base image findings go?
Treat them as dependencies, since the fix is usually to rebuild on an updated base image.
Can one executive number cover both?
Yes, if it is labeled, such as open known exploited items across both sources. Avoid unlabeled blended totals.
Last reviewed: 19 October 2026.
