GSoC'26 Midterm Blog: Building BLT University Into an Interactive Security Learning Platform

#opensource #gsoc #owasp #programming

Overview

This summer, I got the chance to contribute to OWASP BLT, a project under the OWASP umbrella organization, through Google Summer of Code 2026. My project is focused on BLT University, a security learning platform that helps learners and contributors understand web vulnerabilities through hands-on labs.

The main idea behind this project is simple: instead of only reading about vulnerabilities, learners should be able to identify vulnerable code, explain why it is unsafe, and then fix it. This makes security learning more practical and closer to real open-source contribution work.

BLT University is part of the OWASP BLT ecosystem and aims to make cybersecurity education more accessible through open learning material and practical labs.

During the first half of GSoC, most of my work went into building the foundation for this experience: structuring labs, creating an interactive lab engine, adding validation, improving contributor workflows, and setting up tests so the platform can grow safely.

What is my GSoC all about?

My GSoC project is about transforming BLT University from a mostly static educational site into an interactive cybersecurity learning platform.

The core learning flow I am building is:

Identify the vulnerable part of a code snippet.
Explain why the code is vulnerable.
Fix the issue using safer code.

This flow is being built on top of a static Jekyll site, so a big part of the work has been designing a system that works without a traditional backend while still supporting structured content, validation, progress tracking, and future dashboard features.

The main tech stack for this phase included Jekyll, Markdown, YAML frontmatter, JavaScript, JSON Schema, Python validation scripts, Jest, jsdom, GitLab CI, and browser localStorage.

Key deliverables

Lab content and platform structure

Created 10 labs across major web security topics.
Moved lab content into _labs/ using Markdown and YAML frontmatter.
Added lab listing and lab detail pages.

Interactive learning experience

Built an interactive lab engine with Identify, Explain, and Fix stages.
Added line-selection based vulnerability identification.
Added explanation and fix validation.
Added browser-side progress storage using localStorage.

Contributor workflow

Added schema validation for labs.
Added a lab validation script for contributors.
Added contributor documentation and a reusable lab template.

Gitlab CIs & Tests

Added GitLab CI checks for validation, build, and tests.
Added a Jest test baseline for lab behavior, validators, progress storage, and state transitions.

Progress vs proposal

At midterm, the strongest progress is in the foundation layer. BLT University now has a structured lab platform and the core interactive learning flow is mostly in place.

Proposal area	Current progress	Status
Structured labs	Labs live in `_labs/` and render through Jekyll.	Mostly complete
Interactive flow	Identify, Explain, Fix, feedback, hints, and progress storage are working.	Mostly complete
Contributor workflow	Schema validation, docs, and a reusable lab template are in place.	Mostly complete
Quality checks	GitLab CI and Jest test coverage have been added.	In progress
Intelligence dashboard	Planned for the second half.	Upcoming
Personalisation	Recommendations, analytics, badges, and streaks are planned next.	In second half

Architecture

The main challenge was connecting the different parts of BLT University into a reusable system.

Lab content begins in _labs/, where each lab is defined using Markdown and YAML frontmatter. During the Jekyll build process, these files are transformed into static pages. A shared JavaScript engine then powers the interactive Identify, Explain, and Fix workflow by loading the lab configuration, rendering the simulation, validating learner submissions, and tracking progress in the browser using localStorage.

flowchart LR
    author["Contributor writes lab<br/>Markdown + YAML frontmatter"] --> labs["_labs/ collection"]
    labs --> schema["Schema validation<br/>and lab checks"]
    schema --> ci["GitLab CI<br/>validate, build, test"]
    labs --> jekyll["Jekyll build"]
    jekyll --> page["Static lab page"]
    page --> data["Embedded lab data"]
    data --> engine["JavaScript lab engine"]
    engine --> identify["Identify vulnerable code"]
    identify --> explain["Explain the issue"]
    explain --> fix["Fix with safer code"]
    fix --> progress["Browser progress<br/>localStorage"]
    engine --> feedback["Hints and validation feedback"]

Merge requests

MR !1 introduced the first interactive simulation work and helped move the project from static reading material toward hands-on labs.
MR !2 improved the lab page structure and site integration so labs could be rendered more consistently.
MR !3 added schema validation, the lab validation script, and contributor-facing lab documentation.
MR !4 expanded the lab with additional web security labs such as command injection, file upload vulnerabilities, open redirect, sensitive data exposure, and SSRF.
MR !5 added automated test coverage for validators, simulation state transitions, progress storage, and lab engine behavior.
MR !6 refined the lab simulation experience and addressed review feedback around reusable simulation behavior.

Links:

Repository: BLT University on GitLab
Live demo: BLT University

Challenges & What I Learned

One of the main challenges was building interactive experiences on a static Jekyll site without relying on a backend. The lab pages are static, but the learner experience still needs dynamic behaviour: selecting lines, validating answers, showing feedback, and tracking progress. This pushed me to think carefully about what should live in Markdown, what should be handled by Jekyll, and what should be handled by JavaScript.

Another challenge was designing reusable validators. Security fixes can be written in many valid ways, so the validators cannot simply check for one exact answer. They need to focus on secure coding patterns, such as parameterised queries or restricted redirects, while still giving useful feedback to learners.

I also learned how important state management is in an interactive learning flow. A step being unlocked is different from a step being completed, and learners should be able to restart earlier stages without the UI showing later stages as complete. Fixing these details made the lab engine feel more reliable and less confusing.

Next phase after midterm

After midterm, the focus will move from the foundation layer to the intelligence and personalisation layer.

It will include:

Building the vulnerability intelligence dashboard to show vulnerability trends, OWASP category patterns, and related BLT University labs.
Creating data files for vulnerability trends and OWASP category weights.
Mapping vulnerability patterns to relevant labs.
Building a recommendation system based on learner progress and vulnerability frequency.
Improving the lab dashboard experience.
Adding learner analytics across categories.
Improving accessibility and keyboard navigation.
Adding badges, streaks, and static hint fallbacks.

The long-term goal is for BLT University to become a platform where contributors can learn security through practice and understand which vulnerabilities matter most based on real patterns from open-source development.

The first half of GSoC was about building the foundation: labs, validation, reusable interactions, contributor workflows, and tests. In the second half, I'll be building smarter learning experience where BLT University not only teaches individual vulnerabilities, but also helps learners understand what to practice next and why it matters.