demisto
Vulndb fetch-Incidents
Contributing to Cortex XSOAR Content
Make sure to register your contribution by filling the contribution registration form
The Pull Request will be reviewed only after the contribution registration form is filled.
Status
- [ ] In Progress
- [x] Ready
- [ ] In Hold - (Reason for hold)
Description
Adds the "fetch-incidents" command for the VulnDB Integration. The Fetch-incidents fetches updates for vulnerability information and creates Incidents for them.
Must have
- [ ] Tests
- [ ] Documentation
Thank you for your contribution. Your generosity and caring are unrivaled! Make sure to register your contribution by filling the Contribution Registration form, so our content wizard @itssapir will know the proposed changes are ready to be reviewed. For your convenience, here is a link to the contributions SLAs document.
Hi @rundssoar, thanks for contributing to the XSOAR marketplace. To receive credit for your generous contribution please follow this link.
@itssapir: I marked the "fetch-incident" command as no cover for the Test Coverage to make the test continue to make sure the PR can move forward). Before i spend time developing a test for it, i would like to get first input if the PR is ok in general. I may write a test for (part of) that, but the majority of functions doesn't have coverage and i definitely won't write tests for the functions i didn't touch.
Hi @rundssoar, Thank you for your contribution!
Sorry for the delay, this requires some internal discussions since the addition is fetch-incidents. We will give an update about this soon.
In the meantime, feel free to reach out if you have any questions. Thanks again
Regarding your first point: The "min_disclosure_date" param/variable looks redundant. How is this different from first_fetch? can't first_fetch be used to give the same results?
The API return: the vulnerabilities that were updated or created in the last specified number of hours
This can mean, you are getting vulnerabilities that were disclosed years ago, but for some reason were updated within the specified number of hours. In case those are not of interest for the workflow, the "min_disclosure_date" allows to skip them, while you still may want to fetch incidents, that were updated / created since the given time initially (first_fetch)
Closing this for now as the contributor will no longer be available to handle this.
The current implementation fetches modified vulnerabilities as duplicates which does not fit the fetch-incident standards for XSOAR packs and would need to be changed to avoid these duplicates. (Getting updates on modified vulnerabilities that were already fetched would entail adding a mirroring mechanism as well)