DefectDojo
Dependency Check Reimport already existing finding, if suppressed, does not reflect suppressed in Defect Dojo
Bug description As per the Defect Dojo documentation at https://defectdojo.github.io/django-DefectDojo/integrations/parsers/#dependency-check. The ideal behavior while importing the dependency check scan suppressed findings is following.
But this behavior is true only for the dependency check scan report suppressed findings which are already not available in the scan result on Defect Dojo. If the finding which has been suppressed is already available in the Findings list for the scan result on Defect Dojo, then that finding is not marked as suppressed during reimport scan.
Dependency check scan findings which are now suppressed in the suppression file, should be marked automatically as suppressed during /reimport-scan/.
Steps to reproduce Steps to reproduce the behavior:
- Go to 'Product Type-> Product -> Engagement -> Test section'
- Click on 'Import Scan Results' to import a dependency check scan report with no suppressed findings.
- After selecting the dependency check scan report with with the findings marked as suppressed in the suppression xml file, click on 'Re-Upload Scan Results'
- Verify that the findings which are suppressed in the suppression xml file are marked as suppressed in Defect Dojo.
Expected behavior If the finding which has been suppressed is already available in the Findings list for the scan result on Defect Dojo, then that finding should be automatically marked as suppressed during reimport scan.
Deployment method (select with an X)
- [x ] Docker Compose
- [x ] Kubernetes
- [ ] GoDojo
Environment information
- Operating System: [e.g. Ubuntu 18.04]
- DefectDojo version - v. 2.14.1 and v. 2.16.1
I think the re-importer logic will only work with mitigated findings, so the part about suppressed vulnerabilities only be marked as inactive and not mitigated won't work with the re-importer.
I have the same issue with version v. 2.15.1 I believe in an older version a suppression also changed the status on existing findings.
The current behaviour is, that the inital import creates active findings. When you import the same report again the findings will be updated as inactive and gets the suppressed tag.
I have done some more tests now on the head dev branch. I have worked with the dependency check parser.
When I ran the tests all seems to be fine. Also upload and re-uploading the test files works as expected. But the reimport via the API is not working.
Here is a way to reproduce the issue with the existing test file:
- start DD and get the API Key
- run
curl --fail --location --request POST 'http://localhost:8080/api/v2/reimport-scan/' \
--header 'Authorization: Token XXX' \
--form 'active="true"' \
--form 'verified="true"' \
--form 'scan_type="Dependency Check Scan"' \
--form 'test_title="test_title"' \
--form 'product_type_name="Portal"' \
--form 'product_name="product_name"' \
--form 'auto_create_context="true"' \
--form 'engagement_name="engagement_name"' \
--form 'file=@"django-DefectDojo/unittests/scans/dependency_check/multiple_vulnerabilities_has_multiple_findings.xml"'
-
Now you can see all finding as active
-
When you run the same curl again, all suppressed finding will be marked as inactive
I hope this help to fix the issue. I think it's a bug in the re-import API.
Tested with 2.51.2 and we still have the same behaviour. The suppression is ignored during the first reimport.
If you specify active=True all new findings will be created as active, overwriting any status in the report. But the flag only applies to new or reactivated findings, so on the second run the status from the report will be used.
What would be your proposed solution? The easier way would be to not set active to True if you want to use the status from the report.
I had a misunderstanding about the active parameter. I thought it would define the default state and not enforce it.
Nevertheless, I see a problem here in the different treatment between the first import and all subsequent imports. I think this should be consistent. I suggest either always marking suppressed findings as inactive or always marking them as active, regardless of the suppression tag. I don't know how other tool importers handle this. It would probably be good if they were treated the same way here.