After upgrading from DependencyTrack v11.1.0 to v12.1.0, we noticed a sharp increase in CPE matches, leading to a flood of tickets for failures and suppression requests.
Upon further investigation, it appears that very loose CPE matches are causing this spike. For example, we’re seeing matches for any package with "Redis" in the name, even when they are unrelated.
Example Packages matched:
pkg:nuget/Microsoft.AspNetCore.DataProtection.Redis@0.3.3
pkg:nuget/Hangfire.Redis.StackExchange@1.9.4
pkg:nuget/EasyCaching.Redis@1.9.2
pkg:nuget/EFCoreSecondLevelCacheInterceptor.StackExchange.Redis@5.0.0
pkg:nuget/StackExchange.Redis@2.8.24
The CPE match shown in the HTML report typically looks like this:
cpe:2.3:a:redis:redis:5.0.0:::::::* (Confidence: Low)
We have reviewed the changelog, but we haven’t found any changes that directly explain this behavior.
Could you provide any insight into what might have changed in v12.1.0 regarding CPE matching? Is there a way to adjust the matching logic or fine-tune the confidence threshold to avoid these false positives?
Thanks in advance for your help!
After upgrading from DependencyTrack v11.1.0 to v12.1.0, we noticed a sharp increase in CPE matches, leading to a flood of tickets for failures and suppression requests.
Upon further investigation, it appears that very loose CPE matches are causing this spike. For example, we’re seeing matches for any package with "Redis" in the name, even when they are unrelated.
Example Packages matched:
The CPE match shown in the HTML report typically looks like this:
We have reviewed the changelog, but we haven’t found any changes that directly explain this behavior.
Could you provide any insight into what might have changed in v12.1.0 regarding CPE matching? Is there a way to adjust the matching logic or fine-tune the confidence threshold to avoid these false positives?
Thanks in advance for your help!