DEV Community: OWASP BLT

When GitHub Went Dark: How OWASP BLT Found a New Home

Donnie Brown — Tue, 20 Oct 2026 23:54:11 +0000

50+ repositories went offline in the middle of Google Summer of Code. Here's how our community kept moving, and how an unexpected project became our new home.

This one is a bit of a rollercoaster, so buckle up. 🎢

The calm before the storm

It was the middle of Google Summer of Code (GSoC).

OWASP BLT (Bug Logging Tool) had more than 50 repositories under a single GitHub organization. We had everything from the core application to Slack bots, a browser extension, a hackathon platform, a GSoC tracker, and a long list of tools built and maintained by our contributors.

Things were moving along nicely.

Mentors were reviewing. Contributors were shipping. Leaderboards were updating. The usual open-source chaos, but the good kind.

Then we decided to do some housekeeping.

Good security hygiene, right?

We applied an organization-wide GitHub ruleset to enforce consistent repository protections across all our projects.

A security-focused project enforcing security rules on its own organization.

What could possibly go wrong?

The morning after: everything was gone

We woke up to find our GitHub repositories offline.

All 50+ of them.

And here's where things got confusing.

At almost exactly the same time, GitHub itself was experiencing an outage.

So for several hours, we genuinely had no idea what was happening.

Was it our new ruleset? Was something wrong with the BLT organization? Was it GitHub's outage? Or was the timing just a coincidence?

We contacted GitHub support.

Then we followed up.

And followed up again.

Days passed, and we never received a clear explanation for what had happened to our organization.

Mostly, we got silence.

Meanwhile, Google Summer of Code wasn't going to pause for us.

Contributors had active branches. Mentors had pull requests waiting for review. Projects had deadlines.

When developers can't clone repositories or open pull requests, that's more than an inconvenience. It brings development to a halt.

We needed another option.

Plan B: moving to GitLab

Rather than keep waiting for answers, we moved our repositories to GitLab.

We pushed the code, redirected contributors to the new location, and worked on getting everything running again.

Repositories were accessible. CI pipelines were migrated where possible. Contributors could get back to work.

It wasn't the migration we'd planned.

Actually, we hadn't planned a migration at all.

But the community adapted, and development continued.

We still wanted our original GitHub organization restored, of course.

We kept reaching out to GitHub over the following months.

Unfortunately, we still didn't get a clear answer.

An unexpected plot twist: Kaif built a Git forge

Here's where the story gets interesting.

Some time later, we learned that one of our community members, Kaif, had built something of his own.

While we had been dealing with the fallout of losing access to our GitHub organization, Kaif had turned the situation into a project.

He built ForkMesh, a self-hosted Git forge.

Think of it as having your own GitHub-like platform, with:

Git repositories and code hosting
Issues and pull requests
Actions-style CI/CD workflows
Support for AI agents as first-class collaborators
The ability to run your own instance

The funny part?

We hadn't set out to build or commission our own Git hosting platform.

We had moved to GitLab to keep things going, and later discovered that someone in our community had built an entirely different option.

So we gave ForkMesh a try.

And it stuck.

From 50+ repositories to one home

Today, OWASP BLT has a very different setup.

Our official source of truth is now git.owaspblt.org/BLT, running on ForkMesh.

And we took the opportunity to do something we'd wanted to do for a while: consolidate our projects.

### One repository, all our history

Instead of maintaining 50+ separate repositories, BLT projects now live together in one repository, organized into their own folders.

We preserved their commit histories along the way.

That means:

45,000+ commits preserved
260+ contributors represented
Projects organized in one place
One central home for issues, contributions, and development

That's a lot of community history, and we wanted to make sure it came with us.

### GitHub is now our mirror

Yes, you read that correctly.

GitHub went from being our primary home to being our backup.

Our repository at github.com/OWASP/BLT is now a read-only mirror, automatically synchronized from our forge.

The source of truth is the forge we host.

Funny how things turn around.

### GitLab is archived, not forgotten

We didn't just abandon our temporary GitLab home.

Every open merge request was reviewed. Contributions worth bringing forward were merged into the new repository, with the original authors credited.

Other merge requests were closed with explanations.

Open issues were migrated to the forge, with references back to their original locations.

The GitLab repositories remain archived so old links and project history are still accessible.

### A little cleanup along the way

We also used the migration as an opportunity to clean up some technical debt.

For example, scheduled data jobs now write to Cloudflare storage instead of filling the Git history with automated bot commits.

A bunch of little improvements that might not have happened otherwise.

Sometimes an unexpected migration gives you a good excuse to fix things you've been putting off.

What this taught us

There are a few lessons we're taking away from the experience.

1. Don't put all your eggs in one platform

GitHub is an important part of the open-source ecosystem, but relying entirely on one platform introduces risks.

Your source code, issues, contributions, and project history represent years of community effort.

Having a backup is inexpensive. Losing access without an explanation can be extremely costly.

We now have much more control over where our work lives.

2. Test organization-wide changes on a smaller scope first

We still don't know exactly what caused our GitHub organization to become unavailable.

It would be unfair to claim the ruleset was responsible without confirmation.

But we learned something important regardless.

When making changes that affect more than 50 repositories, start small.

Test the behavior, understand the impact, and expand gradually.

Because when a large change goes wrong, the consequences can be just as large.

3. Open-source communities are remarkably resilient

This is probably the biggest takeaway.

What kept BLT going wasn't a particular platform.

It was the people.

Contributors continued working. Mentors kept supporting students. The community found alternatives.

And one community member went a step further and built a Git forge that eventually became our new home.

That's the part of open source we love most: people turning problems into opportunities to build something useful.

Come build with us 🐝

If you already contribute to OWASP BLT, or you've been thinking about getting started, our new forge is where the action happens.

👉 Explore the OWASP BLT repository

You can browse the projects, clone the repository, open issues, submit pull requests, and help us improve both BLT and the contributor experience.

We're still learning what works best with our new setup, and we'd genuinely appreciate feedback.

One more thing: we have a world 🌍

Because apparently moving 50+ repositories wasn't adventurous enough, there's also something fun to explore.

The forge comes with its own virtual world.

OWASP BLT has its own hex, complete with:

A bug terrarium filled with websites that people have reported bugs on. You can walk inside through the door.
A Hacker House you can enter and explore.
A road connecting the BLT world to the neighboring ForkMesh world.

It's a playful little addition to what started as a pretty frustrating situation.

👉 Take a walk around the BLT World

We started with more than 50 GitHub repositories, lost access to them in the middle of GSoC, moved to GitLab to keep development going, and eventually found a new home thanks to something a community member built.

Not exactly the infrastructure roadmap we'd imagined.

But here we are: 45,000+ commits, 260+ contributors, one forge, and a community still building.

See you on the forge. 🐝

Eleven Projects, One Remarkable Team: Celebrating OWASP BLT’s GSoC 2026

Donnie Brown — Mon, 31 Aug 2026 01:11:26 +0000

Open source is often measured in commits. The better measure is what those commits make possible.

During GSoC 2026, the OWASP BLT community worked across 11 projects: four Google Summer of Code projects and seven paid internship projects. The team built zero-trust security pipelines, practical learning experiences, privacy tools, AI-assisted contributor workflows, edge-native services, and the infrastructure needed to run them in production.

By the end of the summer, the portfolio was not a collection of slide decks. Nine projects had live applications or documentation sites, Hackerhouse had a new production domain and healthy database-backed deployment, and the Cloudflare-backed projects had current deployments and completed migrations.

This is the team behind that progress.

The GSoC projects

Preetham Poojari — BLT-NetGuardian

Preetham helped turn NetGuardian into a serious zero-trust ingestion and triage pipeline. The system verifies signed finding envelopes, applies replay protection and role-based access, stores metadata in D1, and supports CVE-aware review. The result is a working bridge between distributed security research and accountable triage.

The repository records 90 commits by Preetham during the coding period, and the deployed service now has scheduled maintenance running through BLT Monitor without consuming another Cloudflare cron slot.

Mentors: Jisan and CarlaV.

Try NetGuardian · Source code

Sakshee Suman — BLT-University

Sakshee advanced BLT-University as a hands-on security learning platform built around a clear loop: identify a vulnerability, explain it, and fix it. The project connects practical labs with real vulnerability insights and makes security education something learners can actively do.

