-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix when getting Vaadin analysis to also check the affected dependency group, name and version #157
base: main
Are you sure you want to change the base?
Conversation
…y group, name and version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we have an analysis of CVE-2023-6378 for logback-classic
, but the application is affected by the same vulnerability and only depends on logback-core
? Would the analysis be shown after this change?
No, because I realized that the current vulnerability analysis’ structure is using Map<String, CLASS> almost everywhere, so I think the current vulnerability analysis structure is not suitable to handle cases like this. The structure should be improved like this:
and provide analysis for both cases. |
We can change the analysis structure if we keep it compatible with older kit versions, e.g. by introducing a new property instead of changing the existing one. If we do this, do we still need this PR? |
AppSec Kit handles and shows the found vulnerabilities per dependency. It can happen that two dependencies are affected by the same vulnerability:
In cases like this if the security team wants to provide separate analysis for the two vulnerabilities then the current logic to get the analysis is not correct. Currently, we get an analysis based only on the vulnerability id and after we check if the affected dependency's parent's group, name and version match the ones provided in the analysis assessment.
We need to extend the logic with checking the group, name and version when we get the analysis to be able to choose the right analysis for the given vulnerability and dependency combination.
Dependencies and their parent:
Same in the generated SBOM: