GSoC 2026 Proposal: Security Audit for OpenELIS Global

Community
1

Name: Brian Patrick Bahati

Email: bahatibrianp@gmail.com

GitHub/Portfolio: Bahati308 (Brian308) Ā· GitHub

LinkedInhttps://www.linkedin.com/in/brian-patrick-bahati/

Synopsis / Abstract

As a system handling sensitive health information, ensuring the security and integrity of OpenELIS is critical. This project aims to perform a comprehensive security audit, identifying vulnerabilities, risks, and potential attack surfaces, and recommending fixes or implementing safeguards where feasible.

The goal is to provide OpenELIS with a robust security baseline, enhancing trust, compliance with data protection standards, and long-term maintainability.

Benefits to the Community

  1. Stronger Security Posture: Identify and mitigate vulnerabilities to protect patient and laboratory data.

  2. Community Awareness: Provide the OpenELIS community with a detailed security report and best practices for secure deployment.

  3. Compliance: Align OpenELIS with global healthcare security standards (e.g., HIPAA, GDPR compliance considerations).

  4. Open-Source Security Contribution: Set an example of secure software practices in open-source healthcare projects.

Deliverables / Expected Results

By the end of this project, the following will be delivered:

  1. Security Audit Report

    • Threat modeling and attack surface analysis

    • Vulnerability scanning results (OWASP Top 10, dependency vulnerabilities, etc.)

    • Recommendations for mitigation and secure coding practices

  2. Test Cases & Automation Scripts

    • Scripts for automated security checks (static analysis, dependency checks, and CI/CD integration)

  3. Optional Fixes

    • Patches or pull requests addressing high-risk vulnerabilities identified during the audit

  4. Documentation

    • Guidelines for secure deployment and coding standards for OpenELIS contributors

Technical Details / Implementation Plan

Phase 1 ā€“ Initial Assessment (Weeks 1ā€“2)

  • Understand OpenELIS Global architecture and components

  • Map out potential threat vectors

  • Review existing security documentation

Phase 2 ā€“ Vulnerability Scanning (Weeks 3ā€“4)

  • Perform static and dynamic code analysis

  • Analyze dependencies for known vulnerabilities

  • Test for common security risks (SQL injection, XSS, CSRF, insecure file handling)

Phase 3 ā€“ Risk Analysis & Prioritization (Weeks 5ā€“6)

  • Categorize vulnerabilities by severity

  • Identify immediate, medium-term, and long-term security actions

Phase 4 ā€“ Mitigation and Patching (Weeks 7ā€“10)

  • Implement fixes or suggest remediations

  • Develop automated CI/CD checks for security issues

Phase 5 ā€“ Reporting and Documentation (Weeks 11ā€“12)

  • Compile final security report with findings, mitigations, and recommendations

  • Provide documentation for contributors to maintain secure practices

Requirements / Skills Needed

  • Strong understanding of web application security and secure coding practices

  • Familiarity with OWASP Top 10 and security best practices for web-based software

  • Experience with Python, Java, or related languages used in OpenELIS

  • Knowledge of CI/CD, automated testing, and static analysis tools

  • Basic understanding of healthcare compliance and data privacy standards

Why I Am a Good Fit

  • Certified in Ethical Hacking, Cybersecurity, and Networking

  • Experienced in auditing and securing open-source codebases

  • Strong background in web applications, DevOps practices, and automated testing

  • Passionate about contributing to healthcare IT projects and improving open-source software

  • Participated in GSoC 2025 where I improved the E2E QA Tests with OpenELIS

References / Resources

Future Work

  • Continuous security monitoring integration into OpenELIS CI/CD pipeline

  • Regular security audits and automated patching of dependencies

  • Education for community contributors on secure coding practices

cc: @caseyi , @Moses_Mutesasira

1 Like
2

very good brainstorm that we highly need,

2 Likes
3

Thanks @tasksolver . Great Idea.

2 Likes
4

@Moses_Mutesasira @tasksolver
If this does not over load and misalign the project direction, can we consider adding performance testing as part of the security assessment?

This could fit well in Phase 2 alongside your security testing, using tools like:

  • JMeter or Locust for load testing
  • OWASP ZAP has performance testing capabilities
  • Monitoring resource usage during penetration tests
    As you already Mentioned !
2 Likes
5

this so insightful @Agaba_Derrick_Junior , thanks !

1 Like
6

Great initiative. Iā€™m particularly interested in Phase 4 regarding the CI/CD checks.

While the one-time audit is great, the automated scripts will be the real long-term value here. Iā€™d suggest prioritizing the integration of tools like SonarQube or Bandit into the pipeline early (maybe move part of that up to Phase 2?). If we can catch vulnerabilities on every PR automatically, that saves us from needing another major audit next year.

CC: @Moses_Mutesasira @tasksolver