# GSoC 2026 Proposal: Security Audit for OpenELIS Global **URL:** \ **Category:** Community\ **Created:** [January 20, 2026, 12:58pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862 "2026-01-20T12:58:48Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![tasksolver](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/tasksolver/32/1067_2.png) [@tasksolver](https://talk.openelis-global.org/u/tasksolver)\ **Post date:** [January 20, 2026, 12:58pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/1 "2026-01-20T12:58:48Z")
# **Name:** Brian Patrick Bahati **Email:** [bahatibrianp@gmail.com](mailto:bahatibrianp@gmail.com) **GitHub/Portfolio:** [Bahati308 (Brian308) · GitHub](https://github.com/Bahati308) **LinkedIn** [https://www.linkedin.com/in/brian-patrick-bahati/](https://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** 2. **Test Cases & Automation Scripts** 3. **Optional Fixes** 4. **Documentation** ## **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** - OpenELIS Global repository: [OpenELIS · GitHub](https://github.com/OpenELIS) - OWASP Top Ten: [https://owasp.org/www-project-top-ten/](https://owasp.org/www-project-top-ten/) - Security testing tools: OWASP ZAP, Bandit (Python), SonarQube, Snyk - Relevant papers and guides on secure lab information systems ## **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 ---
**Author:** ![Agaba\_Derrick\_Junior](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/agaba_derrick_junior/32/503_2.png) [@Agaba\_Derrick\_Junior](https://talk.openelis-global.org/u/Agaba_Derrick_Junior)\ **Post date:** [January 20, 2026, 2:59pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/2 "2026-01-20T14:59:33Z")
very good brainstorm that we highly need, ---
**Author:** ![Moses\_Mutesasira](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/moses_mutesasira/32/72_2.png) [@Moses\_Mutesasira](https://talk.openelis-global.org/u/Moses_Mutesasira)\ **Post date:** [January 20, 2026, 6:28pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/3 "2026-01-20T18:28:46Z")
Thanks @tasksolver . Great Idea. ---
**Author:** ![Agaba\_Derrick\_Junior](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/agaba_derrick_junior/32/503_2.png) [@Agaba\_Derrick\_Junior](https://talk.openelis-global.org/u/Agaba_Derrick_Junior)\ **Post date:** [January 21, 2026, 6:59pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/4 "2026-01-21T18:59:34Z")
@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 ! ---
**Author:** ![tasksolver](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/tasksolver/32/1067_2.png) [@tasksolver](https://talk.openelis-global.org/u/tasksolver)\ **Post date:** [January 21, 2026, 7:21pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/5 "2026-01-21T19:21:48Z")
this so insightful @Agaba_Derrick_Junior , thanks ! ---
**Author:** ![Vishal\_Sharma](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.openelis-global.org/vishal_sharma/32/739_2.png) [@Vishal\_Sharma](https://talk.openelis-global.org/u/Vishal_Sharma)\ **Post date:** [January 23, 2026, 6:00pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/6 "2026-01-23T18:00:46Z")
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 ---
**Author:** ![Gopikaa](https://avatars.discourse-cdn.com/v4/letter/g/ce73a5/32.png) [@Gopikaa](https://talk.openelis-global.org/u/Gopikaa)\ **Post date:** [March 23, 2026, 11:49am UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-security-audit-for-openelis-global/1862/7 "2026-03-23T11:49:03Z")
Hi, I’m Gopika J, a fourth year computer science student from Kerala, I was looking into applying for contributions to OpenELIS via GSOC, I’ve done work relevant to the aforementioned task: such as security patches and introducing CI/CD tests for another open source repository Hyphae APIS under LF (Linux Foundation) Energy , I believe we could introduce static analysis testing and fuzzing in addition to the points mentioned above as well. I strongly believe I could contribute to this given my prior experience. Here’s some of my previous work : > > > code scanning/security issues shows that a vunerability exists in the repository…: > refer here: https://github.com/hyphae/apis-emulator/security/code-scanning/13 > > The vunerability had occured due to returning a user defined variable (key) : > previously when the system couldn't find the specific key requested by a user, it would send an error message back by directly sending back the users input to a sentence ( return "key not found: " + user\_input) > > the browser treated this response as active text (HTML), If a malicious user sent a key that was actually a script, the browser would trust the server and run that code automatically, thus resulting in the cause of the vunerability. > > the patch implemented resloves vunerability #13 by instead returning a JSON object within which I have wrapped the error and the user input- which ensures its non executable as a script. > > I've tested the build and this hasn't brought any issues wrt functionality. > patching the vunerability would ensure we follow ossf best practices as defined here : > https://www.bestpractices.dev/en/projects/9993/baseline-1 > > would appreciate if someone could cross verify these changes accordingly ! @axmsoftware > > > have written a CI test for github/workflows to ensure build doesnt break due to …any changes to repository, as an additonal check. > > changes made in line with resolving issue (refer here) : https://github.com/hyphae/apis-emulator/security/code-scanning/12 > > please let me know if any changes are to be made to the CI test, for now the yml file does not include test for docker build, it works on runner directly, changes can be made to accomodate for that as well, > would be greateful for any feedback on PR, lmk if lgtm , thankyou!have written a CI test for github/workflows to ensure build doesnt break due to any changes to repository, as an additonal check. > > changes made in line with resolving issue (refer here) : https://github.com/hyphae/apis-emulator/security/code-scanning/12 > > please let me know if any changes are to be made to the CI test, for now the does not include test for docker build, it works on runner directly, changes can be made to accomodate for that as well, > would be greateful for any feedback on PR, lmk if lgtm , thankyou!