The local history shows 40 coding-period commits across Sakshee’s author identities. The result is live, browsable, and designed to make the next generation of security contributors more capable from day one.

Mentors: BishalDas and Chigorin.1337.

Explore BLT-University · Source code

Md Kaif Ansari — BLT-Next

Md Kaif worked on the broadest architectural challenge in the programme: moving BLT from a tightly coupled Django application toward modular, edge-first services. BLT-Next demonstrates the direction with a static frontend, Cloudflare Workers, D1-backed services, and independently deployable capabilities.

That work reaches beyond one repository. The programme roster credits Md Kaif across BLT-Next and supporting BLT services including API, docs, hackathons, jobs, monitor, newsletter, and Zero. The success here is architectural: a clearer path to a capable platform with dramatically lower hosting overhead.

Mentors: DonnieBLT and Rinkit Adhana.

Visit BLT-Next · Source code

Ananya — BLT-Vanish

Ananya evolved BLT-Vanish toward a universal identity shield: phishing detection, credential hygiene, suspicious-login correlation, encrypted workflows, and explainable risk scoring across web and Flutter clients.

With 59 coding-period commits in the web repository, Ananya moved the project from an idea toward a cohesive privacy and personal-security experience. The production web app is now served from its dedicated OWASP BLT subdomain.

Mentors: Ankitsinghsisodya and Ramansh.

Try BLT-Vanish · Source code

The paid internship projects

Savio D’souza — BLT-Preflight

Savio built an ambitious local-first contribution assistant spanning the editor, pre-commit checks, and CI. Its hybrid classifier and OWASP-documentation retrieval layer are designed to catch risk while a contributor can still act on the feedback—not after a review cycle has already stalled.

Savio authored 28 coding-period commits across his recorded identities. Preflight is deployed as a live interactive experience, with the repository retaining a second optional API target for future provisioning.

Volunteer mentor: Raj Gupta.

Open BLT-Preflight · Source code

Ojaswa — BLT-Toasty

Ojaswa’s Toasty tackles one of vulnerability management’s hardest operational problems: turning raw reports into safe, useful, structured intelligence. It combines fail-closed PII redaction, AI summarization, duplicate detection, webhook ingestion, durable state, and MCP export.

The coding period includes 74 commits by Ojaswa, ending with a polished architecture showcase and quick-start experience. Toasty’s Worker, state migrations, and public site are deployed and tested.

Meet Toasty · Source code

Nachiket Roy — BLT-MCP

Nachiket made Model Context Protocol practical for the BLT contributor ecosystem. BLT-MCP gives tools and agents a consistent way to discover capabilities and work with project context instead of relying on brittle, one-off automation.

With 88 coding-period commits, Nachiket delivered one of the summer’s most active repositories. The live service makes the work immediately discoverable to both contributors and tool builders.

BLT-MCP project experience

BLT-MCP live CLI and vulnerability triage view

Explore BLT-MCP · Source code

Karuna Rapolu — BLT-SafeCloak

Karuna’s SafeCloak work focused on privacy guardrails and safer user workflows. The project gives users a security-focused place to reason about exposure and make better privacy decisions without turning the experience into an expert-only tool.

The summer established a deployed, tested baseline and a public experience on its own subdomain—an important foundation for deeper privacy automation.

Visit SafeCloak · Source code

Rudra Pratap Singh — BLT-Hackerhouse

Rudra helped build Hackerhouse as a collaboration pipeline for hands-on offensive and defensive security work. The application now has a real production stack: a Python Worker, Durable Objects, a D1 database, queue-backed events, applied migrations, and regression-tested health reporting.

Rudra authored 48 coding-period commits. Hackerhouse also reached a particularly visible milestone this summer: a healthy production deployment at its new dedicated domain.

Visit Hackerhouse · Source code

Sidd190 — BLT-Autopatch

Sidd190 took on automated patch generation and validation: an idea with enormous potential to shorten the distance between discovering a vulnerability and safely remediating it.

Autopatch is the portfolio’s earliest-stage project. Its success this summer was establishing the project home and a clear direction for the work ahead. Calling that out honestly matters: healthy open source celebrates shipped systems and the people laying foundations for the next contributors.

Source code

Jayant — BLT-MAYO

Jayant developed BLT-MAYO as a shell dangerous-execution analyzer—a practical quality and safety tool for BLT engineering workflows. The repository now contains its Python package, tests, documentation, configuration example, and a focused analyzer design.

Jayant authored three coding-period commits across his recorded identities, progressing the project from initial structure into working analysis and test foundations.

Source code

What the team achieved together

The individual stories are impressive. The shared outcome is bigger:

11 contributors received ownership of meaningful, security-focused projects.
Nine projects now have live applications or documentation experiences.
Cloudflare-backed releases were brought current and smoke-tested.
D1 migrations were applied and verified with no pending migration queues.
Hackerhouse gained a production database, queue, Durable Objects, and its own domain.
NetGuardian’s maintenance schedule was integrated without exceeding the account’s five-cron limit.
Project discovery now leads with live experiences and clearly identifies GitLab as the source-code home.

Most importantly, the team produced multiple on-ramps into open-source security: learn with University, protect identities with Vanish, review findings with NetGuardian, improve reports with Toasty, guide contributions with Preflight, and build new automation through MCP.

From the contributors

The strongest account of a programme comes from the people who built it. Continue with these contributor stories, demos, and community reflections:

Thank you

Thank you to every contributor, GSoC mentor, volunteer mentor, reviewer, tester, and community member who made room for this work to grow. Great mentoring is invisible in a diff, but visible everywhere in a project that becomes clearer, safer, and more welcoming over time.

Explore the full OWASP BLT GSoC 2026 team and project page, visit the live project directory, and find the complete source-code organization on GitLab.

The summer is over. The work—and the community behind it—is just getting started.

My GSoC journey with OWASP BLT

saksh — Mon, 24 Aug 2026 11:41:28 +0000

The journey of Google Summer of Code has come to an end.

It is hard to believe how quickly the past few months have gone. When I first started contributing to OWASP BLT, I was simply trying to understand an unfamiliar open-source project and find a way to make my first meaningful contributions. I did not expect that journey to eventually lead me to GSoC and to working on BLT University.

My journey with OWASP BLT started before GSoC, when I took my first steps into open source and began learning how to contribute to an existing project. I gradually became more comfortable with the codebase, the contribution process, and working through reviews and feedback. I documented those early experiences in my earlier post about getting started with open source.

Over the course of the program, BLT University evolved significantly. What started as a small collection of interactive security labs grew into a broader security learning platform with interactive labs, courses, learning tracks, vulnerability insights, saved progress, recommendations, and automated browser testing.

I shared the first half of my work in my midterm post. This final report brings together everything I built during GSoC, from the first interactive labs to learning tracks, vulnerability insights, saved progress, and browser tests.

BLT University is now a static, interactive learning platform with 13 labs, five courses, two tracks, and a dashboard built from recent public vulnerability records. Progress is stored locally. You can explore the live website, try the SQL injection lab, or explore the Security Trends dashboard.

Demo video

What I built

Over the course of GSoC, the project grew from a small set of interactive security labs into a broader learning platform.

Built the first interactive SQL injection, XSS, and CSRF simulations using the Identify, Explain, Fix flow. MR 1
Added the lab structure, validation script, contributor guide, reusable template, and automatic validation. MR 2
Updated the main site pages and layouts to improve navigation, responsiveness, and consistency. MR 3
Added tests for validators, state changes, hints, saved progress, and lab simulation flows. MR 4
Added the IDOR lab and its guided simulation. MR 5
Added six more security labs, expanding the initial lab collection. MR 6
Added the complete Identify, Explain, Fix simulations and reorganised the lab engine into focused files. MR 8
Built the NVD and CISA vulnerability pipeline, CWE-to-OWASP lab mappings, schema validation, pipeline tests, and the generated 90-day dataset. MR 10
Hardened the lab engine, improved saved-progress handling, reorganised validation code, and documented the engine behaviour. MR 11
Added AST validation for JavaScript lab answers, tests that reject unrelated code containing expected security keywords. MR 12
Built the Security Trends dashboard with charts, search, filters, a CVE explorer, text fallbacks, and progress-aware lab recommendations. MR 13
Added Cyber Hygiene and Professional Security tracks, three Cyber Hygiene labs, track filters, course-to-lab navigation, and adaptive recommendations. MR 14
Expanded five courses with interactive activities and related labs, then added saved progress, streaks, badges, next-course suggestions, and cross-browser tests. MR 15

Future enhancements

Automate regular vulnerability-data updates while keeping validation and review checks.
Add more courses and labs across both learning tracks.
Improve lab-authoring tools so contributors can create exercises more easily.
Expand accessibility and browser testing across complete learning journeys.
Add Python-based exercises and more adaptive hints.

Acknowledgements

I would like to thank Google Summer of Code, OWASP, and the entire OWASP BLT community for giving me this opportunity and supporting me throughout my journey. A special thank you to Donnie Brown for his guidance, feedback, and support throughout the project. I am grateful to have worked with and contributed to this community.

Building an AI-Powered Security TUI with Rust and MCP

Nachiket Roy — Wed, 19 Aug 2026 16:05:15 +0000

Picking up where I left off

In my midterm update, I introduced the two main parts I was working on for OWASP BLT: BLT-MCP, which connects AI models with the BLT API, and BLT-CLI, a Rust-based terminal interface for working with BLT.

At that point, most of the foundation was there, but some of the features were still being worked on. The triage workflow was still coming together, and the screenshot analysis feature was only an early experiment. Since then, both have come together quite a bit, so here is where the project is now.

What BLT-CLI can do now

The CLI has grown quite a bit since the midterm version. You can browse vulnerabilities, search and filter reports, view bounty hunts, check contributor rankings, inspect individual vulnerabilities, submit new reports, and use the AI features for analysis and screenshots.

There are also logs and health information available from the interface. Guest mode is available as well, so you can explore the application without having to configure everything first.
Here is a small demo of BLT-CLI running in guest mode -

How it works

There are currently two ways to use the CLI. In the basic mode, it talks directly to the BLT API.

When AI features are needed, it can use BLT-MCP, which sits between the CLI, the BLT API, and the AI models. This keeps the terminal interface focused on the actual user experience while the MCP server handles the connection between the different services.

AI-assisted triage

One of the main things I wanted to experiment with was using AI to help with triage. When looking at a vulnerability, the AI can analyze the available information and provide suggestions around severity, attack vectors, potential impact, duplicate risk, and other things worth considering.

The AI does not automatically change the vulnerability. It gives you an analysis that you can review and decide what to do with. I think this is an important distinction. AI can save time when doing repetitive analysis, but I did not want it making changes behind the scenes.

Submitting reports from the terminal

The report submission workflow is also now part of the CLI. You can fill in the usual information such as the title, URL, severity, bug type, description, and proof of concept.

The form can be filled out entirely from the terminal and submitted directly to BLT. So the workflow can now go from looking at a vulnerability, analyzing it, writing the report, and submitting it without having to constantly move between different applications.

From a screenshot to a report

This was probably the feature I was most interested in when I started working on the project. At the time of the midterm update, the vision part was still very experimental. Now it works as part of the normal workflow.

You can provide a screenshot and the vision model can analyze it and help fill in parts of a vulnerability report, including the title and reproduction steps.

What comes next

There is still plenty to improve. Some of them are better AI analysis, more reliable MCP tools, smoother TUI workflows, better error handling, and more functionality in the CLI.

I also want to keep experimenting with how AI can fit into security workflows without turning everything into an automatic black box. The current version is really just a starting point.

Wrapping up

This also concludes my summer term project. It was genuinely fun to spend the term building and testing new things, especially getting to work with Rust, MCP, AI models, and the terminal UI together.

Not everything worked on the first try, and there were plenty of things I had to rethink along the way, but that was probably one of the best parts of the project. I got to experiment with different ideas and see what actually made sense once everything was put together.

There is still a lot that can be improved, but I am happy with where the project ended up compared to where it started.

Try it out

The project is still evolving, so there are definitely some rough edges.

BLT-CLI and BLT-MCP will be published soon, and once they are available, you will be able to try them out yourself. If you find something that does not work or have an idea for improving the workflow, feel free to open an issue or merge request.

The project is still being built, and feedback from people actually using it is probably the most useful thing it can get.

Thank you for reading and following along!!

Connecting AI and Security with BLT-MCP

Nachiket Roy — Mon, 06 Jul 2026 21:25:45 +0000

This summer i was given the opportunity to work on my BLT-MCP project with OWASP-BLT. Over the last few months, I've been working on transforming how users interact with BLT. Now it marks the midpoint of the project, and there's been some interesting development i would like to share.

What is MCP?
MCP (Model Context Protocol) is an emerging open standard that helps AI models securely interact with local tools and remote data sources. By building an MCP server for OWASP BLT, we're essentially teaching AI assistants (like Claude, Cursor) how to natively speak with BLT directly. Your AI can read issue context, browse repositories, and submit vulnerabilities, without ever leaving your IDE.

The Two Pillars So Far

The MCP Server
Written in Python, the server acts as the translation layer between LLMs and the BLT API. It exposes two main capabilities to the AI:
- Resources (blt:// URIs) - the AI can fetch live data exactly when it needs context. For example, reading blt://issues/123 to get the details of a specific vulnerability.
- Tools - actionable endpoints that let the AI do things, like submit_issue and add_comment.
The BLT-CLI (Rust Terminal UI)

While IDE integration is great, sometimes you just want a fast terminal experience. I built BLT-CLI in Rust using ratatui a Terminal UI (TUI) that connects directly to the MCP server and the BLT API. Triage logic is being built alongside it, so you can browse, review, and act on issues right from the terminal.

What's Next
The core logic and terminal are built. For the remaining sprint, I'll be focused on testing everything end-to-end, polishing the rough edges, and starting work on a vision pipeline that can turn a dropped screenshot into a drafted vulnerability report, which is still early and in progress.
Thanks for following along!

Building BLT HackerHouse: An Open Source Journey!

rp_dex — Sun, 05 Jul 2026 16:35:08 +0000

Over the past few weeks, I've had the opportunity to intern with OWASP BLT, where I've been working on BLT HackerHouse a real time platform that visualizes contributor activity in an interactive virtual house.

The idea behind HackerHouse is simple: as contributors open merge requests, report bugs, or interact with the project, their avatars move through different rooms, giving maintainers a live overview of what's happening across the community. Behind that visualization is a backend responsible for processing events, managing contributor state, and delivering updates in real time.

When I joined, I expected my biggest challenge to be designing the backend architecture. Instead, the project took an unexpected turn.

During development, the OWASP BLT GitHub organization became inaccessible, requiring the team to migrate active development to GitLab. It wasn't just a matter of moving repositories documentation, development workflows, CI/CD pipelines, and contributor onboarding all had to be updated while development continued.

It was the first time I'd experienced how quickly the direction of an open source project can change and how important adaptability is. Watching the community reorganize and keep shipping despite the disruption was a valuable lesson in resilience.

Alongside the migration, I focused on building the backend foundation for HackerHouse. This included designing an event processing pipeline, implementing webhook handling, creating a unified event model, building real-time communication with WebSockets, and writing automated tests to ensure the system remained reliable as it evolved.

One of my biggest takeaways from this internship has been that building software isn't just about implementing features. It's about designing systems that can evolve, collaborating with an open source community, and adapting when unexpected challenges arise.

I'm excited to continue developing HackerHouse over the coming weeks and contribute further to the OWASP BLT ecosystem. This experience has already taught me far more than I expected not just about backend engineering, but about how resilient and collaborative open source communities can be.

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 :)

📢 Calling all Content Writers & Community Builders!

Ananya — Sun, 03 May 2026 20:21:06 +0000

Hey everyone! We are opening up opportunities for everyone to contribute to our official social media channels. If you enjoy writing, sharing tech insights, or highlighting community wins, we want you on the BLT Newsroom team! 🗞️✨

Here is how the process works:

Topics & Deadlines: We will regularly share specific writing topics based on our current requirements, along with a submission deadline.
Submit Your Draft: Write your post based on the given topic and share your draft right here in the group before the deadline hits.
Review & Feedback: The lead project maintainer and social media maintainers will review all the submitted drafts.
Final Selection: The draft that gets the top reviews will be selected and published on the official OWASP BLT social media pages!

This is a fantastic way to build your portfolio, practice your technical writing, and get your work seen by a much wider audience. Keep an eye out for our first topic announcement soon! 🎨💻

Apply here: https://jobs.owaspblt.org/job.html?id=owasp-blt-content-writer
Join our slack community today!👉https://join.slack.com/t/owaspblt/shared_invite/zt-3rstz26wj-WtlZFo5RXqT_9UwNYJeycw
Then join the newsroom channel.

See you all with your first drafts here!

Accepted into GSoC 2026: From First PR to Official Selection

Ananya — Thu, 30 Apr 2026 18:17:01 +0000

If some had told me in my first year of university that I would be writing this post, I wouldn't have believed.

Today, I finally achieved a dream I have held onto for years: I’ve officially cracked Google Summer of Code 2026! with @owasp_foundation under OWASP BLT✨ It might seem like just another program to some, but for me, this is a dream coming true-a journey of collecting broken pieces, holding them together, and building something completely new.

🍂 The Beginning

Coming from a computer science background in high school to an unexpected core engineering major in university was a drastic shift. My first year was spent just trying to heal my lost confidence and survive the transition. I heard about GSoC back then, but since I wasn't involved in the tech community, it felt like a distant, impossible mountain.

The real struggle hit in my second year. The syllabus was exhausting. By the time my second year rolled around, I started peeking outside my core curriculum. I heard whispers of hackathons, open-source contributions, and got more involved in exploring this "famous" program called GSoC. I made my first attempt at GSoC by looking into organizations. I failed. I didn't have the knowledge of any tech stack, Git, or the skills to write those hundreds of lines of codes.

☕ The Turning Point

That failure was my wake-up call. During the summer break, I made a choice. I grounded myself, cut out the outside world, and sat at my desk for three months straight. I began participating in hackathons, doing LeetCode, and my open-source journey truly took off with GirlScript Summer of Code (GSSoC) 2025. That experience gave me the momentum and belief I needed to aim higher.

💻 The GSoC Grind

In October, I changed my strategy, dug through past archives, and found an organization that perfectly matched my new skills: OWASP BLT.

The struggle didn't end there. For the first few months, I had to work incredibly hard just to understand how a single line of code contributed to the final service on their homepage. But I stayed consistent. I opened my first PR, fixed bugs, and slowly became a constant contributor from October all the way through March, balancing my contributions with my core curriculum.

🤍 The Gratitude

This win is not mine alone. It belongs to the incredible people who believed in me:

To my Father and Mother: You are my strength. Your faith in me when I had none is why I am here.
My Circle: To the few friends who stood by me and fueled this journey.

I met incredible people in this organization. To our Lead Project Maintainer, @donnieblt : Thank you. Every single step I have taken in this organization was only possible because of your support. If you hadn't been there, I wouldn't have reached this level of excellence.

I am endlessly humbled and grateful to every energy out there that helped make this dream a reality.

Here is to new beginnings. 🥂

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.

🎉First PR? Get paid for it

Ananya — Wed, 01 Apr 2026 18:55:05 +0000

Introducing Dollar Deletions — a special campaign only for first-time contributors.

We know large codebases can be intimidating, so we are paying you $1 for your first accepted Pull Request where you safely delete unused or legacy code.

👉 Why are we doing this?

We are preparing for a major migration! To do this safely, we need to thoroughly clear out the existing repository. Your deletions will help us sweep away all the old files so we can seamlessly move our brand-new system into the clean repo.

🧹 Clean up real production code
🧠 Learn how large codebases work
🚀 Make your first open-source contribution
💵 Earn your first dollar online

How it works

Find dead or unnecessary code in our repository.
Submit your first-ever PR to remove it.
Pass the code review (your changes must not break existing functionality).
Get $1 via GitHub Sponsors!

📌 The Rules

This campaign is only for first-time contributors to this repo.
Your PR must include a clear explanation of what you removed and why.
The code must remain fully functional after your deletion.
Limited to one reward per contributor.

🏆 Bonus: Referral Leaderboard!

Spread the word and climb the ranks! You can refer others to this initiative. Just have the PR mentioning that you are referring a contributor as @user1 refers @user2 and link that PR to our mega issue. This will track the mention and boost @user1's rank on our referral leaderboard.

