GSOC 2026 Project #22 : Title: OWASP DevSecOps Maturity and controls implementation for the EBRAINS community - a PoC with the MIP platform

Mentors: Julien Dhallenne <firstname.lastname@chuv.ch>, Konstantinos Filippopolitis, Jonathan Haab

Skill level: Intermediate to Advanced (advanced mostly due to tool integration + reducing false positives + documentation quality)

Required skills: Git, CI/CD, basic security mindset, scripting, Docker, Linux, Python

Time commitment: part time or full time (175/350h)

About: Current code, infrastructure and CI/CD security practices vary in EBRAINS and the Neuroinformatics community. In many projects, they are only partially meeting security standards required by the Cyber Resilience Act (CRA) and NIS2. Using the Medical Informatics Platform (MIP) [1] as a PoC for demonstrating feasibility in the wider community, we want use the OWASP DevSecOps Maturity Model (DSOMM) [2], as the baseline to assess our current pipeline maturity, and the OWASP DevSecOps Guideline [3] as the reference for implementation. We have both Kubernetes-related IaC and software stacks that can be worked on. The MIP is a federated platform designed to help clinicians, clinical scientists, and clinical data scientists who want to adopt advanced analytics for clinical research. Users can explore harmonized medical data extracted from pre-processed neuroimaging, neurophysiological and medical records and research cohort datasets without transferring original clinical data.

Aims: This project starts with a DSOMM-based maturity snapshot that we will convert into an actionable implementation plan. We will implement the first controls of a “real” DevSecOps-enabled infrastructure for end-to-end quality and security of software. The outcome will be a working reference pipeline (IaC or application code) that produces security artifacts automatically (ex: scan reports, SBOM, policy results), demonstrating that high quality and secure software production is achievable in our community and reusable across teams. Finally, the contributor will package the results as a reusable “secure pipeline blueprint”. We will also plan upstream contributions to OWASP, should there be some discrepancies encountered in the OWASP guides and framework along the way.

Expected outcomes: There will be 3 phases, following the general GSoC calendar.

Phase 1: DSOMM baseline assessment + choose controls to implement (planning). Deliverables: DSOMM assessment report (simple matrix: current state → target maturity → chosen activities)

Phase 2: Implement DSOMM controls in pipelines and generate artifacts (main work). The amount of controls implemented depends on the time commitment.
Deliverables: Reference CI/CD pipeline implementation (GitHub Actions) with secret scanning, SCA+SBOM, IaC misconfiguration scanning or application SAST (depending on chosen focus of applicants) and Pipeline artifacts produced automatically (reports in CI artifacts, SARIF, SBOM files, policy checks, etc…)

Phase 3: Make it reusable, contribute upstream and polish documentation.
Deliverables: Documentation and developer workflow (ie. “how to fix findings, automatically or manually” and “how to adopt in another repo”) and finalize upstream contribution PRs (that could have been started during the project)

Website: GitHub - Medical-Informatics-Platform/mip-infra: MIP KaaS deployment infrastructure repo based on ArgoCD deployments · GitHub

Tech keywords: Git, CI/CD, Security, Scripting, Kubernetes, Github workflows, SAST, Kubernetes, DevOps, DevSecOps, SARIF, SBOM, DSOMM

Resources:

[1] Medical Informatics Platform: Medical Informatics Platform | EBRAINS

[2] OWASP Devsecops Maturity Model: OWASP Devsecops Maturity Model | OWASP Foundation

[3] OWASP DevSecOps Guideline: OWASP DevSecOps Guideline | OWASP Foundation

1 Like

I’ve been reading through the OWASP DSOMM framework to get familiar with the assessment approach
My question is: for the Phase 1 DSOMM baseline assessment, will the contributor be evaluating the mip-infra repository specifically or are there other MIP repositories that should be included in scope?

Hi @moghit-eou ,
Mentor here! Thank you for your interest and reading through the framework. For the repository, it is still open and I would like to leave the choice according to the interest of participants. Some people might be more software focused while others might have a stronger interest in IaC.

Happy to have @arnab1896 verify my e-mail for the mentor badge or something that would make my newly created account look a bit more official :slight_smile:

1 Like

Hi @jdaln

I’ve been digging into the DSOMM matrix to ground my Gsoc proposal in the current state of mip-infra and what I’ve found so far:

We already have a level 1 Build (Build & Deployment) with two active CI workflows and also we’re missing level 2 SBOM of components as mentioned in this article .

For example in another dimension :Test and verification ( static depth for infra ) there’s no test for stored secrets which means nothing scanning for accidentally committed passwords or tokens in YAML files.

Since this repo is pure IaC , I feel like adding secrets scanning check is the best starting point for Phase 2.

Just a quick question to help refine my proposal.

For the Phase 1. should I provide a high level snapshot of all DSOMM dimensions, or is it preferred that I perform a deep dive only on the dimensions targeted for Phase 2 (Build and Deployment , implementation, test and verification) and other dimensions are just optional ??

regarding PR #2, If you have any time I left a comment explaining why the lint-yaml workflow is failing.
And thank you for the assistance provided so far

Hi @moghit-eou ,

Thank you for your time already looking into it! Please make sure to follow the official Google procedure for joining the GSoC. This is the first time I attend it as a mentor so it is also new to me but @arnab1896 will be able to help you, should you have questions on the process.

Secret scanning is indeed a good start, like the OWASP documentation points out. There is a 1-button way to activate it on Github but I do not know how deep it goes. Overall, I think we could target more than mip-infra because it is quite a new repository and there has not been credential leaks there, as far I am aware (but hidden force pushes in PRs that were not yet garbage collected could always add some that I could not notice if we push it far into thinking!).

The goal is to cover as many phases as we can cover and to do it in a vendor-neutral way. I have experimented a little bit with secret scanning, SCA, SAST and DAST and found out a few neutral scanners that seems to be the best available for free for now. Please take a look to it. Of course this was just an experiment, but I believe it can push us forward a bit already :slight_smile: . local-sonarqube-osx/docs/analysis_guide.md at main · jdaln/local-sonarqube-osx · GitHub . In fact this list is not complete anymore, I have added scanners on the C/C++ sides that do DAST, provided the binary.

Hi @jd39 @arnab1896

I’ve submitted my GSoC proposal for this Project #22.

If you have any time, I’d appreciate your feedback on it. Here’s Proposal Draft.

Thanks again for your guidance on my recent PRs.

Thank you @moghit-eou . This is excellent! :slight_smile: