-
Notifications
You must be signed in to change notification settings - Fork 190
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
cli: version 2.6 generating different vulnerability hashes from 2.5 #680
Labels
kind/bug
Something isn't working
Comments
matheusalcantarazup
added a commit
to ZupIT/horusec-devkit
that referenced
this issue
Oct 15, 2021
A new field VulnHashInvalid was added on vulnerability struct to allow cli match the valid and invalid hashes of vulnerability. For more info see ZupIT/horusec#680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup
added a commit
that referenced
this issue
Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the Details of vulnerability is used to generate the vulnerability hash, so adding the rule id on details generate a different hash which cause a breaking change. So this commit remove the rule id prefix from Details field of Vulnerability and also add a workaround to users that is already using the new hash as a false positive and risk accept. To support the two ways of hashing the vulnerability a new field was added on Vulnerability struct that represents the breaking way, so we generate the two hashes of vulnerability and when we set the vulnerability to false positive/risk accept according to config file we use the two hashes to match. Fixes #680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup
added a commit
to ZupIT/horusec-devkit
that referenced
this issue
Oct 15, 2021
A new field VulnHashInvalid was added on vulnerability struct to allow cli match the valid and invalid hashes of vulnerability. For more info see ZupIT/horusec#680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
wiliansilvazup
pushed a commit
to ZupIT/horusec-devkit
that referenced
this issue
Oct 15, 2021
…113) A new field VulnHashInvalid was added on vulnerability struct to allow cli match the valid and invalid hashes of vulnerability. For more info see ZupIT/horusec#680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup
added a commit
that referenced
this issue
Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the Details of vulnerability is used to generate the vulnerability hash, so adding the rule id on details generate a different hash which cause a breaking change. So this commit remove the rule id prefix from Details field of Vulnerability and also add a workaround to users that is already using the new hash as a false positive and risk accept. To support the two ways of hashing the vulnerability a new field was added on Vulnerability struct that represents the breaking way, so we generate the two hashes of vulnerability and when we set the vulnerability to false positive/risk accept according to config file we use the two hashes to match. Fixes #680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup
added a commit
that referenced
this issue
Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the Details of vulnerability is used to generate the vulnerability hash, so adding the rule id on details generate a different hash which cause a breaking change. So this commit remove the rule id prefix from Details field of Vulnerability and also add a workaround to users that is already using the new hash as a false positive and risk accept. To support the two ways of hashing the vulnerability a new field was added on Vulnerability struct that represents the breaking way, so we generate the two hashes of vulnerability and when we set the vulnerability to false positive/risk accept according to config file we use the two hashes to match. Fixes #680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup
added a commit
that referenced
this issue
Oct 15, 2021
On pr #636 we add the rule id on description of vulnerability, but the Details of vulnerability is used to generate the vulnerability hash, so adding the rule id on details generate a different hash which cause a breaking change. So this commit remove the rule id prefix from Details field of Vulnerability and also add a workaround to users that is already using the new hash as a false positive and risk accept. To support the two ways of hashing the vulnerability a new field was added on Vulnerability struct that represents the breaking way, so we generate the two hashes of vulnerability and when we set the vulnerability to false positive/risk accept according to config file we use the two hashes to match. Fixes #680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
matheusalcantarazup
added a commit
that referenced
this issue
Oct 18, 2021
On pr #636 we add the rule id on description of vulnerability, but the Details of vulnerability is used to generate the vulnerability hash, so adding the rule id on details generate a different hash which cause a breaking change. So this commit remove the rule id prefix from Details field of Vulnerability and also add a workaround to users that is already using the new hash as a false positive and risk accept. To support the two ways of hashing the vulnerability a new field was added on Vulnerability struct that represents the breaking way, so we generate the two hashes of vulnerability and when we set the vulnerability to false positive/risk accept according to config file we use the two hashes to match. Fixes #680 Signed-off-by: Matheus Alcantara <matheus.alcantara@zup.com.br>
This issue was fixed on version v2.6.3. Users getting this problem please upgrade to this version or greater. |
This was referenced Oct 23, 2021
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened:
The vulnerability hashes from version 2.6.0 is different from 2.5.0. This causes new vulnerabilities to be reported. Vulnerabilities previously registered as false positive and accepted risk are reported again, but with a different hash.
What you expected to happen:
All vulnerability hashes are the same after update
How to reproduce it (as minimally and precisely as possible):
Create a example file with a leak:
Execute horusec v2.5.0 results in this vulnerability:
Execute horusec v2.6.0 results in this vulnerability:
Note that the
ReferenceHash
from two versions is different. Was expected to be equals.Anything else we need to know?:
Affected versions:
The text was updated successfully, but these errors were encountered: