DEV Community: saksh

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

saksh — Sun, 05 Jul 2026 15:51:10 +0000

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.

Acknowledgement

I would like to thank all my mentors, for their guidance, review feedback, and support throughout this period.

Thank you for reading :)

Breaking Into Open Source This Summer? Start with OWASP BLT

saksh — Thu, 16 Apr 2026 15:31:47 +0000

As summer approaches, open source sees a steady wave of new contributors.
Each year, developers explore repositories, review issues, and look for meaningful ways to get involved.

The challenge is rarely writing code. It is understanding the system well enough to contribute effectively.

This summer, OWASP BLT is participating in the Social Summer of Code (SSOC), a three-month program focused on open source contribution, learning, and collaboration. It brings together contributors from diverse backgrounds to work on real-world projects, submit pull requests, and actively engage with the open source ecosystem.

About OWASP BLT

OWASP BLT (Bug Logging Tool) is a community-driven OWASP project developing open source tools for vulnerability reporting, bug tracking, and security automation.

The project spans APIs, dashboards, applications, bots, and ongoing research under OWASP. This is designed to make security workflows more practical, structured, and accessible for developers and teams.

Ongoing Deletion Program

Alongside regular development, OWASP BLT is running an ongoing deletion initiative.

Contributors review the repository, identify unused or unnecessary files, and remove them. Each valid contribution is rewarded with $1. This campaign will run till 30th April.

This effort focuses on:

Supporting the ongoing migration to separate and more structured repositories
Maintaining a clean and efficient codebase
Improving long-term maintainability
Helping contributors understand the structure of a real-world project

It also provides a simple and practical entry point for those beginning their open source journey.

Contribution Opportunities During SSOC

As the program progresses, more areas of the project will be opened for contribution, including:

Clearly defined and beginner-friendly issues
Opportunities across different parts of the stack
Active collaboration within the community

Whether you are exploring open source for the first time or looking to contribute to security-focused tooling, OWASP BLT offers a structured and meaningful way to get involved.

Get started 🚀

Explore the repository and start contributing:
https://github.com/OWASP-BLT/BLT.

The first step in open source

saksh — Wed, 04 Mar 2026 13:08:02 +0000

Back in October, I read a blog by GSoC contributor.

He talked about how he started, how he discovered open source, what he worked on, and how his journey unfolded. I already knew what open source was. I knew what GSoC was. I had watched the videos. I had read many blogs too.

But knowing something and stepping into it are two very different things.

I had this quiet dream of one day having that GSoC badge on my profile. And to have that, you need to contribute to open source.

But my brain kept whispering:

“What if you change one line of code and accidentally take down production?”

There’s also this narrative you sometimes see online that students (especially from India) “pollute” open source with low-quality contributions.

So my biggest fear wasn’t just breaking production with my code but also criticism .

In that blog, he mentioned his first PR in OWASP BLT. It was a small simple pr. And I thought if I could find something like that, maybe even I can contribute. So, I explored the organization.

Every page.

Every link.

Everything just to spot a small issue which I could handle.

And after some chaotic scrolling and determined clicking, I found what felt like buried treasure:

A broken link in the contribution guide. It was just a small href issue.
It really felt like mirage lol. I went to their repo , read the contributing guidelines, I set up the codebase and installed all the prerequisites.

When I solved the issue, the pre-commit kept failing. And I was like this is the end. It’s not going to work. It took me 5 hrs to solve everything. Eventually it worked and I raised the pr on 1st november 2025.

drum roll

And the very next day pr was merged.

Press enter or click to view image in full size

I remember, I kept visiting the site just to check my change lol. That tiny broken link was my entry into OWASP BLT and open source as whole.

And I’ll always be grateful for the blog, BLT.

Because fast forward to today, I have 20+ prs merged in this org.I learned how to interact with maintainers, contribute to real-world problems, and even give peer reviews.

I used to think open source was reserved for genius developers , turns out all I needed one first step forward.

If you’re still reading and hesitating. Go and explore https://github.com/OWASP-BLT.
You might find your own “broken href” moment.

And that tiny fix?
It might quietly change your trajectory.

Like it changed mine.

And yes, don’t treat open source like a competitive exam.

It’s about learning by working on real-world applications.

It’s about realising that your small change can help many people. That feeling is so powerful.

I hope it helps ;))