OpenOSP EMR Maven Supply Chain

I was recently involved in a research project to secure the Maven build supply chain of a large healthcare application. It was an intriguing journey into the “ingredients” that make up modern software, and I want to tell you all about it!

My focus was OpenOSP EMR, an open-source electronic medical record system based on the OSCAR project, originally created by Dr. David Chan at the Family Medicine Department at McMaster University. This application is a cornerstone of the Canadian healthcare industry. It is a web application built using the Maven build tool, and the goal of this research was to secure the Maven build supply chain and document a blueprint for its future security.

The Problem

A study by the cybersecurity firm Synopsys revealed that a whopping 96% of all codebases contain open-source software. Now, you might be wondering: why does this matter? Well, open-source software is collected using a process called the software supply chain.

Think of it as the process of fetching the ingredients needed to cook software. But instead of food ingredients, we’re gathering software ingredients. This process can be prone to security risks called supply chain attacks. Imagine if someone tampered with your pizza ingredients before they even got to you! To keep our software safe, we need to protect the supply chain from these attacks. By understanding the risks and implementing best practices, we can protect our critical systems from potential threats.

In the same study, it was revealed that 84% of codebases contained at least one open-source vulnerability. OpenOSP EMR is no exception. I found issues resulting from unmanaged software dependencies, external domains, and other untrusted components. Public healthcare is a basic right for Canadians, and this research felt impactful as it contributes directly to the improvement of the Canadian healthcare industry.

Plan and Methodology

The goal was to collect data to gain more visibility into the supply chain. I started by analyzing the project structure, dependencies, and build process, identifying potential security vulnerabilities introduced by external repositories. I used plugins like the OWASP Dependency Checker and AquaSec Trivy as my trusty sidekicks in this investigation. I even investigated tools that can be integrated into the CI/CD workflow for automated security scans. It’s like setting up a security camera, but for code!

Every methodology has its limitations. This approach is primarily reactive; it focuses on addressing Maven build process warnings and assumes the components are trustworthy until proven otherwise. This could potentially overlook vulnerabilities that don’t trigger build warnings or those discovered after the components have been deemed safe.

The dynamic nature of supply chain components makes it difficult to maintain accurate data. It’s like trying to paint a moving train—by the time you finish one end, the other has already changed! This calls for a solution that can be integrated into the supply chain for continuous monitoring.

How I Resolved the Challenges

In the first phase, I collected data from Maven Build Logs. It was like going on a treasure hunt, but instead of gold, I was after logs! The OWASP Dependency Checker helped generate reports to scrutinize the dependencies, and CycloneDX helped generate an aggregate Software Bill of Materials (SBOM) containing all the components that are part of the project.

I faced some real challenges. The project consisted of unsupported components no longer being maintained by their original authors. Many were hard-coded in the local repository within the source code, often lacking documentation to clarify their purpose. It was like trying to assemble a jigsaw puzzle without the picture on the box! But I love a good challenge.

For the next step, I leveraged A.I. to gather information about dependencies and find well-known alternatives for unsupported components. It was like having a super-smart detective on the case! Once that was done, I used AquaSec Trivy to scan Docker images of the application. Trivy didn’t just discover vulnerabilities; it suggested the fixed versions for components. It was a win-win situation.

Key Findings and Recommendations

Let me explain it with a picture.

If you look closely, you will realize there’s a problem here. The top part, which represents most of this project, is like a shiny new skyscraper. It has a modern digital infrastructure, which is great. But do you see that trusty little block down there? That block is the weakness of this entire skyscraper. In the case of OpenOSP EMR, that block represents components that are just a little bit too outdated. They are hardcoded in the project source code and are still used today to build the application.

I proposed two approaches to fix this: a reactive approach and a proactive approach. Think of them as a dynamic duo—like Batman and Robin!

The Reactive Approach

In this approach, I recommended fixing the checksum values for existing components that could be trusted. I wrote a custom script called “Reactive Panda” to help the project achieve that. Secondly, I recommended transitioning components from untrusted repositories to their new home in Maven Central. Thirdly, until those components have a new home, I recommend changing the repository connection to HTTPS.

The Proactive Approach

This was the big one. I recommended integrating a few automation tools into the project:

Dependency Lock Maven Plugin: This keeps a ledger of checksums. Anytime the project is built, it validates the integrity of all components. If an attacker tries to inject a malicious component into the build process, it will stop them in their tracks.
OWASP Dependency Checker: This automatically scans components for known vulnerabilities right inside the Maven build process for early detection.
AquaSec Trivy: This scans for vulnerabilities during infrastructure deployment and stops the process if any critical issues are discovered.

Open-Source Contribution

I raised a pull request with all the recommended changes discussed here. It brings me so much joy to share that the change was approved and merged by the OpenOSP team into the master branch. My recommendations are now available in the project to benefit all the users of this application.

Final Thought

Securing the supply chain is about ensuring that the foundation of our critical systems is as strong as the structures we build on top of them.