SecObserve
SecObserve copied to clipboard
Multiple remediations per observations
We're currently thinking about how to solve the following scenarios:
- 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
andworkaround
. - 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 selectingvendor_fix
.
Things to consider:
- The CSAF
remediation
currently depends on the SecObserverecommendation
. It looks like you can't specify arecommendation
for imported observations. - As far as I see it, CSAF allows to specify multiple remediations for one observation (e.g.
vendor_fix
andworkaround
, 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 https://github.com/MaibornWolff/SecObserve/discussions/1106#discussioncomment-8708628
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.
What we could do:
- Have a new relationship
Observation_Remediation
, where we can store multiple remediations per Observation. - Each entry has
-
category
(values can be taken from https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#323121-vulnerabilities-property---remediations---category) -
text
-
- Users can add, edit and delete remediations for imported or manual observations.
- The current attribute
recommendation
will still be filled by imports as before - When generating a VEX document, the new remediations are used if one or more have been added, otherwise the
recommendation
from the scanner is used.
Does that makes sense, @dervoeti ?
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".
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.
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.