-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
API: return stats for api (re)imports #5635
Conversation
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Conflicts have been resolved. A maintainer will review the pull request shortly. |
This reverts commit 0b7781e.
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.
This is a fantastic addition
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.
Approved
Pretty cool 😃 |
This PR adds some improvements to Reimport (and Import), mainly focused on returning statistics. These can be useful in ci/cd situations, for example to do follow up actions if there were new (critical) findings, or to store statistics in a ci/cd platform to show trends.
Changes:
IMPORT_UPDATED_FINDING
;IMPORT_UNTOUCHED_FINDING
to record which findings were untouched by a reimport;stats
property toTest
;stats
property toTest_Import
;statistics
in API responses forimport_scan
andreimport_scan
;index
to help with statistics lookup queries;IMPORT_UNTOUCHED_FINDING
action;IMPORT_UNTOUCHED_FINDING
;@override_settings(TRACK_IMPORT_HISTORY=True)
from tests as True has been the default for a whileAt some point during this PR I had added the
stats
property also toProduct_Type
,Product
andEngagement
. But this would become slow when serializing lists of these models. I tried to work with prefetching, but that is slow on these big joins. I tried using a seperate query for the statistics, but this would be hard to do at the right moment in the serializer classes (after paging, after filtering, but before serializing). So I removed this part and focused just on (re-)import statistics, which was the original goal of this PR.A more generic solution for statistics on
Product_Type
,Product
,Engagement
andTest
serializer has to be a different PR. The more I work with statistics on these models, the more I see that all this prefetching and querying is hard to maintain and hard to keep performant for all usecases. So maybe we should introduce a statistics table ('materialized view'), similar to product grade, that gets updated on modifications but can return statistics very easily without complex joins or slow performance.The statistics are quite verbose as I think it's important to have the severity in there as well to be able to make decisions based on for example the number of critical vulnerabilities still open or that were added. It also means that the stats are correct even if some parsers are importing findings as not
active
oris_mitigated
.For import there is only the
after
part of the statistics:For reimport, there is also the
before
anddelta
parts.