Skip to content
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

Update report_vuln to support tracking origin #19817

Conversation

adfoster-r7
Copy link
Contributor

Update report_vuln to support tracking origin

Verification

  • Ensure CI passes

@@ -116,13 +115,13 @@ def report_service(opts)
end

if opts[:task]
Mdm::TaskService.create(
Mdm::TaskService.where(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without this change, multiple entries were being created

end

ret[:service] = service
service
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A hash was never being returned from this method, the value assigned to the hash entry was being returned - i.e. the Mdm::Service

@adfoster-r7 adfoster-r7 force-pushed the update-report-vuln-to-support-tracking-origin branch 2 times, most recently from 983fd26 to d59c6f0 Compare January 20, 2025 20:54
@adfoster-r7 adfoster-r7 force-pushed the update-report-vuln-to-support-tracking-origin branch from d59c6f0 to c768ec8 Compare January 20, 2025 22:07
@@ -8,4 +8,61 @@
it { is_expected.to respond_to :find_or_create_service }
it { is_expected.to respond_to :services }
it { is_expected.to respond_to :report_service }

describe '#report_service', if: !ENV['REMOTE_DB'] do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the API for the remote db needs more work for existing functionality to be tested; but will mark this as skipped for now: #18439

@adfoster-r7
Copy link
Contributor Author

Note: Looks like this might be a weird pattern, as if a module is rerun multiple times - it will try to upsert the vuln model - and replace existing 'origin' definitions. This means if the user wants to see where a vuln came from - it will be the last reported module run.

This might be fine, but for the scenario of regenerating older reports - the link between the task run and the associated vuln may now no longer exist. This might be an existing problem with our data model though.

@smcintyre-r7 smcintyre-r7 self-assigned this Jan 23, 2025
@adfoster-r7
Copy link
Contributor Author

Will close this off; I don't think a single origin is a good pattern to follow for reported vulns - as multiple places may be able to identify a vuln. i.e. imports, or multiple different module reruns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants