Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
OpenMRS seeks to be a reliable and trusted application. We also recognize that security incidents can (and do) still happen, and so it's just as important to have effective methods for handling them should they arise.
Where to send Vulnerability reports
By Email: Anyone can send in reports via email to security@openmrs.org.
Or, on GitHub: you can use the Private Vulnerability Report feature in GitHub here. This helps us leverage GitHub's Security Advisory & CVE tools.
Our Security Group
A Security Group currently exists on OpenMRS Talk. Membership is by invitation only and is open to existing members of the OpenMRS community working on security issues. This Security Group automatically receives any messages sent to security@openmrs.org. (See More about Our Security Group below.)
To ensure our incident response process is consistent, repeatable and efficient, we have a clearly defined internal framework that covers the steps we need to take at each phase of the incident response process.
Community members and concerned parties work with OpenMRS' Security Group in logging, monitoring of our artifacts and infrastructure. The designated mechanisms through which security incidents are reported are:
Members of the Security Group will review the incident report and determine an incident severity categorization as depicted below:
Severity Level | Characteristic | Target time to resolve (Days) |
---|---|---|
Critical |
For critical vulnerabilities, it is advised that you patch or upgrade as soon as possible unless you have other mitigating measures in place. For example, a mitigating factor could be if your installation is not accessible from the Internet. | 90 |
High |
| 180 |
Medium |
| 180 |
Low | Vulnerabilities in the low range typically have very little impact on an organization's business. The exploitation of such vulnerabilities usually requires local or physical system access. | 1 Year |
Routine security updates will be highlighted in the release notes for each release. If a vulnerability is a critical one (e.g something submitted by an external body), members will receive an email to that effect
The security vulnerabilities group will determine depending on the level of severity of the incident, agree what corrective measures need to be taken to contain the incident, eradicate the underlying causes and start our recovery processes to ensure that operations return to normal. Thus a summary of activities at this stage would include:
We aim to notify affected community members within 5 business days or without undue delay if their data is involved in an incident or a breach. This might be light on detail at first, but we’ll provide every detail available when it is available. These initial communications will be done directly with the affected party as the matter is being resolved, however, as soon as the security group deems that it is possible to inform a broader audience, such information will be posted to the designated communication channel which is OpenMRS Talk.
Why create Security Advisories in GitHub?
We recommend using GitHub Security Advisories in the relevant repo(s). This is because:
After some period of time (e.g. ranging from immediately to 2 weeks, depending on the severity):
Security Advisory Format
Contains at a minimum:
Sample Template Here: Sample Template
Role:
The role of the group is to work with the finder or reporter to resolve the identified vulnerability. It is also tasked to continually review and understand vulnerabilities that are currently occurring within the system either by themselves or via programs such as bug bounties. This group is responsible for identifying the requisite resources needed to address any vulnerabilities addressed.
Scope of activities:
Roles within the Security Group:
Security Vulnerability “Manager” - Roles and Responsibilities