DEV Community: OWASP BLT

My GSoC journey with OWASP BLT

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

The journey of GSoC has come to an end. Time flew by. It feels like I was accepted only yesterday, and now it is already time to write my final report.

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.

Designing the Face of OWASP BLT: Three New Creative Challenges 🎨✨

Ananya — Fri, 20 Mar 2026 15:33:34 +0000

If you’ve been following our journey, you know that OWASP BLT is evolving. We’re streamlining our mission and modularizing our code, but a project is only as strong as its identity. We want the "front door" of our project to reflect the innovation happening behind the scenes.

We are officially inviting the creative community to help us redefine our look and community interaction through these design contests:

1. The Video Meme Contest 🎬

Who says security has to be serious all the time? We’re looking for the most creative, relatable, or just plain hilarious video memes that capture the "bug hunting" struggle or the spirit of the OWASP community.

Prize: $10
Deadline: April 15, 2026

👉 View Video Meme Contest Details

2. The Logo Design Contest 🕵️

The OWASP BLT logo is more than just an icon; it’s a symbol of security and community accountability. We’re looking for a fresh, modern take on our visual identity. Whether you’re a minimalist or a fan of bold, "hacker-y" aesthetics, we want to see your vision.

Prize: $25
Deadline: April 15, 2026

👉 View Logo Contest Details

3. The Homepage Redesign Contest 💻

We want our landing page to be as intuitive and high-performance as the tools we build. This is a challenge for the UI/UX enthusiasts—how would you structure the first experience a researcher or contributor has with BLT? Show us your layouts, your transitions, and your vision for a better user experience.

Prize: $25
Deadline: April 15, 2026

👉 View Homepage Contest Details

Why get involved?

Open source isn’t a gated club for "genius coders." It’s a space for anyone who wants to build something that matters. By participating in these contests, you’re not just submitting a file; you’re interacting with the OWASP BLT repository, getting your name on the contributor list, and helping us shape the future of the project.

Start small, design bold, and let’s see what you can create.

The Great OWASP BLT Cleanup: Delete a File, Join Open Source

Donnie Brown — Mon, 16 Mar 2026 23:16:25 +0000

The OWASP BLT project is entering a new phase.

Over time, the main repository grew into a large monolith containing many different components. To make the project easier to maintain and contribute to, we’re migrating from a single repository into multiple focused repositories.

During this transition, we’ve paused new additions to the main repo while we move components into their own homes.

But instead of doing the cleanup alone, we decided to turn it into a community challenge.

🧹 The Great OWASP BLT Cleanup

Want to contribute to open source in the easiest possible way?

Delete a file.

Each contributor can submit one pull request that removes a single file from the repository. That’s it.

As components move to their new repositories, the community will help gradually bring the original repo down to zero files.

Think of it like a collaborative game where every PR moves the project one step closer to its next chapter.

Why We’re Doing This

This campaign helps us:

Trim down the original repository during the migration
Give first-time contributors an easy entry point to open source
Teach the basics of forking, branching, and pull requests
Create a fun community moment around the transition

Once the repository is empty, we’ll replace it with a lightweight version that reflects the project’s new structure.

The Rules

To keep things fair:

🗑 One file deleted per contributor
🔁 No multiple deletion PRs from the same person
🧩 Only one file per pull request
🌱 Contributors are encouraged to join the new repositories afterward

This ensures more people can participate.

Perfect for First-Time Contributors

If you’ve ever wanted to contribute to open source but didn’t know where to start, this is a great opportunity.

You’ll learn how to:

Fork a repository
Create a branch
Commit a change
Open a pull request

All with almost zero technical complexity.

Want to Do More?

After submitting your deletion PR, feel free to jump into the new BLT repositories and contribute real features, fixes, or improvements.

This campaign is just the first step into the community.

Let’s Clean It Up Together

Every deleted file means:

one step closer to the new architecture
one new contributor joining the project
one small win for open source collaboration

Find a file. Delete it. Submit your PR. 🚀

Welcome to the cleanup crew.

OWASP BLT Github Repo