Do both. Fix individual CVEs in third party code one at a time, since that is how patches arrive. For flaws in your own code, fix by weakness class: find the repeated pattern, fix it once at the root, and add a guard so the class does not come back.
Two different kinds of finding
A CVE identifies one specific vulnerability in one product, usually a dependency you do not control. A CWE identifies a type of weakness, such as injection or out of bounds writes. (For the difference, see CVE vs CWE explained.)
Dependency findings come with fixed versions, so the natural unit of work is the CVE or the package upgrade. Findings in your own code, from code analysis or testing, often repeat the same weakness many times.
When class based fixing pays off
If a code scan reports forty SQL injection findings, forty separate patches treat the symptom. The cause is probably a handful of patterns: string built queries, a helper that skips parameters, an old data access layer.
Fix the pattern:
- Group findings by weakness type and by code location.
- Find the shared cause, such as one helper function or one framework misuse.
- Fix the helper or replace the pattern.
- Add a rule or test that fails when the pattern returns.
- Close the grouped findings together once the root fix is confirmed.
This turns forty tickets into three pieces of work and reduces repeat findings.
A comparison
| By CVE | By weakness class | |
|---|---|---|
| Suited to | Third party dependencies | Your own code, repeated patterns |
| Unit of work | Package upgrade | Shared helper, pattern, or guard |
| Strength | Direct match to advisories and fixed versions | Prevents future occurrences |
| Weakness | Never ends, new CVEs keep arriving | Needs engineers who understand the pattern |
| Typical owner | Platform or service team | Application team with security review |
Mix them in prioritization
Rank by risk first, then use classes to batch the work. A reachable, exposed flaw goes to the front whichever way you group it. Within the same tier, batching related fixes saves review time and reduces regressions.
Dependencies can also be batched. One framework upgrade may close many CVEs at once, and that is a class of its own: stale framework version.
Make the fix stick
A class fix is only finished when something prevents recurrence. Options include a linter rule, a pull request check, a safe by default library function, or a code review checklist item. Without this, new code reintroduces the pattern.
Try it yourself
Open the demo and look at how code scan findings can be grouped. Look for clusters that share a single cause.
Click through it at your own pace, or open it full screen.
Quick check
Is a weakness class fix riskier than a single patch?
It touches more code, so test it well. The payoff is fewer repeat findings.
Do dependency CVEs ever get class based treatment?
Yes, for example one framework upgrade that closes many advisories at once.
Safeguard's code and dependency scanning can surface both kinds of finding in one place, and the free scan at gold.safeguard.sh/scan is a way to try it.
Last reviewed: 19 October 2026.
