Replies: 4 comments
-
|
Having a tree of observation according to the dependencies of an observation would generate a lot of entries. The dependency tree for the above mentioned example looks like this: Grype found 4 observations for In my opinion we have a good compromise at the moment, but this discussion shows, it would help a lot for the assessment, to have the full tree of dependencies available. I have implemented this and it's part of the |
Beta Was this translation helpful? Give feedback.
-
|
Another thing I learned is, that Grype and Trivy change the dependencies of an SBOM, when you analyze a CycloneDX SBOM and get the result as CycloneDX as well. I hoped to get exactly the same
Not what I expected. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! I agree, the current compromise is fine and there's no value in swamping analysts with thousands of observations. I just checked out the current Now there's one open question left: In the VEX documents, do we want to list the affected components or just relate the vulnerability to the product branch? Listing the components brings more information into the VEX, but the question is whether this is really needed, or if the approach "Only issue a VEX for the component that's affected most severely" is better. This would keep the VEX simpler and currently, in the VEX, there's not too much information provided about the component anyway (just the identifier, nothing about how the component is brought in or who the vendor is). I stumbled across this when thinking about how to structure the |
Beta Was this translation helpful? Give feedback.
-
|
Having the component with the relationship in the VEX document like it is implemented currently, makes it more unambiguous. When we have 2 components with the same vulnerability, one affected and the other one not_affected, then a person or a tool reading the document can better understand, what's going on. Without the component it is not that clear anymore, why the decision was taken. We could have 2 components with the same vulnerability, both not_affected but with different justifications. Without the component we could report only one justification, eg. from the first component. But with the components the decisions are reported completely. And Trivy for example has implemented the usage of components and relationships recently, so we know they are used by tools. |
Beta Was this translation helpful? Give feedback.
-
I've been thinking about what exactly we want to publish VEX statements about, or rather which level of detail is necessary.
I can think of three levels:
Currently, each product branch seems to have a flat list of affected components (the observations).
But a component can be referred to via different paths:
If we look at the SBOM for Apache druid-server 26.0.0 for example, we can see that
jackson-databind@2.10.5.1is a dependency of several components, likejackson-datatype-guava@2.10.5andaws-java-sdk-core@1.12.317.So,
jackson-databind@2.10.5.1is a transitive dependency of multiple other components and appears multiple times in the dependency tree, via different paths. In one of those paths, a vulnerability injackson-databind@2.10.5.1might be exploitable, while in another path the same vulnerability might not be exploitable (because the vulnerable code is not used).This means that these different paths to the same component could be different observations.
The paths in the example would be
druid-server 26.0.0 -> jackson-datatype-guava@2.10.5 -> jackson-databind@2.10.5.1and
druid-server 26.0.0 -> aws-java-sdk-core@1.12.317 -> jackson-databind@2.10.5.1.That of course requires additional information (like an SBOM), at least something that provides the dependency tree, to know those paths. A simple scan of the container image won't suffice. Both Trivy and Grype are able to scan SBOMs and at least Grype seems to provide the correct component relations in the scan result (in the
dependenciesattribute, if the format of the scan result is CycloneDX). So, instead of a list of components, a product branch would have a tree of components. Every possible path to the vulnerable component could be a separate observation.I realize that this is a lot of effort and I'm not sure whether this is really necessary, it just came to my mind and I wanted to mention it. SecObserve already does something with the
dependsOnattribute (in the_filter_component_dependenciesfunction), but it looks like only the first path to a component is resolved (and stored inorigin_component_dependencies), not all paths.For reference, this is the command I used to scan the druid-server SBOM with Grype:
Another option would be to say "well, only issue a VEX for the path to the component that has the most severe effect", which might be good enough and would not require a tree structure (this is basically level 2 in the levels mentioned in the beginning). Or you could even say "only issue a VEX for the component that has the most severe effect" (this would be level 1).
I'd say from the VEX consumer side, the simplest level of detail would be sufficient (level 1). As a consumer of the software I want to know "Is my Apache Zookeeper 3.8.3 affected by CVE-2024-1234 and if yes, what do I need to do". I don't really care in which component the vulnerability is. It's either exploitable in at least one component or it isn't.
On the other hand, as a vendor creating those VEX statements, I might want to store my analysis result as detailed as possible. Which components exactly where affected, which were not.
These are only assumptions though.
I think the current solution is fine and a good compromise, but I wanted to spark a discussion about this in general. Can this just stay the way it is? Would a component tree be better than a component list (is this level of detail required)? Or can details be reduced even further, meaning that one observation per vulnerability in a product branch is sufficient, even if multiple components are affected?
Beta Was this translation helpful? Give feedback.
All reactions