MaibornWolff / SecObserve

SecObserve is an open source vulnerability management system for software development and cloud environments. It supports a variety of open source vulnerability scanners and integrates easily into CI/CD pipelines.
https://maibornwolff.github.io/SecObserve/
BSD 3-Clause "New" or "Revised" License
74 stars 7 forks source link

Multiple remediations per observations #1199

Open StefanFl opened 4 months ago

StefanFl commented 4 months ago

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:

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

StefanFl commented 4 months ago

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 commented 3 months ago

What we could do:

Does that makes sense, @dervoeti ?

dervoeti commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.