@nasif thank you for bringing that up and sharing your work!
I am not aware of any policy or guideline. Security Overview · openmrs/openmrs-core · GitHub “Security policy” might be something we could look into to start setting one up.
I believe that at the moment vulnerabilities get fixed by:
- Someone that sees a reported vulnerability and takes on the work to update the dependency
- A major openmrs release. A vulnerability might be in openmrs for quite a long time until there is a major openmrs release that gets a lot of updates which remediate the security issues.
I also think we currently only monitor the master branch whether its snyk or dependabot. See automatic dependency updates - #12 by teleivo So I assume (have not read your paper yet) that even actively maintained openmrs versions have known vulnerabilities in them.
Like you said a clear guideline on how vulnerabilities should be reported. How vulnerabilities that have a patched version is available should be fixed. Also how we deal with vulnerabilities that have no patched version available. All of the approaches we take should be automated as much as possible since the time the community has for all the things that need to be done is very limited. So there is definitely a lot of valuable work that would benefit users, implementers and developers of OpenMRS.
Is a goal of your research to also come up with specific suggestions for the OpenMRS community or is OpenMRS rather a subject for studying the tools available to opensource communities?