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

Multiple remediations per observations #1199

Open
StefanFl opened this issue Mar 8, 2024 · 5 comments
Open

Multiple remediations per observations #1199

StefanFl opened this issue Mar 8, 2024 · 5 comments

Comments

@StefanFl
Copy link
Collaborator

StefanFl commented Mar 8, 2024

We're currently thinking about how to solve the following scenarios:

  1. A product version is affected by a vulnerability and there's a mitigation or a workaround available for it. This would map to the CSAF remediation categories mitigation and workaround.
  2. A product version is affected and there's a newer version available that fixes the vulnerability. This would map to the CSAF remediation category vendor_fix. In theory this could automatically be determined, if a newer version is present in SecObserve that does not have this vulnerability (that requires some form of version comparison though). Or the user would manually specify that version when selecting vendor_fix.

Things to consider:

  • The CSAF remediation currently depends on the SecObserve recommendation. It looks like you can't specify a recommendation for imported observations.
  • As far as I see it, CSAF allows to specify multiple remediations for one observation (e.g. vendor_fix and workaround, so people can choose whether they want to upgrade or implement the suggested workaround).
  • Would the status "Risk accepted" be the appropiate one for both scenarios?

I'm not sure what's the best way to solve this, this is quite complex. Perhaps users could optionally provide a list of remediations when selecting "Risk accepted" in the assessment dialog. Happy to implement this, but I wanted to discuss the best way to do it first.

Originally posted by @dervoeti in #1106 (comment)

@StefanFl
Copy link
Collaborator Author

StefanFl commented Mar 8, 2024

I see what you mean, but have to think about, what the best solution is. I don't think it's the status "Risk accepted", that means it is as it is, I cannot do something at the moment and accept the risk that is involved with the vulnerability.

We might need a list of remediations with different categories, that are editable for imported vulnerabilities. They would need to be concatenated for OpenVEX.

@StefanFl
Copy link
Collaborator Author

What we could do:

Does that makes sense, @dervoeti ?

@dervoeti
Copy link
Contributor

Sounds good in general. The question remains if we need a new status "Affected" or something like that. And then only display the "remediations" section in the assessment dialog when the status is "Affected"?
I also think changes regarding remediations should go into the observation log. In that case, maybe it would be easier to make the remediations just another column of "core_observation", with data type JSON (we need to check whether all databases support this). That would make it easier to log the previous and current state of remediations in the log. I don't think the remediation change needs to be displayed in the log (comment should be enough) but at least the information should be present somewhere. An alternative would be to have a separate "Observation_Remediation_Log".

@dervoeti
Copy link
Contributor

I just checked, maybe https://docs.djangoproject.com/en/4.2/ref/models/fields/#django.db.models.JSONField could be used for this:

JSONField is supported on MariaDB, MySQL, Oracle, PostgreSQL, and SQLite (with the JSON1 extension enabled).

I'll try to draft something with this.

@StefanFl
Copy link
Collaborator Author

Please let's have a chat about it before you start. I am not sure what the right way is to deal with the issue and would like to understand your idea better.

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

No branches or pull requests

2 participants