💡Not sure where to start? Look for issues labeled good-first-deletion to get your bearings.

👉Start here: OWASP-BLT/BLT

Your first PR shouldn’t be scary—it should be rewarding. We can't wait to review your code!

A Beginner’s Guide to Open Source Contributions (From My Journey and Mistakes)

Jayant Malvi — Tue, 31 Mar 2026 21:02:24 +0000

Hello everyone, I am Jayant Malvi. I am currently in 2nd year of my B.tech Computer Science in IIT Madras.

So my journey started way before I actually started contributing. I was really intrigued by the open source world and always wanted to contribute to organizations where my work is actually used by real people.

My first mistake was that I was just looking at how to start contributing—how to do GSoC and all that. I checked various GitHub repos, looked at good-first-issues, and always thought, “nah, I don’t know this, I won’t be able to contribute.” This was in my first year of college. Around the same time, I was also reading a lot about cybersecurity—networking, vulnerabilities, etc.

Then in my second year, one day in September, I explored OWASP projects and got introduced to OWASP-BLT. The idea of turning bug hunting and vulnerability findings into a gamified environment—with bounties, bacon—really caught my eye. That day I joined the Slack channel and messaged the maintainer, Donnie, about how I wanted to contribute. Donnie, being a great mentor, replied and helped me get started. That was the all the head start I needed.

I jumped into the codebase and started looking at pending PRs. My goal was simple: understand how the codebase works and how PRs are actually done. While setting up the project, I noticed tests were failing. I had no idea what those tests meant at first, but after digging into the codebase, I found there were two identical names causing the issue. I discussed it in Slack and raised a PR.

That’s when I realized—we really overcomplicate open source contributions. It’s honestly just about having the will to contribute and enjoying the process. From that day onwards, I caught momentum and never stopped.

The biggest advice I can give (it sounds simple, but it works): stop thinking so much and just jump into the codebase. At the start, you’ll feel like you don’t understand anything, but trust me—there will be a point where it just clicks, and after that it almost becomes addictive.

Another important thing: being involved in discussions. One of my mistakes was being too hesitant to talk or ask questions. I thought people might think I’m dumb or not professional. That mindset held me back for a while. What I later realized is—no one thinks like that. Everyone is learning. You should ask questions freely. The kind of knowledge you get from peers in these communities is something you won’t easily get elsewhere.

I also really liked how our maintainer, Donnie, introduced initiatives like requiring peer reviews for PRs. We have a strong peer network in BLT where everyone helps each other. A big part of my journey was reviewing PRs—this helped me understand the project better and learn about common mistakes like N+1 queries, deduplication issues, etc. I’d strongly recommend reviewing PRs—it helps others and sharpens your own understanding.

One of the major things I worked on was BLT-Zero. It’s a core part of OWASP-BLT where anyone can send vulnerabilities report to target organizations through a zero-trust workflow—no plaintext storage, mail with encrypted zips, hashes for decryption. This project is really close to me. I started working on it in November, it grew into a community project(in BLT-Zero repository, feel free to join us), and now we’re really close to sending the first vulnerability mail. I’m genuinely excited about that.

There are also many other community projects like BLT-Leaf, BLT-SafeCloak, and more across different domains ,you can contribute to domains that interests you and learn a lot. We’ve also started an initiative for new contributors to help reduce technical debt by making deletion PRs. It’s a great way to get started and understand the project better.

Today the GSoC proposal deadline ended. What I really liked is how my perspective has changed. Around 6 months ago, GSoC felt like just a program to get into. But now, it felt like I’m actually building my own project from scratch and trying to make it as good as possible in the organization which is really close to me. The time I spent researching and writing my proposal was quite a lot, but I enjoyed the whole process more than I expected.

Looking back, I’ve really enjoyed these last 6 months of contributing. I just wish I had joined in the fun earlier. The peer group I found here is one of the most supportive I’ve seen. I’ll keep contributing and see BLT grow into one of the biggest security projects out there.

And finally, a special thanks to our maintainer, Donnie for the constant guidance and for helping me grow as a contributor. The discussions we had around new ideas and improvements—and the way you always encouraged them—were easily the best part.

If you’re someone thinking about starting open source—just start. That’s it. You are always welcome at OWASP-BLT.