Hi Joshua, It may take a lot of effort and knowledge to review whether CVEs are exploitable or not. I have seen this kind of analysis done in a few cases, such as SnakeYAML recently: https://s.apache.org/beam-and-cve-2022-1471 ( https://github.com/apache/beam/issues/25449)
If there is a patch available, I believe we should err on the side of caution and update them (if possible). For the example that you mentioned, there is some work started by Alexey Romanenko to remove/decouple Avro from Beam core, so we can upgrade to newer versions: https://github.com/apache/beam/issues/25252. Another recent progress is Beam releasing a new version of its vendored gRPC to move past some CVEs originated from protobuf-java: https://github.com/apache/beam/issues/25746 Is there any other particular dependency that you are concerned about? Please consider filing an issue at https://github.com/apache/beam/issues so we can start tracking it. Best, Bruno On Mon, May 1, 2023 at 5:28 PM Brule, Joshua L. (Josh), CISSP via user < user@beam.apache.org> wrote: > Hello, > > > > I am hoping you could help me with our vulnerability remediation process. > We have several development teams using Apache Beam in their projects. When > performing our Software Composition Analysis (Third-Party Software) scan, > projects utilizing Apache Beam have an incredible number of CVEs, Jackson > Data Mapper being an extreme outlier. > > > > I Jackson Data Mapper is a transitive dependency via Avro but I am > wondering. Has the Apache Beam team reviewed these CVEs and found them NOT > EXPLOITABLE as implemented. Or if exploitable implemented mitigations > pre/post usage of the library? > > > > Thank you for your time, > > Josh > > > > *Joshua Brule* | Sr Information Security Engineer >
