2026 Focus / Core Feature Ideas & Direction (Open for Feedback)

[DonnieBLT]

Discussion: Core Feature Ideas & Direction (Open for Feedback)

This document summarizes an early concept for refining BLT. Nothing here is final — all ideas, assumptions, and directions are open for discussion, critique, and improvement.

---

1. High-Level Vision

• A service focused on identifying and helping fix unpatched vulnerabilities
• Emphasis on practical remediation, not vulnerability hype
• Community-driven, educational, and focused on giving back to open source

Key questions:

• Is this problem worth solving in this way?
• Who benefits most from this approach?
• What should not be in scope?

---

2. Vulnerability Discovery (Concept Stage)

• Use Buttercup or similar scanning methodologies to detect unpatched CVEs

• Automated or semi-automated email alerts for scan results

• Notifications sent to appropriate project contacts (maintainers, owners, or designated security contacts)

• Potentially submit pull requests with fixes

  • Must respect each project’s contribution and disclosure guidelines

• Explicitly not a tool for security researchers

• Positioned as a separate service focused on:

  • Detection
  • Responsible disclosure
  • Remediation support

Discussion points:

• Should fixes be automated, human-reviewed, or hybrid?
• Is email the right notification mechanism?
• At what point does scanning become intrusive?
• Who is the ideal user or beneficiary?
• How do we prevent misuse or overlap with existing tools?

---

3. Internet-Wide Bug Discovery (Exploratory)

• UI/UX bug discovery and reporting at scale
• Focus on low-hanging fruit with high remediation value

Discussion points:

• Is UI/UX bug discovery a distraction or a complementary strength?
• Should this remain separate from security vulnerabilities?
• How do we define and scope “low-hanging fruit”?

---

4. Incentivizing Fixes (Early Idea)

• Incentivize vulnerability patching through:

  • A revamped incentive model (e.g., BACON-style rewards)
  • Rewards specifically for security-related pull requests

Discussion points:

• Are incentives necessary or potentially harmful?
• What types of incentives actually drive quality fixes?
• How do we avoid gaming or low-quality contributions?

---

5. Education & Contributor Growth

• blt-university / blt-education

  • Possibly a separate repository
  • Or higher-level, OWASP-aligned training

• Goal: grow contributors who can confidently identify and fix issues

Discussion points:

• Should education live inside or outside the core project?
• What skill level should this target?
• How do we measure learning impact?

---

6. Knowledge Sharing & Community Impact

• Focus on surfacing:

  • Patterns
  • Common challenges
  • Learning opportunities

• Avoid publishing raw vulnerability details

• Strong emphasis on:

  • Community sharing
  • Giving back to open source

Discussion points:

• What’s the right balance between transparency and safety?
• How should learnings be shared (blogs, reports, dashboards)?
• Who owns and maintains this knowledge?

---

7. Open Questions

• What feels most compelling?
• What feels risky or unrealistic?
• What should be removed entirely?
• What’s missing?

---

🔹 Original Concept (Unedited Reference from @kittenbytes)

Core Features

• Three main pillars

• Vulnerability Discovery

  • Utilize Buttercup or other scanning methodologies to find unpatched CVEs

  • Email service to alert of scanning

  • Report unpatched CVEs via email

    • Open Source Oliver
    • Founder Frank

  • Provide fix as a PR to project?

    • Would need to consider contribution guidelines for each project

  • Not a tool for security researchers

    • Totally separate service

• UI/UX Bug Discovery & Reporting

  • Internet-wide
  • Ideally focused on low-hanging fruit

• Incentivize Vulnerability Patching

  • Utilize a proposal to revamp BACON incentives
  • Rewards specifically for security-related PRs

• Education & Contributor Growth

  • blt-university / blt-education

    • Separate repo or
    • Higher-level OWASP training to help grow contributors

• Knowledge Sharing & Community Impact

  • Surface patterns, challenges, and learning opportunities
  • Avoid publishing raw vulnerabilities
  • Community sharing / giving back

---

💬 All feedback welcome — technical, philosophical, critical, or exploratory.
This is intentionally early-stage and meant to evolve through discussion.

[kittenbytes]

For context, here are the persona descriptions:

Aspiring Alex:
Bio: Alex Rivera is a 24-year-old aspiring cybersecurity professional who loves solving puzzles, finding vulnerabilities, and contributing to open-source projects. They use BLT to sharpen their skills, gain real-world experience, earn rewards, and build a reputable presence in the security community.
Quote: “BLT is the first platform where I feel like I can actually learn, compete, and earn rewards — without needing to be an elite hacker. It’s fun, challenging, and helps me build real experience.”

Founder Frank:
Bio: Frank Patel is a 29-year-old first-time entrepreneur who recently launched an early-version web app for his startup. He’s operating on a tight budget and needs affordable QA testing, basic vulnerability reporting, and actionable user feedback to improve his product. Frank isn’t a cybersecurity expert — he just wants to make sure his site is stable, functional, and safe before investing heavily in marketing or growth.
BLT appeals to Frank because it offers a cost-effective way to get real testers, real bug reports, and real insights without the complexity or price tag of enterprise platforms.
Quote: “I just need real people to try my site, break things, and tell me what to fix — without spending thousands of dollars. BugHeist feels like QA, security, and user feedback all in one.”

Open Source Oliver:
Bio: Oliver Smith is a 45 year old maintainer of an open source project. His project doesn't have many contributors and keeping up with security fixes can sometimes be challenging. He needs to be made aware of vulnerabilities in his project, and could also use upskilled contributors with more security knowledge to help him more regularly.
Quote: "BLT helps alert me to issues while also helping to improve the FOSS ecosystem by upskilling contributors."

[kittenbytes]

Here's what we came up with for the Mission and Vision statements:

Vision (the future we want to achieve): A secure FOSS ecosystem, with few supply chain vulnerabilities and a highly-engaged cohort of FOSS Security Developers

Mission (how we can get there): to secure the FOSS ecosystem supply chain by assisting with CVE discovery and patching while incentivizing engineers to engage with FOSS and AppSec

Description statements: BLT is an OWASP-hosted, community-governed platform being refocused into a hybrid automated and human-driven discovery engine, designed to teach responsible security work while improving the Internet’s baseline security — with a clear open-core and fork-friendly future.

Building security-aware contributors is the most durable way to improve the FOSS ecosystem.

[DonnieBLT]

I think we can refine the vision a bit more well I would say maybe broaden the vision a bit more to be all websites not just open source although the open source ones will be easier to provide fixes for we still we also want to scan any close source

[sidd190]

The problem is definitely worth solving and the solution proposed here seems pretty adhesive and nice to me. A few things I can think of and am maybe a bit concerned about are -

• The fixes definitely need to be a hybrid of human - reviewed and automated at the least, since security tightening can't be fully and blindly be given to an agent to lead. And about the ideal user or benificiary, as Carla pointed out here, the persona descriptions are pretty varied, so we have to consider the point of distinction between what we scan, how much and how often and how the scanning priority algorithm is made since to scan such large volume with no bias is no simple task I feel. If it's supposed to be a deployable/installable crawler agent, then that's a different story and this issue is nothing much to be worried about.

• UI/UX bugs don't feel like they would suit the scope of the proposed direction we're taking, especially not if we're planning on incentivizing fixes. This has various reasons, like :
  - UI/UX fixes are one of the easiest ways to let contributors participate in the projects, and more than often, enough contributors generally quickly find such bugs and propose fixes for them.
  - Incentivizing these issues will make the project suffer quite a bit, though I imagine intencivizing these bugs and fixes are not really considered for incentivization by bacons.
  Hence I think we might want to keep these concerns seperated for now, the vulnerabilities reporting and potential fixes and contributor reviews and final nods seems a lot more value adding as compared to this for now.

• Incentivizing fixes seems like a good idea if done selectively with a well made incentive model automated to give out BACON style rewards. Incentives are good to help contributors motivate and sustain working on bigger issues/fixes and actual value addition. If we want to really keep it limited we might introduce a system where we're kind of giving out these badges/licenses to be able to do the incentive hunting based on previous contributions so only frequent quality contributions get what they deserve, hence keeping out the low quality contributions, those done for the sake of incentives purely. Maybe these badges can have some kind of ranking system which can be increased by gaining points, which might be gained by doing either contributions to fix vulnerabilities or otherwise contributing to forums/education part of it like Quora or something. This whole system might be able to fit together this big chunk of the system of contributions in code,education and knowledge sharing. I can elaborate a lot more on this but this is getting a bit too long, so I'll keep it to this much for now.

Overall, this does feel like a good plan since we'll be creating/reflecting the thing that our product is supposed to be solving and then directing the contributors/agents into an adhesive community to grow, help and learn while sharing the growth with others. Maybe the UI/UX bug hunter sounds like noise to me in this for now, and a few things like maybe a full on pipeline for issue prioritization for big orgs, a stab at the decentralized security sector through this autonomous bug scanning agent and such stuff feel missing.

This is all I could think of on the first few reads of the above ideas and direction. Looking forward to be a part of this! Happy to take up any of these points and elaborate or discuss more.

[e-esakman]

1. High level vision

I do think this problem is worth solving in this way. In fact, I feel this might actually help BLT get back to having a clear “core” again. Right now there are many features and it’s sometimes hard for new users to understand what BLT mainly stands for. If the core becomes security + remediation + learning, that gives a much clearer picture of what BLT is about.

• who benefits the most? I think mostly projects and founders who have limited or no budget for security. Small open-source projects or early startups usually don’t have proper AppSec setups, so getting alerts about vulnerabilities and even some guidance on how to fix them can be very helpful.

2. Vulnerability discovery

At high level, I think automation / AI based scanning is necessary here, because manually checking codebases at scale is not really practical. So scanners + AI helping to find dependency issues or known CVEs makes sense as the first step.

• About “potentially submitting PRs with fixes” this part feels a bit risky to me. Creating PRs automatically for security fixes could be misused, or could break things, or might not follow project contribution guidelines. Also disclosure needs to be handled carefully in security.
  Maybe a safer flow could be like how BLT already creates GitHub issues when someone reports a bug, but in a more security-aware way:
• automated detection
• create issue / advisory with remediation hints
  then human contributors or maintainers decide on PRs.
  So automation helps with detection and reporting, but fixing still stays human-reviewed.
  For notifications, email still feels like the standard and expected way for responsible disclosure, so I think email is okay, but maybe combined with GitHub security alerts or some opt-in dashboard for maintaine

3. UI/UX bug discovery

Personally UI/UX bug discovery feels like noise compared to the new security-focused direction, at least as a main pillar. UI bugs are easier to find and usually don’t need strong incentives, and contributors already report these naturally. That being said, sometimes frontend issues can also become security issues (like vulnerable frontend dependencies, auth flow mistakes, etc.). So maybe instead of general UI/UX bugs, the focus could be more on frontend-related security risks (like the recent- critical security in react components) , not visual or usability problems.

4. Incentivizing fixes

I agree with @sidd190 with this incentives help and good to help contributors motivation but my main concern is that before heavily incentivizing security fixes, we first need to make BACON / badges more credible and meaningful.
From a user’s POV, people who are capable of finding serious security issues can often earn good money elsewhere, so if incentives here are not trusted or valuable, they may not bother. At the same time, we also don’t want low-quality PRs just for rewards. Maybe incentives should depend on or we can categorize them based on their findings:

• severity of the issue
• trust level of the contributor
  For beginners who wish to learn about security flaws or have reported some basic vulnerabilites, we could have badges showing learning progress and skills make sense.

5. Education & contributor growth

I feel education is very important for this vision, but it might be better to keep it in a separate repo or platform, so the core product doesn’t get too heavy. Right now we already have some security labs, but they are mostly MCQ-type questions. I think we first need to clearly decide what kind of education we actually want to provide to contributors and what level of security knowledge we expect them to have.
By that I mean, what kinds of vulnerabilities or security concepts should a BLT contributor really understand in practice or a user should must know in real-world ?
For this, I feel education should be much more hands-on, for example:

• vulnerable code examples
• small code snippets where users identify what kind of security flaw is present
• explaining different types of vulnerabilities with real code, not just theory

And maybe the best learning source could be BLT itself —

if vulnerabilities are found during scanning of repos, those patterns (without exposing sensitive details) can be turned into learning material. So people who don’t understand what a certain vulnerability means can learn about it through education modules based on real findings.
This way education is directly connected to what BLT is actually discovering and fixing, instead of being generic cybersecurity content.

6. Knowledge sharing & community impact

For patterns and trends, dashboards feel more useful than blogs. Blogs can explain BLT features, contributor stories, or learning resources, but for vulnerability patterns and common issues, dashboards or reports feel more appropriate and safer.

[e-esakman]

Open ended questions :-

1. What feels risky?
   Having so many goals to work upon feels risky, with all these things , building trust for both users and founders like Frank may become over-complicated. But I do agree we need to sort this out , so we can present a single goal and have people use BLT for scanning an everything.
   Also, If users receive too many alerts without clear priority, they may not know what actually matters and may start ignoring them.

2. What should be removed entirely?
   Anything that does not directly support:

• discovering vulnerabilities
• fixing vulnerabilities
• growing capable contributors
  could be removed.

some features that I noticed in blt which could be removed (based on the need, i just found some features which is repititive or does not align with blt)

• https://owaspblt.org/map/ (rn, it serves no purpose & its broken)
• job dashboard ( demand of workers keep on changing i mean the deadline for apply and things like that , so we create different repos for this , it would require constant maintaining)
• we have one staking , bidding , we can either merge or have only one.
• we have reporting bug-issues, and issue , pr-submit, issue-prompt
  ( either we merge or provide clear description)

3. What's missing?
   missing is clarity around governance and consent:

• what kind of project should be scanned?
• how projects opt in to scanning
• how disclosures are handled
• who decides what type of fixes should be proposed or sent to the maintainer of the project.
• what type of vulnerabilities matter most.
• what projects should get the attention first or most.

[Mysterio-17]

Really appreciate this breakdown — it does a great job of grounding the vision back into something practical and understandable 👍

A few things really resonated with me:

• I strongly agree that security + remediation + learning as the core helps BLT regain clarity. That framing alone already makes the project easier to explain to new contributors and founders.
• Your suggestion of keeping automation focused on detection and reporting, while leaving fixes and PRs human-reviewed, feels like the safest and most trust-preserving path forward. Especially in security, that human checkpoint seems non-negotiable.
• On UI/UX bugs, I’m on the same page — treating frontend-related security risks as in-scope, while avoiding generic UI issues, feels like a good middle ground that avoids noise without ignoring real risk.

I also really like the idea of education being derived from BLT’s own discoveries. Turning anonymized vulnerability patterns into hands-on learning material feels much more valuable than generic content, and it tightly couples education with BLT’s actual impact.

One question I’m curious about your thoughts on:
Do you see education as something contributors naturally grow into through fixing issues, or should BLT explicitly guide contributors along a path (e.g., beginner → intermediate → trusted fixer)?
It feels like this decision could strongly shape how incentives, verification, and trust evolve over time.

Overall, this feels like a very grounded take that balances ambition with realism. Thanks for laying it out so clearly — I’d love to hear how you’d prioritize these pieces if BLT had to roll them out incrementally.

[e-esakman]

I personally feel that learning by doing is the most natural and effective way contributors grow. When someone starts fixing real issues, they automatically begin to understand the codebase, the product, and the kinds of problems that actually matter. In that sense, contributors can learn on the go and side by side with real contributions, based on the types of issues they choose to work on.

About explicit guidance on BLT, most people who come are already contributors, but they may have very different levels of security knowledge, and some might know little or nothing about security. Whether we should guide them more strongly really depends on the direction BLT wants to take, and whether contributors are expected to learn security as part of contributing, or whether security knowledge is assumed.
If BLT becomes fully security-focused, another option could be to introduce some light prerequisites before contributors work on sensitive security issues for eg, small learning or practice tasks that help ensure basic understanding of common vulnerability types. This wouldn’t block people from contributing entirely, but it could act as a safety layer before allowing access to higher-impact security-related work :)

[Pritz395]

High-level Direction

The overall direction is solid but we might be overlooking certain aspects and underlooking in another. I'll be breaking down my understanding of these ideas and approaches as we go.

So the direction of folding BLT for what it was always meant to be, by focusing majorly on identifying security based issues → providing solutions for the issues → gamifying the entire process - feels RIGHT!! This 3-step process in and of itself is 1/2 part of the ENTIRE execution plan.

Now, further breaking down the said "3-step process":

Vulnerability Discovery (Buttercup)

• Using Buttercup to scan unpatched CVEs sounds good but why are we using email specifically for reporting? I think it should be plausible to create and use high-priority alerting workflows for automated tools like Buttercup, routing alerts to the right people or channels in GitHub itself.
• In order to build recognition for genuine contributors, if guidelines permit, submitting PRs after having them reviewed by multiple contributors/maintainers - approvals from fellow contributors/reviewers/maintainers etc. - would be more preferable since genuine security-related work would then actually be recognized without risking artificial inflation of PRs. This in-turn should justify project maintainers and security-minded contributors who can remediate and actually further prevent the platform from vulnerability "finders" seeking disclosure credit.

So how often would we run Buttercup scans without it burning ourselves out?

• Boundarising the process of scanning by setting appropriate rate-limits (e.g., weekly, bi-weekly scanning) or/and having an exclusive allow-list should help this from becoming overly intrusive.
• (I dropped my opinion towards the end in detail regarding misuse/overlap towards the end of this comment 🙂 ).

Incentivising Fixes (Anti-gaming)
So now that we're done with finding security-work and working on it, how do we encourage contributors to keep pushing their limits?

• I do think incentivising security-work is one of the 3 more important things as discussed above. The two major issues are distinguishing code fix vs. documentation-only/trivial PRs reliably and judging code quality/substantiveness. Hence by using multi-layer controls: NVD validation, duplicate detection, merge-after-publish check, per-user monthly caps (e.g., 5 verified CVE claims), diff heuristics to flag doc-only PRs, mandatory maintainer verification before rewards, and reputation weighting over time...should help prevent false/unjustified claims.

Leaderboards, Recognition, and Mentorship

• So ideally we will need some sort of a leaderboard or ranking to maintain active support and boost engagement within the community to prevent burnout, frustration and resentment. This ranking IN-TURN opens doors for education. I.e., contributors with a higher-ranking may choose to guide and help newer/lower ranked contributors with their security-work hence both sides of the rope get benefitted. More work within the community → higher rank → more guidance/support → easier to navigate.

Education (blt-education, Self-paced)
Now moving on to the other 2/2 part of the execution goal as declared above...
Other than guidance through contributor-to-contributor engagement, how else could we push education more enthusiastically?

• The blt-education repo as a whole sounds solid (separate duties)...since there isn't much detail regarding this, I was thinking that we could push active education based on each contributor's current standpoint...so it would kinda be like a self-paced course we're studying in blt-education while completing our assignments i.e., security PRs.
• For assignments, it would look something like: Beginner → intermediate path with hands-on tracks: read CVE + reproduce + patch + PR etiquette + verification..and as of measuring progress we'd follow something like pre/post micro-quizzes, time-to-first verified fix, verified-to-rejected ratio, challenge completions, and mentor feedback sampling.

Also, something that I was thinking of at the top of my head...contributors of a specific rank and above on the leaderboard could join as teachers for beginners within the blt-education repo. This again leads us back to the goal of incentivising the entire 1/3 part of this year's goal and actually ensuring that the ranking is an accurate display of an individual's involvement within BLT community.

Knowledge Sharing (Safe and Useful)

• I'd toss knowledge sharing within the 2/2 part of the execution plan as it falls under education. Just a passing thought as of now, we could include a page/section in BLT website, kind of like a StackOverflow forum/blog where everyone is open to share their learnings while being cautious regarding sharing patterns and aggregate metrics; never publishing raw vuln details or unverified claims and delaying specifics until fixes are merged. As a bonus, we could generate internal bi-weekly/monthly reports of our own learnings/findings/interests which would need to be verified by trusted sources first, of course.

UI/UX Frontend Bug Reporting

• The UI/UX frontend bug reporting as stated by other contributors as well, seems like a stretch for now at least. It would be better to first focus on the 2 goals as stated above and then branch out and develop a separate tool to chaos engineer a website and pluck out low-hanging fruit. I think this should be prioritised lower for now, at least up until we have the highest-priority 3 goals up & running - that is CVE fetching, fixing and validating the work ethic...I will need to go through this doc a couple more times to come up with a good approach for this later on.

Additional clarifications I want to make explicit (to avoid gaps)

• Post-disclosure scope: Track and reward only post-disclosure CVE work (respecting responsible disclosure).
• Verification gate: No rewards until a maintainer/verifier approves the contribution (the multi-layer checks above feed into this).
• Data boundaries: Store only what's needed for recognition and analytics (CVE ID, CVSS/severity, public PR URL, contributor handle, timestamps); no raw exploit details.
• Monthly caps: Default cap (e.g., 5 verified CVE claims per contributor per month), with the ability to raise it for trusted contributors.
• Unregistered orgs: Webhook-based tracking first; a small, curated GitHub Search polling mode could be a stretch option to surface candidates from public repos.
• Reward weights: Severity-weighted BACON (e.g., Critical > High > Medium > Low); optionally a small "Buttercup bonus" when a PR closes a Buttercup-surfaced opportunity.

Questions I'd like ALL OF YOU to weigh in on:

• Rewards gating: Start with human-gated rewards after automated pre-screening (recommended), or aim for more automation up front?
• Reward weights: Are severity-weighted BACON amounts acceptable (e.g., Critical 100, High 75, Medium 50, Low 25)? Should Buttercup-sourced fixes get a small bonus?
• Unregistered orgs: Keep scope webhook-only for now, or include a minimal curated Search polling pass as a stretch?
• Data boundaries & retention: Is "CVE ID + CVSS + public PR URL + handle + timestamps" the right minimum? Any retention/redaction policy?
• Governance: Who can verify (use the existing verifier role)? Keep the default monthly cap of 5 verified CVE claims per contributor, with overrides? How to handle disputes/appeals?
• Deployment shape: Monorepo app inside BLT vs a standalone service? Any expectations to host read-only dashboards on Cloudflare while keeping verification/rewards in Django?
• Background jobs: Prefer current cron/management-command style, or standardize on a queue (Celery/RQ) for NVD lookups and de-dup?
• Education & challenges: Should challenges reference "opportunities" (e.g., "Close 3 open opportunities this month") and severity thresholds (e.g., "Fix a Medium+ CVE")? Any planned linkages to blt-education (e.g., course-gated badges)?

[Pritz395]

I think overall, whether it's fetching CVEs, solving them, or even rewarding them -we'd need extensive multi-step human verification in the initial stages at least, and then transition to a hybrid approach in later stages by keeping the heavier work subject to maintainer approval. The same applies to the education and knowledge sharing department as well, since we'd be leaving room for plenty of mishaps unless an authenticated individual approves the content being pushed. So basically, human verification in the early stages is imperative.

Please let me know what you guys think!

[e-esakman]

I really liked this point here

1) Burning out

this point can be easily missed and worth thinking about, because Owasp is a npo and we cant ignore financial burdens to run them. AI tools, dashboards, etc. will take money and maintenance, so I agree that we should have clear boundaries like how often scans run and where we focus first, otherwise this can become overwhelming very quickly.

> Beginner → intermediate path with hands-on tracks: read CVE + reproduce + patch + PR etiquette + verification..

One concern I have is around making CVE-level remediation the main learning and contribution path
Let a contributor read about it, but fixing CVEs is still not an easy task, even for intermediate contributors. It often requires understanding why the vulnerability exists, how dependencies work, how to safely upgrade or patch without breaking things, and sometimes dealing with unfamiliar codebases. But most contributors who come to BLT right now are students or general developers, and many of them don’t have much security background yet. So if BLT becomes very CVE-focused, I feel like a large part of the community may struggle to participate or learn effectively, at least in the beginning.
Another point I’m unsure about is where these CVE fixes will mainly happen. BLT itself will not have many real CVEs to fix, so contributors will likely be working across many external repositories. That means beginners will also need to understand different project setups, contribution guidelines, and codebases, which makes the learning curve even steeper.

Contributors can learn side by side while fixing things, based on the type of issues they pick up maybe starting with general bugs, dependency updates, or basic security misconfigurations, and then slowly moving toward more serious vulnerability fixes. (not ui/ux obviously, until they find something like the recent ~ security vulnerability in react components or any issues like that). Over time they naturally grow and can handle more complex security work.

I do agree that we need some kind of filtering or trust system, especially if people are working on sensitive security-related issues. A contribution ladder could help here like beginner → intermediate → trusted contributor - so people don’t jump directly into risky areas, but also don’t get blocked from contributing and learning. I’ve seen similar ladders in other orgs and I think something like that could work well for BLT too.

Now for the questions:

1) Whether rewards be automated or human-reviewed?

For that, we first of all need to decide or categories the kind of rewards we're. giving. If it's monetary ~ it should be human - verified and then let bots / tools to award. If its some basic tasks or some basic security found , we should be awarding with bacon/badges and it should be automated. Because , it's not easy to go through everything and award people manually( the way we have bacon , and badges thing, it should be like that or similar ).

2. Reward weights?

Since BACON is token-based, we also need to be careful about not minting or distributing it too aggressively, otherwise it can get exhausted or lose meaning. At the same time, if we want people to take BACON seriously, we also need to increase its real usefulness and visibility, so that contributors feel it has value beyond just being a badge. Otherwise, even high rewards won’t feel motivating.

3. Unregistered orgs, webhook only or search polling?

I think we should start with webhook-only and registered organizations. That way we are only scanning places where maintainers have explicitly opted in, which feels safer and more respectful.
Scanning random public repos using GitHub search could bring a lot of noise, false positives, and also increase cost and maintenance. Maybe it can be explored later as an experiment, but for the start I feel webhook-only is better and more controlled.

4. I think keeping only CVE ID, severity, public PR link, contributor handle, and timestamps feels like the right minimum. We should avoid storing exploit details, reproduction steps, or any internal project info, because that can be risky and unnecessary.

For retention, maybe we keep detailed data only while verification and rewards are active, and later keep only aggregated stats for dashboards and reports. That feels safer and also respects privacy.

5. About the monthly cap, I want to point out that even 1–2 verified CVE fixes per month is already very serious and difficult work, especially for students and part-time contributors. CVE remediation is not trivial and usually requires deep understanding of the code and dependencies, the number should not create pressure to rush security fixes or treat them like quick tasks.

6.,7 this should be discussed under Donnie sir.

8. Education

Like I mentioned earlier, CVE is not a good metrics, it could be spoting vulnerabilites and fixing them based on its severity.
"challenges reference "opportunities" (e.g., "Close 3 open opportunities this month")" i dont think, it's a good idea. I mean, what kind of prs it should be, we need to specify that? Also , if focus is more on security then we need to specify based on that. But if we consider at blt as just being an open-source security org (allowing users to raise any kind of prs) they could raise the ux fixes, code fixes so it depends.

[arnavkirti]

My thoughts on “Incentivizing fixes”

Really like the direction of a revamped BACON-style model focused on security-related PRs, and wanted to share a few thoughts on the three discussion questions.

1. Are incentives necessary or potentially harmful?
   From what I’ve seen in open source, incentives are a strong lever to:

   • Keep existing contributors engaged on harder, less “glamorous” work like patching CVEs.
   • Attract new contributors who are curious about security but need a concrete on‑ramp plus some external motivation.
     The risk arises when incentives create a volume game: numerous low-value PRs that increase the review burden for maintainers and dilute the signal for genuinely impactful work. So incentives feel necessary, but only if they are scoped and throttled carefully.

