Replies: 15 comments 12 replies
-
|
Exporting VEX documents will be a large task, which we have to implement step by step. To start it, I analyzed the OpenVEX and CSAF (VEX profile) specifications against SecObserve's attributes:
Steps could be:
Steps 4. and 5. will be quite large and be designed later. |
Beta Was this translation helpful? Give feedback.
-
|
Feature flag is in development: #1125 |
Beta Was this translation helpful? Give feedback.
-
|
@dervoeti @lfrancke What is a good strategy to generate VEX documents:
|
Beta Was this translation helpful? Give feedback.
-
|
I don't really have practical experience with VEX, so I can only answer this from a theoretical perspective, but I would expect us to generate one VEX statement per vulnerability (or group of similar vulnerabilities). For example: “This is our statement regarding Log4Shell vulnerabilities” with information about all affected products and their versions. So we would start by analyzing existing vulnerabilities and publishing VEX statements about them. In the long term, we plan to continuously scan our products and publish VEX statements for newly discovered vulnerabilities (again, a new vulnerability might affect multiple products). Perhaps it would be possible to solve all strategies by allowing a workflow like this in SecObserve: Select / Filter out various assessments and generate a VEX file for them. Then it would be possible to filter out "all assessments for this product" or "all assessments for these vulnerability IDs" or even "all assessments done within the last 3 days". So, the central logic would be "take N assessments and create a VEX statement for them". Again, this is only theoretical, I have neither fully thought this through nor experimented with it yet. |
Beta Was this translation helpful? Give feedback.
-
|
Good point, haven't thought about starting from vulnerabilities yet. Maybe we need both approaches, generating VEX documents for vulnerabilities and products. Not so sure about starting with vulnerabilities. We might want to report open vulnerabilities without an assessment. |
Beta Was this translation helpful? Give feedback.
-
|
This will probably evolve heavily over time. I can also see that it might be useful for customers later to just say: Give me all VEX statements for this product. |
Beta Was this translation helpful? Give feedback.
-
Without an assessment, the question is how to determine the dep-scan does it like that, it creates a VEX statement with "in_triage" (basically the same as "under_investigation", just the CycloneDX name for it) in the CycloneDX document for each vulnerability it found. So that's the default state of the VEX. Then, the logic would be "take N observations and create a VEX statement for them". An assessment would be optional and just influence the details of the VEX, but would not be necessary to create the VEX. As a user, an alternative would be to create a rule that sets all new observations to |
Beta Was this translation helpful? Give feedback.
-
|
That is something to consider. Current philosophy of SecObserve is: An observation is treated as relevant/open, until someone decides differently. Should be a good default, but maybe not ideal for creating a VEX document. I like your suggestion with the rule, that gives a project a way to decide themselves. |
Beta Was this translation helpful? Give feedback.
-
|
The branch https://github.com/MaibornWolff/SecObserve/tree/feat/vex_poc contains an initial implementation of the backend to generate VEX documents for CSAF and OpenVEX:
What is missing:
To test it you have to:
Looking forward to your feedback 😃 |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, will have a look at it this week! The work for "justification" is also almost done, PR will be ready very soon. |
Beta Was this translation helpful? Give feedback.
-
|
The It seems to be a meaningful implemention to me, but I am looking forward very much for your feedback. |
Beta Was this translation helpful? Give feedback.
-
|
Totally awesome 🎉 I will test this later today. We've been very actively developing our vulnerability management process this week and outlined some ideas. We plan to further refine our ideas next week and then we will provide feedback (also happy to contribute with PRs when it makes sense). |
Beta Was this translation helpful? Give feedback.
-
|
I made 2 major changes:
|
Beta Was this translation helpful? Give feedback.
-
|
Another change: I wasn't happy with the usage of uuid to make the filenames unique. After a look how other CSAF providers are doing it, it is now a combination of prefix, year and a counter. This should be really it from my side. |
Beta Was this translation helpful? Give feedback.
-
|
That looks pretty good already, thanks!
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. But I wouldn't include that in the current branch. I would like to merge the current branch into dev and release it soon. It is marked as experimental and must explicitely be activated. Then we can go from there with enhancements and changes. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, totally fine, the current state is already quite useful. Just wanted to mention this since we were thinking about what else we would need in our VEX statements. But I also think that it's a good idea to implement this in a separate step, since it might turn out to be a complicated task. |
Beta Was this translation helpful? Give feedback.
-
|
I just found a merged PR for Trivy, which amends how they deal with VEX documents: aquasecurity/trivy#5923 It might be a good idea, to generate CSAF documents like their test example https://github.com/juan131/trivy/blob/main/pkg/vex/testdata/csaf-not-affected-sub-components.json. Currently in our CSAF documents all vulnerabilities are mapped to the SecObserve product. Maybe it is better to map the vulnerability to its component and the components is related to the product. This would be similar to how we produce OpenVEX documents with products and subcomponents. |
Beta Was this translation helpful? Give feedback.
-
|
I think that's a very good idea and it's probably even necessary to implement it like that. A vulnerability might affect multiple components of a product and you might want to issue different statements for each affected component of the product. The vulnerability might be exploitable in component A but not in component B, even though scanners report the vulnerability in both components. In that case you could provide a workaround for component A and set component B to "Not affected". That's already possible in SecObserve, since you'd have two different observations in that case, but this level of detail needs to be reflected in VEX documents as well. |
Beta Was this translation helpful? Give feedback.
-
|
The components are now part of the CSAF document and the status of the vulnerabilities are now linked to a relationship of component_version to product_version. This make the CSAF documents much more meaningful. Please checkout the dev branch and test it. |
Beta Was this translation helpful? Give feedback.
-
|
Just checked this, looks very good already, thanks a lot! At our company, we need to look into how the hierarchy of the product tree should look like. We might have something like "Stackable (vendor) -> Stackable Data Platform (product family) -> 23.11 (release version) -> SDP Zookeeper (product) -> 3.8.3 (product version)". And then probably a list or tree of external components that are part of that product version. But I don't think it's the responsibility of SecObserve to provide an interface for this, as it will be hard/impossible to provide a "one fits all" solution. Our approach would be to take the CSAF document from SecObserve as a basis and then modify the product tree in an automated way to fit our needs. |
Beta Was this translation helpful? Give feedback.
-
I've been giving this some more thought today, it seems to be more complex than I thought (as always), this is the result: #1254 |
Beta Was this translation helpful? Give feedback.
-
|
With the new release 1.9.1 not only the generation of CSAF with components (see above) is productive, but there is a change in the authorization. VEX documents that have been created for a product now follows the product authorization. Maintainers and owners of a product can generate, update and delete VEX documents. |
Beta Was this translation helpful? Give feedback.
-
|
This sounds great, thank you! Speaking of authorization - and I can create a new issue for this: I think we'll need a workflow system in the future. I'm not sure if this should be in SecObserve or via an integration into an external system. I think I'd prefer it in SecObserve. What I mean is a approval/review system for vulnerability assessments. User A makes an assessment but before it is "public" it needs to be approved/reviewed by someone else. Just like with code reviews. We tried various commercial tools and didn't find a single one with this feature. |
Beta Was this translation helpful? Give feedback.
-
|
Good idea, please write an issue for it. I would make it optional per product. So you can decide for a product if assessments get in effect immediately (like now) or need a review. |
Beta Was this translation helpful? Give feedback.
-
|
Done: #1276 |
Beta Was this translation helpful? Give feedback.
-
|
Discussion closed as generation of VEX documents is implemented |
Beta Was this translation helpful? Give feedback.
-
When exporting vulnerability assessments as VEX, a justification is recommended if the status is set to "Not affected". A list of possible justifications was published by CISA, both OpenVEX and CSAF adopted this list.
Suggestion: Add a new field "justification" to the
Observationmodel and define the list of possible options according to the CISA document. Add a dropdown for this to the "Observation Assessment" dialog and only show it if the status "Not affected" is selected.I could try to implement this, if you think this makes sense.
Beta Was this translation helpful? Give feedback.
All reactions