Dependency Vulnerability Scanning

The OpenMRS Dependency Vulnerability Dashboard is a publicly accessible, automatically updated report that shows known security vulnerabilities across OpenMRS modules. It is generated by running OWASP Dependency-Check via GitHub Actions against each module's dependency tree.

The goal is simple: give module maintainers a single place to see which of their dependencies have published CVEs (Common Vulnerabilities and Exposures), how serious those CVEs are, and what version they need to upgrade to in order to fix them.

Direct links:

• OpenMRS O3 Security Dashboard

• https://openmrs.github.io/openmrs-contrib-dependency-vulnerability-dashboard/

Open

How the Dashboard Is Structured

When the page loads, it shows a list of OpenMRS modules. Each module header displays a severity badge (e.g., [Critical], [High]) reflecting the worst vulnerability found in any of its dependencies. Clicking or expanding a module reveals its full dependency table.

Module-Level View

Each module appears as an accordion row:

The badge beside the module name is the highest severity across all that module's vulnerable dependencies. Use this to triage at a glance — start with modules marked Critical or High.

Reading the Dependency Table

When you expand a module you see its Dependency Table — one row per vulnerable dependency. Here is what each column means:

Example row

This means: the module uses tika-core version 2.9.2. That version has 2 CVEs, the worst of which is Critical. No public exploit exists yet. Upgrading to 3.2.2 or later fixes both CVEs.

Reading the CVE Detail Table

Clicking on a dependency row expands the CVE Detail Table — one row per individual vulnerability. This is where you get the full technical picture.

Example CVE row

This means: a Critical XXE (XML External Entity) injection flaw with a near-perfect CVSS score of 9.8. It affects all tika-core versions below 3.2.2. The fix is version 3.2.2. The underlying weakness type is CWE-611.

How to Decide What to Fix First

Use this prioritisation order:

1. Critical severity + Exploit? = Yes — fix immediately. A working exploit exists and the flaw is severe.

2. Critical severity + Exploit? = No — fix in the next release cycle. High risk even without a known exploit.

3. High severity — schedule a fix. Monitor for exploit status changes.

4. Medium / Low severity — fix when you upgrade for other reasons, or batch with quarterly dependency updates.

Additionally, read the Description and CWE columns before starting work. Some CVEs only trigger in specific usage patterns (e.g., parsing untrusted PDF files). If your module never exercises the vulnerable code path, the risk is lower — but the dependency should still be upgraded to avoid transitive exposure and to keep the dashboard clean.

Taking Action: Opening a Fix PR

OpenMRS modules come in two flavours — backend (Java/Maven, pom.xml) and frontend (TypeScript/React, package.json + yarn). The dashboard covers both. Identify which type the affected module is before starting.

Once you have identified which dependencies need upgrading, the fix process is:

1. Identify all vulnerable dependencies for the module

In the dashboard, expand the module and collect every row where Fix Version is populated. Note the current version and the required fix version for each.

2. Update the dependency version

Backend modules (Maven / pom.xml)

Open pom.xml (or the relevant dependencyManagement block) and update the version:

If the dependency is managed by a parent POM or BOM, you may need to override it using <dependencyManagement>.

Frontend modules (yarn / package.json)

Open package.json and update the version range for the vulnerable package:

Then regenerate the lockfile and install:

If the vulnerable package is a transitive dependency (not directly listed in your package.json), use yarn's resolutions field to force the safe version across the entire dependency tree:

After adding a resolution, run yarn install again to apply it.

Run yarn audit to confirm no vulnerable versions remain after the upgrade:

3. Check for breaking changes in the upgrade

Major and minor version bumps often include breaking API changes. Before committing, check:

• The dependency's CHANGELOG or migration guide for breaking changes between the current and fix version.

• For backend: whether the module's code imports or calls any Java APIs that were renamed, removed, or changed in signature.

• For frontend: whether any TypeScript types, component APIs, or exported functions changed. Look for type errors after running yarn tsc or yarn type-check.

• Whether any transitive dependencies also need adjustment.

Fix any compilation errors or runtime failures introduced by the upgrade before opening the PR.

4. Test the fix

Dependency upgrades require both automated and manual verification:

Automated tests — backend:

• Run mvn clean test to execute the module's unit and integration test suite.

• Run mvn clean verify to include integration tests if they exist.

• All tests must pass before the PR is opened.

Automated tests — frontend:

• Run yarn verify (or the equivalent script defined in package.json, commonly yarn test, yarn lint, yarn type-check) to run the full check suite.

• All checks must pass before the PR is opened.

Manual testing:

• Deploy the updated module to a local OpenMRS instance.

• Exercise the features that use the upgraded dependency — for example, if a file-parsing library was upgraded, upload several file types and verify they are handled correctly.

• For frontend modules, open the relevant pages in the browser and check for console errors, visual regressions, and broken interactions.

• Check the OpenMRS server logs (backend) or browser console (frontend) for new warnings or errors after the upgrade.

• Test any REST APIs or UI flows that interact with the affected functionality.

5. Open a pull request

Create a PR with:

• Title: (chore) Upgrade <dependency> to <fix-version> to fix CVE-XXXX-YYYY

• Description: List each CVE fixed, its severity, and a brief note on what was tested.

• Reference: Link to the relevant module entry on the dashboard so reviewers can verify the fix is sufficient.

Example PR description (backend):

Example PR description (frontend):

Where Data Comes From

The vulnerability reports are generated automatically by the owasp-dependency-check.yml GitHub Actions workflow (in the openmrs-contrib-gha-workflows repository). The workflow runs OWASP Dependency-Check against each module, produces a JSON report, and commits it to the dashboard repository. The dashboard page reads those JSON files and renders them in the browser.

This means the dashboard reflects the last time each module's workflow ran — it is not real-time. After you merge a fix PR and the module's CI runs, the dashboard will update on the next workflow execution.

Quick Reference