Bug bounty programs started with a good idea: give security researchers a safe way to report vulnerabilities, reward them for useful findings, and help companies fix issues before attackers exploit them.
That idea still makes sense.
The problem is what the industry has done with it.
Somewhere along the way, too many companies turned bug bounty into a cheap substitute for real security. They launched programs with tiny scopes, vague rules, slow triage, questionable duplicate decisions, and rewards that sometimes feel insulting compared to the value of the finding.
And then, after a researcher spends hours or days finding a real issue, writing a report, creating proof of concept steps, and taking the legal risk of touching someone else's system, the company replies with something like:
"Thanks, here is a T-shirt."
Or:
"We'll add your name to our hall of fame."
Come on.
Recognition is nice. Community is nice. A thank-you is nice. But a T-shirt is not compensation. A hall-of-fame mention is not a serious reward for protecting a company's users, reputation, infrastructure, and revenue.
If a billion-dollar company benefits from vulnerability research, it should pay for vulnerability research.
That should not be controversial.
The Industry Wants Free Security Labor
Let's be honest about what is happening.
A lot of companies want the benefits of security research without paying for security research.
They want outsiders to test their systems. They want researchers to spend nights and weekends looking for bugs. They want detailed reports, clean reproduction steps, screenshots, videos, impact analysis, and responsible disclosure. They want researchers to behave professionally, follow the rules, avoid disruption, and protect user data.
But when it is time to pay, suddenly everything becomes complicated.
The report is "informative." The bug is "low impact." The endpoint is "out of scope." The issue is "known." The vulnerability is a "duplicate." The exploit requires "unlikely conditions." The reward is "swag only." The researcher gets a badge, a shirt, or a name on a web page.
This is the part that feels broken.
Security research is work. It takes skill. It takes time. It takes judgment. A good report is not just someone clicking around a website and getting lucky. It often requires understanding application logic, authentication flows, API behavior, browser security, cloud services, access control, business rules, and how small weaknesses can chain into serious impact.
Companies pay consultants for this. They pay auditors for this. They pay penetration testing firms for this. They pay security vendors for this.
But when an independent researcher finds the same kind of issue through a bounty program, suddenly the company wants to pay in stickers.
That is not a serious model.
Bug Bounty Is Not Charity for Corporations
There is a difference between helping a community project and doing unpaid work for a wealthy company.
If an open-source project run by volunteers has a small security issue and someone reports it for free, that is community. If a nonprofit or small project says, "We cannot pay much, but we appreciate help," most people understand the situation.
But when a large company with investors, revenue, customers, and executives asks the global security community to test its systems, that is different.
That is not community in the same way. That is labor.
The company is receiving value. It is reducing risk. It is avoiding potential incidents. It is protecting its brand. It is improving its product. It may even use the existence of the program in sales calls, compliance conversations, investor updates, or marketing material.
So when the reward is a T-shirt, the message is clear:
"We value the appearance of security more than the person doing the work."
That is why so many researchers are tired.
They are tired of being treated like free QA. They are tired of being thanked but not paid. They are tired of programs using technicalities to avoid rewards. They are tired of companies acting like exposure is compensation.
A name on a hall of fame page does not pay rent. A hoodie does not cover the time spent building a proof of concept. A sticker does not compensate for helping prevent a data breach.
Scope Can Be Used as a Trap
Every bug bounty program needs rules. Nobody is saying researchers should have unlimited permission to test anything, break things, or touch sensitive systems without boundaries.
Scope matters.
But scope can also be abused.
Some programs define scope so narrowly that the researcher is basically trapped inside one tiny box. Test this demo app, but not production. Test this one host, but not the APIs behind it. Test this feature, but not authentication. Test this sandbox, but not real user flows. Do not test business logic. Do not test chained impact. Do not test anything that would actually prove whether the product is secure.
Then the company proudly says, "We have a bug bounty program."
That is misleading.
If researchers are only allowed to test a toy version of the environment, the program does not prove much. It proves that a toy version of the environment was tested. It does not prove the company has good access control. It does not prove customer data is safe. It does not prove the architecture is secure. It does not prove internal systems are protected. It does not prove the product can survive real-world abuse.
A lot of serious vulnerabilities live in the gaps between systems. They appear when APIs trust the frontend too much, when object-level authorization is inconsistent, when internal services expose more than expected, when one permission model does not match another, or when business logic allows something the developers did not anticipate.
Those bugs are often impossible to find if the program forbids researchers from testing anything meaningful.
A narrow scope is sometimes necessary. A fake scope is security theater.
The Duplicate Problem Is a Trust Problem
Duplicates are one of the biggest pain points in bug bounty.
In theory, duplicates are reasonable. If two people report the exact same vulnerability, the first valid reporter should usually get the reward.
The problem is that the researcher often has no way to verify whether the duplicate decision is fair.
You might spend days on a report. You might find a real issue, document it clearly, explain the impact, and submit it responsibly. Then the program replies with a few words:
"Closed as duplicate."
That is it.
No meaningful explanation. No evidence. No indication of whether the original report had the same root cause, the same endpoint, the same exploit path, the same affected users, or the same impact.
And that matters, because two reports can look similar while being very different.
One researcher might report that user A can view user B's file. Another might report that user A can delete user B's entire workspace through a related but different authorization failure. Are those the same? Maybe they touch the same feature, but the impact is not the same.
One researcher might report metadata exposure. Another might show full source code exposure, secrets leakage, and account takeover potential. Calling both of those "duplicate" without explanation is not good enough.
The duplicate system depends on trust. But trust requires transparency.
Programs do not need to expose private details from the first report. Nobody is asking for another researcher's full submission. But they should provide enough information to prove the decision is legitimate. They should say when the original report came in, whether the root cause is the same, whether the affected asset is the same, and whether the new report added any new impact.
Without that, "duplicate" becomes too easy to abuse.
Even when the company is acting honestly, vague duplicate decisions damage confidence. Researchers are expected to trust a process they cannot see, run by the same party that saves money by not paying them.
That is not a healthy system.
The Lovable Story Is the Perfect Example
The recent Lovable situation is a good example of why people are losing patience with poorly run bug bounty programs.
Lovable is an AI app-building platform, and in April 2026 it ended up in the middle of a security controversy after researchers said project data tied to public projects could be accessed in ways users probably did not understand or expect. Reporting around the incident described exposed source code, AI chat history, and other sensitive project context, while Lovable later said private projects and Lovable Cloud were not affected. The company's own incident response said the issue affected public-project chat history and source code visibility between February 3 and April 20, 2026.
The technical issue matters, but the bug bounty process is what made the story explode.
According to Lovable's own post, multiple valid reports were submitted through its HackerOne disclosure programs, but they were closed instead of being escalated because of outdated internal documentation given to the triage team. Lovable also admitted that its first public response was dismissive and failed to acknowledge the real concern. That is a brutal combination: researchers reported something meaningful, the process failed, and then the first public message made it sound like the company was minimizing the issue.
This is exactly the problem with treating bug bounty like a support queue instead of a security function.
A vulnerability report is not just another ticket. When a researcher says, "I can access data I should not be able to access," that needs a real escalation path. Not just platform triage. Not just a duplicate label. Not just "expected behavior." Someone inside the company needs to own the risk, understand the product context, and ask the uncomfortable question: even if this is technically allowed by some setting, would users reasonably expect it?
That last part is important. Security is not only about whether a feature behaves as documented. It is also about whether the behavior is safe, understandable, and aligned with user expectations. If users are building apps with AI and their prompts, source code, secrets, or implementation details can become visible because of a confusing public/private model, that is not just a documentation issue. That is a design issue.
The Lovable case also shows why "duplicate" decisions can be dangerous when they become the end of the road. A duplicate should not mean "stop thinking." A duplicate should mean "we already know about this exact issue, and it is being handled with the right severity." If the duplicate process prevents serious reports from reaching the people who can actually fix the problem, then the process is broken.
And this is where the industry needs to be honest. Bug bounty platforms can help with intake and triage, but they cannot replace internal accountability. If the triage team gets outdated guidance, that is still on the company. If public-project behavior exposes more than users expect, that is still on the company. If researchers are ignored until they go public, that is still on the company.
Lovable's later response was more serious. The company acknowledged the mistake, apologized for the initial tone, said it fixed the issue, and changed how public projects work. That is better than doubling down forever. But the larger lesson remains: a bug bounty program is only as good as the security culture behind it.
The real failure was not just one authorization bug or one visibility setting. The real failure was the gap between what researchers were warning about and how the company's process handled that warning.
That is why bug bounty cannot be treated like a PR accessory. If a company invites researchers to report vulnerabilities, it needs to be ready to listen when the report is inconvenient. Otherwise, the program is not a security program. It is just a branded mailbox with a leaderboard.
Bug Bounty Is Not the Same as Security
Another problem is how companies talk about bug bounty.
They act like having a program means they are secure.
It does not.
A bug bounty program is one layer of security testing. It is not a full security strategy. It is not a replacement for internal security engineers. It is not a replacement for secure design. It is not a replacement for threat modeling, code review, infrastructure hardening, incident response, access reviews, cloud security, logging, detection, or employee training.
Bug hunters usually test what they can see from the outside. That is valuable, but it is limited.
They usually cannot inspect internal architecture. They cannot fully review cloud IAM permissions. They cannot see every CI/CD secret. They cannot audit employee access. They cannot review internal admin panels unless those are in scope. They cannot evaluate the company's incident response process. They cannot verify whether production databases are properly segmented. They cannot assess whether support staff can accidentally expose user data. They cannot review every vendor integration. They cannot fix a broken engineering culture.
Some of the worst security failures are not just "web app bugs."
They are design failures. Process failures. Access control failures. Monitoring failures. Leadership failures.
A bug bounty program might uncover symptoms of those problems, but it cannot fix them by itself.
If a company keeps getting broken access control reports, the answer is not just to patch one endpoint at a time. The real question is why the authorization model keeps failing. Is there a central permission system? Do engineers know how to use it? Are there automated tests for object ownership? Are sensitive APIs reviewed before release? Are logs able to detect abuse? Does anyone look for the same bug class across the whole product?
That is security.
Bug bounty can help find problems. It cannot replace the work of building systems correctly.
The New "We'll Secure You With Bug Bounty" Market
There is also a growing number of security companies selling bug bounty programs as if they are a complete solution.
The pitch is simple: launch a program, invite hackers, get reports, become secure.
It sounds great. It is easy to sell. It gives executives something visible. It gives marketing something to talk about.
But security does not work like that.
A bug bounty platform can help with intake, triage, researcher communication, report management, and workflow. Those are useful services. But a platform cannot magically secure a company that does not understand its own systems.
If the company has weak engineering practices, unclear ownership, poor logging, no incident response plan, messy cloud permissions, and no internal security culture, a bounty program will not save it.
It may actually expose how unprepared the company is.
Because receiving a report is only the beginning. Someone has to understand it. Someone has to reproduce it. Someone has to assess impact. Someone has to fix it. Someone has to check whether the same issue exists elsewhere. Someone has to communicate with users if data was exposed. Someone has to improve the process so the same class of bug does not return.
That is the hard part.
Finding bugs is not the same as managing security.
Researchers Take Real Risk
People outside the field often underestimate the risk researchers take.
A good-faith researcher has to be careful. They have to avoid accessing more data than necessary. They have to stay within scope. They have to document impact without causing harm. They have to trust that the company will not threaten them, accuse them, ignore them, or twist the rules after the report is submitted.
That trust is not always rewarded.
There are researchers who have been ignored. Researchers who have been threatened. Researchers who have been accused of extortion for asking about a bounty. Researchers who have had reports closed after months of silence. Researchers who have watched companies quietly fix the bug and deny payment. Researchers who reported serious issues and received nothing but a generic thank-you.
So when people say, "Bug bounty is voluntary, nobody is forcing them," that misses the point.
Yes, researchers choose to participate. But companies also choose to create the conditions. They choose the rules. They choose the rewards. They choose the triage process. They choose the scope. They choose how transparent to be. They choose whether to treat researchers like partners or disposable labor.
The fact that participation is voluntary does not make every program fair.
What a Serious Program Looks Like
A serious bug bounty program respects researchers and understands its own limits.
It has realistic scope. It pays fair rewards. It explains decisions clearly. It does not hide behind vague policy language. It does not use "out of scope" as a reflex. It does not call everything low severity because the impact is inconvenient. It does not treat duplicate decisions like a secret court ruling.
A serious program also has people inside the company who can actually fix what comes in.
That part is important.
If reports sit for weeks or months because nobody owns the affected system, the program is not working. If researchers keep finding the same bug class, the company is not learning. If serious issues are dismissed until they become public, the program is not a security process. It is a mailbox.
A good program should make the company better over time. It should feed lessons back into engineering. It should lead to better patterns, better tests, better reviews, and better architecture. It should not just be a place where reports go to die.
And yes, it should pay.
Not every valid issue deserves a massive reward. Severity matters. Impact matters. Quality matters. But if the finding is real and useful, compensation should be real too.
Not swag. Not exposure. Not a badge. Not a leaderboard entry.
Money.
The T-Shirt Mentality Has to Die
The T-shirt mentality is the clearest sign that some companies still do not respect security labor.
Imagine telling a lawyer, "Thanks for reviewing this contract, we'll put your name on our website."
Imagine telling a cloud consultant, "Thanks for finding that dangerous IAM misconfiguration, here's a hoodie."
Imagine telling an incident response firm, "Great work helping us avoid a breach, we'll send you stickers."
Nobody would take that seriously.
But somehow, when independent researchers find vulnerabilities, some companies think this is acceptable.
It is not.
If the finding protects users, reduces risk, and helps the company avoid damage, then it has value. If it has value, the person who found it should be compensated in a way that reflects that value.
Recognition can be extra. Swag can be extra. A hall of fame can be extra.
But it should not be the reward.
The Real Issue Is Power
At the center of all this is a power imbalance.
The company controls the program. The company writes the rules. The company decides what is in scope. The company decides severity. The company decides whether something is a duplicate. The company decides whether the researcher gets paid.
The researcher does the work first and negotiates later.
That is a strange model.
It can work when the company is fair, transparent, and serious. It falls apart when the company is defensive, cheap, or more interested in reputation than security.
This is why researchers get angry when companies mishandle reports. It is not just about one payout. It is about a system where the researcher is asked to act in good faith while the company can hide behind process.
If companies want trust, they have to earn it.
Bug Bounty Still Has a Place
None of this means bug bounty is useless.
Bug bounty can be great when it is done properly.
It can bring in diverse perspectives. It can find issues internal teams missed. It can give researchers a legal path to report problems. It can improve products. It can protect users.
But it only works when everyone understands what it is.
Bug bounty is not a replacement for a security team. Bug bounty is not a replacement for secure engineering. Bug bounty is not a replacement for architecture review. Bug bounty is not a replacement for incident response. Bug bounty is not a replacement for paying professionals.
It is an additional layer.
A company should already be doing the basics before asking strangers on the internet to find what it missed. It should know what assets it owns. It should understand where sensitive data lives. It should have engineers responsible for security. It should be able to fix issues quickly. It should have a plan for incidents. It should have logs. It should have access reviews. It should have secure development practices.
Then bug bounty can add value.
Without that foundation, a bounty program is just a public-facing intake form with a marketing budget.
Final Thoughts
Bug bounty is not the enemy.
The problem is bad bug bounty. Cheap bug bounty. Performative bug bounty. Programs that want free labor, narrow the scope to the point of uselessness, hide behind duplicate labels, and reward serious work with a T-shirt.
Security researchers deserve better than that.
They deserve fair pay, clear rules, honest triage, transparent decisions, and respect for the work they do.
Companies deserve to be secure too, but they do not get there by outsourcing responsibility to unpaid strangers. They get there by building real security programs, hiring the right people, designing systems carefully, fixing root causes, and using bug bounty as one part of a much bigger picture.
A hall-of-fame page is not a security strategy.
A T-shirt is not a bounty.
And if a company can afford to profit from software, it can afford to pay the people who help make that software safer.