2. What types of incentives actually drive quality fixes?
   For most contributors, it feels like a mix of money, recognition, and healthy competition works best:

   • Targeted monetary rewards for high‑impact security PRs (e.g., fixing real unpatched CVEs, hardening auth flows, etc.), not generic typo/UI tweaks.
   • Public recognition: leaderboards, badges, or “security contributor” tiers attached to profiles, highlighting people who consistently ship meaningful fixes rather than one‑off drive‑by PRs.
   • Competitive elements (seasons, streaks, rankings) that reward sustained quality over time, not just one month of grind.
     This also aligns nicely with personas like Aspiring Alex (career signaling) and Open Source Oliver (reliable security‑aware contributors that he can trust).

3. How do we avoid gaming or low‑quality contributions?
   A few ideas that could pair well with BLT’s existing workflows:

   • Use GitHub Actions plus AI review (e.g., CodeRabbit, which BLT already leans on in PR workflows) as a first‑pass quality filter to flag trivially low‑effort changes, obviously noisy diffs, or PRs that don’t touch security‑relevant surfaces at all. Human maintainers still make the final call, but automation can reduce the review load.
   • Only mark a PR “incentive‑eligible” once it passes a combined check: tests, basic static analysis, and a short checklist about impact (e.g., “fixes a known CVE”, “removes a vulnerable dependency”, “adds meaningful hardening”).
   • Introduce a reputation / badge system:
     • Contributors gain points for merged, incentive‑eligible PRs and for non‑code contributions that support education and knowledge sharing (e.g., docs, educational writeups, blt‑university content).
     • Access to higher‑value incentives or more sensitive targets could be gated behind reputation thresholds, which discourages drive‑by gaming and rewards people who invest in the ecosystem long‑term.

Happy to expand on any of these, especially around how the automation + reputation layer could be designed so that maintainers keep control but aren’t overwhelmed by noise.

[mdkaifansari04]

1. High-level Vision

My thoughts: It seems good go me if we tried to distribute things as mentioned in the form, we might have achieved a great milestone.

Keys Questions thoughts:

Is this problem worth solving in this way?

> I think how the problem broken down in features and separate features and manageable services it wont be any challenge anymore.

Who benefits most from this approach?

> As the developer myself it would be quite easier to work in isolation on each issue in separate service and not stacking up each and every features in BLT core

What should not be in scope?

> So far the looking at each component and feature, it seems good, but if i was asked to split out less priority one. it would be educational section as we dont have much resources and regular article or video resources. We can focus on it but as we have a whole open internet with some useful resources like [freecodecamp](https://www.freecodecamp.org/), [medium](https://medium.com/) and more.

If we plan adding resources it should be more specific or OWASP / OWAPS-BLT. (more brief on project section).

2. Vulnerability Discovery

A decent yet complex but super useful feature, if build.

Pointer thoughts:

Should fixes be automated, human-reviewed, or hybrid?

> It would be great if it could be hybrid as both comes with some merits and demerits ?

• If we make this completely automated by bot / copilot/ coderabbit, it will save a lot if human effort working on fix, but it will harder for maintainer to becomes annoying if bot make continious unwanted changes.
• if made completely human reviewed and there is no point of using current tools, it might work in some cases if the issue is complex.
• best of both world would be making human reviewed (by adding peer review at-least one, the same concept we use in BLT) and yet using bot for reviewed.

Is email the right notification mechanism?

I think yes, but with the constraint, it should not be spamming maintainer inbox with frequent updates, it should be quite generous email sent one-time for each vulnerability with high priority, so it should not get ignored.

At what point does scanning become intrusive?

🔴 need more context in order to approach this

Who is the ideal user or beneficiary?

> definitely the open source maintainer, but also closed source projects who lack in management of unpatched CVEs.

How do we prevent misuse or overlap with existing tools?

> Simple by making the scope narrow, opt-in and focused.

3. Internet-Wide Bug Discovery

A good start point for early contributors.

Discussion points (thoughts):

Is UI/UX bug discovery a distraction or a complementary strength?

> It becomes distraction if not managed correctly by the maintainer, as the UI bugs are more easy pickup there is a huge changes of spam contribution, it order to maintain the principle every contributor should follow code of conduct and contribution guidelines. If managed correctly and efficiently definetly it would be a complementary strength.

Should this remain separate from security vulnerabilities?

> It depends on use case, we might add good-first labels on UI vulnerabilities, so it’s easier for contributor to filter out those. Making it separate service would be a rework for same functionality. (totally depends on end use case)

How do we define and scope “low-hanging fruit”?

> simply by adding labels and filters.

4. Incentivizing Fixes

Are incentives necessary or potentially harmful?

>both.

incentives can help people start fixing issues, but they become harmful if they push people to chase rewards instead of quality. (we can use bacon reward system, and similar to GSoC warm, up, the bacon reward should be tracked between the contribution phase, and top contributor would be appreciated with prizes / bounties).

note: only possible when maintained by human maintainer, otherwise it may lead to spam

What types of incentives actually drive quality fixes?

> incentives tied to accepted, reviewed, and merged fixes not just activity.

rewards should come after impact, not after effort.

How do we avoid gaming or low-quality contributions?

>only solution human review

5. Education & Contributor Growth

Pointers:

Should education live inside or outside the core project?

>The better way would be having education outside of the core project, and not just support resources related to BLT but entire OWASP community

• we could have a entire CMS platform ( having youtube video resources, organised in milestone fashion.
• bacon reward after course completion and AI test completion.
• ai test could be generated in Q/A fashion.
• automated certification program (how freecodecamp does)
• complete roadmap / contribution guideline for BLT and general open source.
• and much more could be added.

What skill level should this target?

> Basically beginner to intermediate, on BLT, general open source, resources link for tech

I think more about open source contribution, making their first contribution, setup of each project, as most beginner fails in it, maybe publishing article based on

“How to become an ideal contributors”

“Things to avoid while contribution”

“Maintain respect between contributors”

“Best practices of good contributors”

“What make a best pr”

A short article consists with example will definitely help early contributors. (As I faced these issues in my early contribution phase)

How do we measure learning impact?

> As mentioned in a gamified fashion as course / article completion

• an ai / manual test after test completion,
• a bacon reward system,
• personal dashboard for stats
• every day streak for attendance and learning

6. Knowledge Sharing & Community Impact

What’s the right balance between transparency and safety?

> Share learnings, patterns, and mistakes not raw vulnerability details.

I think BLT should focus on what we learned while fixing issues, not the exact exploit or sensitive data.

Things like common mistakes, recurring patterns, or why a fix worked are safe and useful.

How should learnings be shared (blogs, reports, dashboards)?

> short focused content that is easy to consume and easy to maintain.(mentioned in detail in above section)

Who owns and maintains this knowledge?

> The community, with maintainer guidance and approvement

NOTE: I tried to consised the answer in best and short way possible, I might have misunderstood any feature, would appreciate your comment on it.

(maybe contain any grammatical / spelling error please ignore).

Would appreciate to dive deeper into any above section, if I was asked to choose I would be happy taking over the entire Vulnerability Discovery and management.

[Nachiket-Roy]

I feel the strongest direction for BLT is to treat vulnerability discovery and bug reporting as the core product, with education and contributor growth built around it, rather than as parallel or loosely related features.
BLT can be the place where:

• vulnerabilities are discovered responsibly
• fixes are encouraged and reviewed
• contributors learn through real problems
• maintainers and founders get practical help without enterprise barriers

The vulnerability and bug logging flow should remain the primary focus. Strengthening how issues are surfaced, triaged, and followed through to remediation adds more long-term value than continuing to expand sideways into unrelated functionality.
Contributor effort here could be reflected on profiles; not as pure gamification, but as a way to show real, practical security work, similar to how developers showcase learning and problem-solving elsewhere.

Learning Through Helping Others

A major opportunity lies in enabling people who can’t afford enterprise-level audits to still receive meaningful security guidance.
This doesn’t need to be complex:

• a space where founders or maintainers can ask for clarification
• contributors help review configs, explain risks, or guide fixes
• learning happens naturally through real cases

Over time, this could resemble a security-focused discussion layer, similar in spirit to StackOverflow, but centered on remediation and responsible disclosure rather than abstract Q&A.
Any rewards or recognition here should stay secondary to learning and capped to avoid unhealthy competition.

Keeping Scope Clean and Focused

As BLT evolves, it may help to actively separate or remove non-core parts of the current repo such as jobs, adventure, banned apps or etc etc that don’t directly support:

• vulnerability discovery
• remediation
• contributor growth

Reducing this surface area would simplify onboarding, clarify BLT’s identity, and make it easier for new users to understand what the platform is primarily for.

Automation With Human Judgment

Automation and AI can help surface potential issues, but fixes should remain human-driven.
Rather than auto-applying changes at scale, it feels safer to:

• surface issues first
• create tickets or advisories
• allow contributors to opt in to working on them

This keeps trust with maintainers intact and avoids intrusive behavior.

Beginner-Friendly Entry Points

Not all issues need to be incentivized.
UI/UX or low-risk bugs can remain learning-focused entry points where new contributors gain confidence before moving into security-sensitive work. These serve as onboarding paths rather than core outcomes.

Opening BLT Beyond a Single Audience

BLT already attracts many contributors from GSoC, which is great.
At the same time, clearer onboarding, simpler scope, visible contributor profiles, and a discussion-driven learning space could make BLT more approachable for the general public, founders, maintainers, and independent contributors alike.

PS: Sorry if any of these points overlap with others; I read several comments earlier, so some ideas may have stayed in my head while writing this.

[codeXanu]

Hey @DonnieBLT , Thanks for sharing this early-stage vision — I really appreciate that this is being opened up for discussion before anything is finalized.

---

Opinion: Project Registration, Trust, and Issue Severity

From my perspective, maintainer consent is critical for the success of this platform.

If open-source organizations or projects are registered by anyone without maintainer involvement, it can easily lead to frustration. Even well-intentioned security reports may feel intrusive or overwhelming, especially if a large number of issues are raised without context or prioritization.

On the other hand, when maintainers register their own organization or project, they are opting into security checks and remediation support. In that case, suggested issues and fixes are far more likely to be welcomed and acted upon. This opt-in model builds trust and encourages real collaboration rather than resistance.

I believe the platform should strongly prefer:

• Maintainer-initiated registration for full scanning and issue creation
• Any non-maintainer discovery (if allowed at all) should be limited, responsible, and non-intrusive

Additionally, when security issues are raised, they must be clearly labeled by severity level (for example: low, medium, high, critical). Proper severity labeling helps maintainers:

• Understand the real risk
• Prioritize fixes effectively
• Avoid panic or alert fatigue from low-impact findings

Clear severity labels also improve communication and make security discussions more constructive and actionable for everyone involved.

---

Opinion on Vulnerability Discovery, Notification, and Fixing Approach

1. Automated Scanning & Issue Acknowledgement

In my opinion, once an automated tool completes a scan and identifies potential security issues, those findings should be:

• Acknowledged directly to the project maintainers
• Also raised as issues in the project (following contribution and disclosure guidelines)

At the same time, maintainers should always retain full control.
If a maintainer feels that a reported issue is not important or not applicable, they should be free to close or remove it without friction. This keeps the process collaborative rather than intrusive.

---

2. Fixes Should Be Human-Reviewed (Not Fully Automated)

I strongly believe that all fixes should be human-reviewed.
Most organizations and maintainers will not trust fully automated fixes, especially for security-related changes.

Automated tools are useful for detection, but:

• Fixes should be proposed by real contributors
• Reviewed by humans
• Clearly explained in PRs

This approach builds trust and avoids introducing risky or incorrect changes.

---

3. Notification Method (Email)

Email seems to be the clearest and most appropriate way to notify maintainers after scanning:

• It is direct
• It respects existing security contact workflows
• It avoids public noise or surprise issue floods

Emails should ideally summarize:

• What was found
• The severity level of the issue
• What actions (if any) are recommended

---

4. Severity Labeling for Better Communication

Every raised security issue should be clearly labeled with a severity level (for example: low, medium, high, critical).
This helps maintainers:

• Quickly understand risk
• Prioritize fixes
• Avoid unnecessary alarm from low-impact findings

Clear severity labeling improves trust and makes security discussions more actionable.

---

Overall, I think automated scanning combined with maintainer acknowledgement, human-reviewed fixes, clear severity labels, and respectful email notifications is a balanced and responsible way to help open-source projects improve their security.

---

Opinion on UI/UX Issues, Incentives, Education, and Knowledge Sharing

UI/UX Bug Discovery as an Entry Point (Not a Distraction)

I don’t see UI/UX bug discovery as a distraction from security.
Many contributors who join the platform may not be experienced enough to start directly with heavy security-related work. For them, frontend issues and small UI/UX fixes are often the best way to:

• Understand how the platform works
• Learn open-source contribution flow
• Build confidence before moving to more complex security issues

In practice, organizations also receive very valuable UI/UX suggestions. These should not be ignored.
Instead, such issues should be clearly labeled (e.g., UI/UX or Frontend) so maintainers can easily identify them and review them when they have time, without feeling pressured.

If the platform focuses only on security issues, it may become difficult for new contributors to enter and grow within the community.

---

Incentives and Rewards for Fixing Critical Security Issues

I believe rewarding contributors for fixing critical security issues is a positive idea when done carefully.

With:

• Clear contribution guidelines
• Transparent terms and conditions
• A strong code of conduct

contributors will stay focused on quality rather than quantity.

A healthy flow could be:

1. A contributor reports an issue
2. The maintainer reviews and accepts it
3. Only then does the contributor work on a fix
4. A reward is granted after the PR is successfully merged

This ensures:

• No wasted contributor effort
• No spam or low-quality PRs
• Rewards are tied to real impact

At the same time, it’s important to note that not all bugs or issues need to be rewarded.

---

Education & Contributor Growth (Right Time, Right Way)

Once the platform’s core functionality is clear and the community has active organizations to work with, education becomes very important.

At that stage, it would be valuable to teach new contributors:

• How BLT works
• How to start contributing safely
• How to move from simple issues to more advanced ones

This structured learning can help contributors smoothly enter the ecosystem and grow over time.

---

Knowledge Sharing Without Causing Harm

Knowledge sharing should focus on:

• Overall experiences
• Learnings
• Common patterns and challenges

It should not disclose sensitive project-specific security details.

A good approach could be sharing:

• Testimonials
• Learning summaries
• Platform-level insights

This keeps the community informed and motivated while protecting projects.
These formats and boundaries can be refined further as the platform evolves.

---

Apologies for the length of this comment — these are my genuine thoughts and concerns that I wanted to share clearly. I’d really appreciate your feedback on whether I’m thinking in the right direction here, or if I’m getting distracted from the core goals.

Thanks a lot!

[karunarapolu]

Most of the points have been addressed at this point, so here are my two cents.

High-Level Vision

I think the vision is pretty good. The problem is definitely worth solving in this way because many open-source projects struggle with keeping up with security vulnerabilities due to limited resources and contributors. A service focused on identifying and helping fix unpatched vulnerabilities fills a real gap in the ecosystem.

The people who benefit most from this approach are maintainers, since they are the ones who will receive direct help in identifying and fixing vulnerabilities in their projects. Maintainers of smaller open-source projects especially often lack the time, expertise, or contributor support to stay on top of security issues. This initiative could take some of that burden off their shoulders.
The emphasis on practical remediation rather than vulnerability hype is also a good direction.

Vulnerability Discovery

Automated fixes are appealing since manually reviewing all vulnerabilities would need a lot of human effort. However, fully automated solutions risk introducing errors.

There are tools which already discover vulnerabilities like Dependabot which automatically checks for outdated or vulnerable dependencies and opens PRs to update them or OWASP Dependency-Check scans projects to identify known vulnerable components. To differentiate, we could focus on broader CVE detection beyond just dependencies like provide more context around fixes. We have to think about other ways in which we could differ.

For email notifications, messages should clearly explain why the vulnerability is hazardous to encourage maintainers to take action. If maintainers do not understand the risk, they are more likely to ignore the email.

Internet-Wide Bug Discovery

I think focusing on UI/UX bugs feels out of scope and would be a distraction from the core mission.

Incentivizing Fixes

Incentivizing fixes is a good idea, especially for attracting contributors yet we cannot risk encouraging low-quality PRs submitted just for rewards. At the end, it is a demand supply problem: if there are more contributors and few issues, normal BACON and badge style rewards would be a good idea but if there are less contributors but many fixes, incentivizing more or amping up rewards like special one time badges or more BACON points might help. It is also a question of reputation as badges which provide value in user's careers might might incentivize them more.

As to low quality fixes, we can use AI to analyse the quality of a fix before rewarding and award higher quality fixes.

Badge and BACON-style incentives align well with open-source values and OWASP's mission, but may not be motivating enough for all contributors, which might lead to fewer people participating. Before revamping the model, I think we can survey the contributors to understand what non-monetary rewards they would actually want, then design the system based on that. This way, the incentive model is built on real feedback rather than assumptions.

Education & Contributor Growth

A separate repository for education is a good idea. While not core to identifying and fixing bugs, it provides a lot of value for growing the contributor base and improving the overall security awareness in the community.
The content could address multiple skill levels—similar to how Duolingo structures learning:
Beginners start with foundational modules
Intermediate contributors can skip ahead or continue from where beginners finish
This way, the education system does not alienate anyone based on their current skill level and provides a clear path for growth.
We should also use OWASP's existing resources like Juice Shop (a deliberately vulnerable app for learning) and the OWASP Top 10 (a list of the most critical web security risks) for teaching purposes. There is no need to reinvent the wheel when these well-established resources already exist.

Knowledge Sharing & Community Impact

The right balance between transparency and safety might be sharing fixes for common vulnerabilities while keeping less common or specific ones hidden until they are fixed. This way, the community can learn from patterns and common mistakes without exposing sensitive information that could be exploited.

Learnings can be shared through monthly or annual reports and dashboards. However, as others have pointed out, this needs heavy maintenance. Human-written reports build trust though, and having security professionals author or review these reports adds credibility.

Regarding ownership: knowledge maintenance could rotate among experienced security contributors on a yearly or monthly basis, based on availability. This prevents burnout and ensures fresh perspectives while keeping the knowledge base active and up to date.

I’d be happy to dive deeper into any of the sections above and expand on them, especially the incentives part, as I’m already working on the team badges feature and can evolve it based on the new direction.

[kittenbytes]

First, let me say thank you to everyone who has contributed! All of your input is really thoughtful and it means a lot that you've spent time reading and responding.

Vulnerability Detection and Scanning:

I want to be clear the vision is to have some scanning or vulnerability detection tooling that is outward facing. In other words - how might we support other OSS projects in detecting and patching their vulnerabilities?

Buttercup:

I wanted to provide a bit more context on Buttercup: Buttercup is a cyber reasoning tool that was developed as part of the AI Cyber Challenge hosted by DARPA (part of the US Gov). The company that created it won second place in the overall competition and decided to keep it open source and continue development with the community. Currently it runs on a k8s cluster you configure, and uses fuzzing and LLMs to scan a repo. It then identifies the issues (CWEs) and can run a patcher service to generate code fixes. It currently supports Java and C projects that are OSS-Fuzz compatible, and projects that build succesfully and have existing fuzzing harnesses.

Areas of Investigation for Buttercup

• What is the cost to running such a scanner? Do we have a budget?
• Is this scanning type (CWEs in repos) the right approach?
• Does having only Java and C compatibility limit our potential customer base too much?
• If Buttercup is not the right approach, what would be a better approach?

UI/UX:

What I read above is there is a general consensus that reporting of UI/UX bugs should be deprioritized, and should not factor much, if at all, into the BACON rewards.

Overall Project Vision:

I agree with @Nachiket-Roy

I feel the strongest direction for BLT is to treat vulnerability discovery and bug reporting as the core product, with education and contributor growth built around it, rather than as parallel or loosely related features.
BLT can be the place where:

• vulnerabilities are discovered responsibly
• fixes are encouraged and reviewed
• contributors learn through real problems
• maintainers and founders get practical help without enterprise barriers

Vulnerability fixes

I am seeing several comments that echo my own concern about how to provide the vulnerability information with enough detail to potential contributors (especially beginners) so they can make the fixes, without violating ethical disclosure. To me this is the biggest issue we need to solve.

Incentives and rewards

I agree we need to make BACON credible for it to be any kind of incentive. I also agree that we should only award PRs that actually fix something. My suggestion was to cross reference a users' github username with the commit URLs published in the NVD in order to award them BACON. The NVD record also shows the CVSS 4.0 severity rating which could be used to map to our weighted scale. An example page is: https://nvd.nist.gov/vuln/detail/CVE-2026-24130 - scroll down to "References to Advisories, Solutions, and Tools" to see the commit URL in the table. This would ensure BACON would only be awarded once the fix and CVE are published.

Project Cleanup

I agree with several folks who mentioned separating or removing non-core parts of the current repo. I am curious how much impact removing things like jobs, adventure, or banned apps would have on the main website? Are they heavily integrated, or is removing/separating them trivial?

Education

There have been some great ideas on how to build out an education program. It is definitely a lot of work and we should consider whether we want to host and run a CMS ourselves, host and run an LMS ourselves, and what resources we have to create labs and training materials. I love the idea of using real code problems to create learning tools, but I also know it is a LOT of work to develop and maintain good learning guides. In a previous work project my team created 120 wiki articles covering common scan findings and remediation steps, but our customers had a very tight scope of Java Spring Boot back ends with React front ends and we were able to speak very specifically to their tech stacks. I'm wondering if utilizing existing OWASP or other 3rd party learning might be a good starting point before committing to maintaining our own resource libraries?

[Jayant2908]

Most of the points have already been addressed well by others, so I’ll just share a quick gist of my overall view.

1. High-level vision
   I think it’s really important for BLT to have a clear, unified direction. The vulnerability scanning + logging capability should be the primary focus, with other features built either on top of it or in parallel. That keeps the project consistent and prevents BLT from becoming too broad too early.

2. Vulnerability discovery (Buttercup + scanning + notification)
   As @kittenbytes mentioned, Buttercup looks like a strong option for scanning methodologies, and it’s definitely worth evaluating seriously. For the review model, I’d prefer a hybrid approach—automation can assist, but we shouldn’t trust bots completely for fixes or assignments. Email notifications still feel like the best default right now, and I don’t see scanning as “intrusive” if it’s done responsibly and helps maintainers reduce risk.

That said, this is also the feature we need to be most careful about. I’m currently working on a Zero-Trust pipeline that keeps everything encrypted end-to-end and avoids storing sensitive data publicly or on the web. Even with that in place, we should treat this as high-risk to get wrong—so I think we need thorough testing, clear guardrails, and a gradual rollout before introducing it broadly to the community.

3. Internet-wide UI/UX bug discovery
   Personally, this feels like a distraction from BLT’s core value. UI/UX bugs are often easy to find and fix, and they don’t align strongly with the vulnerability-remediation focus. Keeping BLT centered on security outcomes will make the project more meaningful and differentiated.

4. Incentivizing fixes
   I agree with the general sentiment that incentives can be a good policy, but they need strict criteria. We should avoid rewarding very small or “easy win” PRs (especially UI/UX changes) just to prevent gaming. Incentives should target high-impact security remediation with clear quality signals and review standards.

5. Education & contributor growth
   I strongly support the education idea. A blt-education / blt-university track can help beginners learn security fundamentals and contribute confidently. It also builds a long-term contributor pipeline, which is valuable for sustainability and community impact.

6. Knowledge sharing & community impact
   I like the idea of sharing learnings, patterns, and common vulnerability types, but carefully. We could publish findings anonymously on blt-education (no org names or identifying details) so other maintainers and contributors can learn. The key concern is balance—sharing too much detail could enable misuse, so we need clear boundaries on what’s safe to publish.

[S3DFX-CYBER]

My some opinions and suggestions as Security Practitioner for BLT

1. High-Level Vision

I believe this problem is worth solving in this way, and more importantly, I think it can help BLT regain a clear and recognizable core identity.

At the moment, BLT offers many features, but for a new user it is not always obvious what BLT fundamentally stands for. Refocusing the core around security, remediation, and learning gives BLT a much clearer narrative:

BLT helps identify real security issues, supports responsible fixing, and grows security-aware contributors.

This direction feels aligned with BLT’s mission, OWASP values, and the long-term health of the FOSS ecosystem.

Who Benefits the Most

The primary beneficiaries, in my view, are:

Small open-source projects

Early-stage founders

Projects with limited or no security budget

These teams often lack:

Dedicated AppSec engineers

Proper vulnerability monitoring

Time to track dependency risks and disclosures

For them, early alerts plus remediation guidance can meaningfully reduce risk without requiring enterprise-level tooling or cost.

---

2. Vulnerability Discovery

At a high level, I think automation and AI-assisted scanning are necessary, because manual vulnerability discovery does not scale across many repositories.

Using scanners and AI to:

Detect dependency risks

Identify known CVEs

Surface potential security issues

makes sense as a first-step signal generator.

On Automated PRs

Automatically submitting security PRs feels high-risk:

It can break projects

It may violate contribution or disclosure guidelines

It could be misused or spammed

Security fixes require careful human judgment

A safer and more responsible flow, in my opinion, would be:

1. Automated detection (scanner + AI)

2. Security-aware issue or advisory creation

3. Remediation hints and references

4. Human-reviewed fixes, either by contributors or maintainers

This keeps automation focused on detection and triage, while remediation remains human-led and accountable.

Notifications

Email still feels like the most accepted and expected channel for responsible disclosure.
However, combining email with:

GitHub Security Advisories

Opt-in dashboards for maintainers

could improve flexibility without breaking trust.

---

3. UI / UX Bug Discovery

In the context of a security-focused BLT, general UI/UX bug discovery feels more like noise than a core pillar.

UI bugs:

Are easier to find

Usually don’t require strong incentives

Are already reported naturally by users

However, frontend issues can become security issues (e.g., vulnerable frontend dependencies, insecure auth flows, misused components).

So instead of general UI/UX bugs, I think a better fit would be:

Frontend-related security risks

Dependency vulnerabilities in UI frameworks

Security-relevant logic flaws in frontend code

This keeps the scope aligned with security rather than visual or usability feedback.

---

4. Incentivizing Fixes

I agree that incentives help motivation, but I think credibility must come before scale.

If incentives (BACON, badges, rewards) are not trusted or meaningful:

Skilled contributors may ignore them

Low-quality PRs may increase

A more structured incentive model could depend on:

Severity of the issue

Trust level and history of the contributor

For example:

Beginners receive learning-oriented badges and progression markers

Trusted contributors earn higher-value recognition for meaningful fixes

This avoids gaming while still encouraging growth.

---

5. Education & Contributor Growth

Education is critical to this vision, but I believe it should remain separate from the core product (e.g., a dedicated repo or platform), so BLT itself does not become too heavy.

Before expanding education, BLT should clearly define:

What level of security knowledge is expected

What contributors should understand in practice

Which vulnerabilities are “core knowledge” for BLT users

Education should be hands-on, not theory-heavy:

Vulnerable code examples

Small code snippets to analyze

Realistic scenarios instead of MCQs

Explanations tied to real fixes

Ideally, BLT itself becomes the learning source:

Patterns found during scanning (without exposing sensitive details)

Common mistakes turned into learning modules

Real-world findings driving education content

This keeps education tightly connected to BLT’s actual work, not generic cybersecurity material.

---

6. Knowledge Sharing & Community Impact

For surfacing patterns and trends, I think dashboards and reports are more effective than blogs.

Dashboards: vulnerability trends, common categories, remediation outcomes

Blogs: contributor stories, learning guides, platform updates

Dashboards feel:

More actionable

Safer for sensitive data

More aligned with maintainers’ needs

---

Closing Perspective

All of the above reflects my own opinions, shaped by:

Reviewing BLT’s current feature set

Identifying gaps and overlaps

Considering BLT’s stated mission and long-term goals

My intent is not to expand BLT indiscriminately, but to help it move toward a clearer, more defensible core that balances:

Security responsibility

Contributor growth

Community trust

Long-term sustainability

[DonnieBLT]

Closing this and we can discuss with the individual idea posts