/
OpenMRS Antibugotics Program 

OpenMRS Antibugotics Program 

Background and Rationale

OpenMRS supports patient care in many countries and healthcare settings. Because the platform runs on real patient data and, in many deployments, drives clinical workflows, security is not an optional concern, it is part of the platform's duty of care.

Driven by insights from the SAFE-OSE project, OpenMRS is launching a deliberate framework for the community members to discover, report, and help fix vulnerabilities. 

This program proposes a non-cash, recognition-driven program designed to operate alongside existing SAFE-OSE initiatives. It deliberately avoids the cash-bounty model, consistent with the community's standing Position on Bounties,and instead invests in mechanisms such as recognition, credentialing, Dev stage tie-ins, mentorship, and ecosystem contribution — that build durable community capacity.

The program is also designed, deliberately, to model security practices that other open-source projects can adopt. As one of the longest-running open-source health platforms, OpenMRS has both the opportunity and the responsibility to contribute the patterns it develops back to the wider open-source ecosystem.

Program Goals 

  • Software Resilience and Patient Safety: Proactively identify and patch critical vulnerabilities in OpenMRS Platform, the 3.x Reference Application, and its upstream dependencies before they can be exploited in production environments serving real patients.

  • Capacity Building and Secure Coding Culture: Foster a security-first mindset across the OpenMRS developer ecosystem, building the individual skills that turn contributors into security-aware developers.

  • Upstream Citizenship: Encourage the community to not just look at OpenMRS code, but to audit and contribute security fixes back to the libraries and dependencies OpenMRS relies on.

  • Ecosystem Expansion: Increase the total number of people who actively engage with OpenMRS.

  • Community Contributions: Expand the pool of community members who can triage, fix, and review security work. 

  • Workforce development: Produce verifiable security credentials, badges, and demonstrable experience that contributors can carry into their careers.

  • Setting the Standard: Create a blueprint that other digital public goods (DPGs) and global-health technology projects can freely adopt.

Program Scope 

Who can participate 

Any OpenMRS community member can participate in the program as outlined below.  If you are not a member of the community, please join.  If you are new to OpenMRS, getting involved takes just a few steps: 

  • Contributors start by creating a free OpenMRS ID 

  • Introducing themselves on OpenMRS Talk, the community's main forum, and

  • Join the community Slack and the #security channel to follow this program's activity.

  • The Get Involved guide on the wiki has the full walkthrough. Once you're set up, you're eligible to report findings, submit fixes, and earn the recognition described below.

In Scope

To be in scope, the reported bug must align with the following types of artifacts AND the types of security issues outlined for the program.  

Artifacts In Scope for the program include: 

  • Openmrs-core (the OpenMRS Platform)

  • OpenMRS 3.x Reference Application distribution and its constituent modules

  • Official OpenMRS release artifacts — .war, .jar, npm packages, and Docker images published by OpenMRS

  • Documented OpenMRS APIs (REST, FHIR)

  • The centralized GitHub Actions workflows in openmrs-contrib-gha-workflows and related security infrastructure

Types of Security issues that are in scope  for the above artifacts:  

  • Items on the dependency vulnerability dashboard, the CVSS / security dashboard, and demo instances at https://openmrs.org/demo/  

  • In scope vulnerability classes broadly follow the OWASP Top 10, including:

    • Authentication and session management flaws

    • Authorization and access control issues, including privilege escalation

    • Injection (SQL, command, etc.)

    • Cross-site scripting (stored, reflected, etc.)

    • Server-side request forgery; insecure deserialization; XML External Entity (XXE)

    • Cryptographic weaknesses with demonstrable impact

    • Sensitive data exposure, particularly Protected Health Information (PHI)

    • Vulnerable or outdated dependencies with demonstrable exploitability in the OpenMRS context

    • Supply-chain integrity issues affecting OpenMRS release artifacts

Out of Scope

If the security issue is on one of the following artifacts or of the type listed below, it is out of scope.  

Artifacts and implementations that are out of scope:  

  • Implementer-deployed instances. These belong to the operating organization (Ministry of Health, NGO, clinic, etc.), not to OpenMRS.

  • Third-party services not operated by OpenMRS (e.g., GitHub itself, Atlassian Cloud)

Types of security issues that are out of scope.  

  • Physical security attacks or attacks requiring physical access to a deployment

  • Third-party services not operated by OpenMRS (e.g., GitHub itself, Atlassian Cloud)

  • Issues that are configuration-only and addressable by the implementer at deployment time (these are documentation issues, not security findings)

  • Documentation issues 

  • Minor code changes

Incentives and Recognition

[TO BE ADDED]