this brings up a general question: is there a policy in place on how to handle security updates? both for libraries used by the software (i.e. also affecting binary downloads or even maven artifacts) as well as components of the docker images?
i can see two options:
you have an update-test-and-release-ASAP strategy (i.e. CVE pops up, dependabot (which i believe wasn’t properly enabled with OpenSearch#664 because i’ve never seen any PR from dependabot on any of your repos - probably something to look into again?)) creates a PR, you merge it, you create a fix release of the affected things) on all supported releases (whichever those are?)
you analyse the CVE and publish a documentation confirming that the CVE has no impact on opensearch / users of opensearch and that an update is thus not needed as a hotfix (can e.g. be done if an update is more complicated than the analysis)
@ralph There is actually some working going on with this. The project uses whitesource but there is some thoughts on using dependabot. You can find a relevant discussion in this issue
thanks for the update, looks like 1.2.1 released but it only fixed log4j issue. (Not NSS issue)
What is the best way to create our own custom openearch image with 1.2.1 as base and update with appropriate NSS package 3.67.xxx
@ralph Yes, we update dependencies to pick up security fixes, as well as fix any known issues in the project code, with every new release. If an issue like the Log4j2 one shows up that warrants immediate attention, we don’t wait for the next scheduled release, and instead issue a patch release right away.