As part of my research, I am looking at the detection and prioritization of vulnerable dependencies, i.e. VDs (open source libraries with known vulnerabilities). Recently, we wrote a paper where we compared 10 existing VD detection tools. For this comparison, we used openmrs-distro-referenceaapplication 2.10.0. The studied tools include OWASP Dependency-check, Snyk, npm audit and some commercial tools as well. We have just submitted the paper to a conference and is now awaiting peer-review. I am attaching the draft here for referencevulndep_tool_comparison.pdf (292.5 KB). I will appreciate any feedback on the paper.
To summarize the paper with relevance to this community, tools found many dependencies with known vulnerabilities in the latest release of OpenMRS reference application. Although we found different tools may inflate or deflate results with false positives/negatives, many VD alerts were detected by multiple tools as well. As an example, Snyk found 96 unique Maven dependencies with 189 known vulnerabilities among all 44 projects of the distribution.
Based on our study, I had some questions:
Does OpenMRS use any tool to monitor vulnerable dependencies?
Does OpenMRS have any policy or guidelines on how to address the vulnerable dependencies? I am guessing it may be necessary to assess the risk of these vulnerabilities from the context of OpenMRS and prioritize fixes if necessary.
While setting up OpenMRS, it asks permission if it can collect diagnostic/error reports. Is there any such database of error reports of OpenMRS that is publicly accessible? I am asking this because one of our future research ideas is to look into crash logs of an application to determine which dependencies appear on the stack traces which may be an indicator of how close a dependency is to the application’s attack surface. If OpenMRS has such crash logs or error reports that gives stack traces from real-world application use, it will be greatly helpful for our research.
I am tagging @f4ww4z and @teleivo based on this and this post. Also tagging @isears. Sorry for unsolicited tagging, but It’ll be greatly helpful if you can help me on my queries or guide me to the right direction.
Finally, I would appreciate any feedback or research suggestions on the draft paper I’ve attached here. Although the paper is long, the study uses OpenMRS as case study and I believe should be interesting to this community.
I don’t know much, but I know that dependabot is enabled in most (if not all) repositories we have. The thing is that they might not be necessarily released (and bundled into a distribution) until the next release, which could potentially take months.
Interesting research. At OpenMRS we’ve been using Snynk in our java-based repositories for some time as well as, more recently, Github’s built-in dependabot. One of the issues we face using these tools is that they were implemented pretty late in the game, so when they were first turned on, we had a very large number of alerts to deal with. Dependabot’s automated PR functionality has been especially helpful in remediating some of those issues and we’re slowly working towards phasing out all our vulnerable dependencies. I know @dkayiwa and @teleivo have been especially active on this front, huge props!
I think the above answers your questions (1) and (2), but I’m not sure about (3), maybe someone else can help you with that one?
I just read the abstract so far, but I’ll try to set aside some time later this week to read the rest. I’ll let you know if I have any useful feedback!
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?
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?
The attached work on surveying existing tools, and we chose OpenMRS as the subject case study. We are still figuring out what our next project can be. If you suggest any specific research opportunity with respect to OpenMRS projects, that’ll be great.