An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick.
Then again, I once submitted a bug report to my bank, because the login method could be switched from password+pin to pin only, when not logged in, and they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password. (And that's not even getting into the difference between real two-factor authentication the some-factor one-and-a-half-times they had implemented by adding a PIN to a password login.) I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.
Assuming the host of the bug bounty program is operating in good faith, adding some kind of barrier to entry or punishment for untested entries will weed out submitters acting in bad faith.
Bug bounties often involve a lot of risk for submitters. Often the person reading the report doesn't know that much and misinterprets it. Often rules are unclear about what sort of reports are wanted. A pay to enter would increase that risk.
Honestly bug bounties are kind of miserable for both sides. I've worked on the recieving side of bug bounty programs. You wouldnt believe the shit that is submitted. This was before AI and it was significant work to sort through, i can only imagine what its like now. On the other hand for a submitter, you are essentially working on spec with no garuntee your work is going to be evaluated fairly. Even if it is, you are rolling the dice that your report is not a duplicate of an issue reported 10 years ago that the company just doesn't feel like fixing.
Pay to enter would increase the risk of submitting a bug report.
However, if the submission fees were added to the bounty payable, then the risk reward changes in favour of the submitter of genuine bugs.
You could even have refund the submission fee in the case of a good faith non bug submission.
A little game theory can go a long way in improving the bug bounty system...
They could allow submitters to double down on submissions escalating the bug to more skilled and experienced code reviewers who get a cut of the doubled submission fee for reviews.
Indeed, increasing the incentive for companies to reject ( and then sometimes silently fix anyway ) even the valid reports would only increase further misery for everyone.
A problem with this approach is that one of the key functions of a bug bounty program is to encourage people to report vulnerabilities to the developers, rather than selling them elsewhere.
If I have to pay money to submit a vulnerability to the developers with on guarantee that I'll even get refunded for a high quality and good faith report, let alone any actual payout, there's much less incentive for me to do so compared to selling them to someone else who won't charge me money for the privilege.
> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.
Sadly, yeah. And will do anything only if they believe they can actually be caught.
An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago.
A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick.
I refer to this as the Notion-to-Confluence cost border.
When Notion first came out, it was snappy and easy to use. Creating a page being essentially free of effort, you very quickly had thousands of them, mostly useless.
Confluence, at least in west EU, is offensively slow. The thought of adding a page is sufficiently demoralizing that it's easier to update an existing page and save yourself minutes of request time outs. Consequently, there's some ~20 pages even in large companies.
I'm not saying that sleep(15 * SECOND) is the way to counter, but once something becomes very easy to do at scale, it explodes to the point where the original utility is now lost in a sea of noise.
It’s strange how sensitive humans are to these sort of relative perceived efforts. Having a charged, cordless vacuum cleaner ready to go and take around the house has also changed our vacuuming game. Because carrying a big unwieldy vacuum cleaner and needing to find a power socket at every location just feels like much more effort. Even though it really isn't.
It is. The classical vacuum is heavier, you have to find the socket and plug it in (non-trivial if you have few of them, or have kids and sockets have kid blocks on them), and perhaps most importantly, you need two free hands to operate it (particularly when carrying, plugging in and repositioning). That alone is enough to turn it into a primary activity, i.e. the kind of thing that you explicitly decide to do and becomes your main focus. Meanwhile, a charged cordless cleaner is something you can semi-consciously grab with one hand while passing by, and use on the go to do some cleaning while actually focused on something else. It's an entirely different class of activity, much easier to fit in during the day.
Ironically, the cordless vacuum is even better than vacuum robots in this regard! I was surprised to hear from some friends and acquaintances that they prefer the manual vacuum to robotic one, and find it a better time/effort saver - but I eventually realized they're right, simply because the apps for controling the robotic vacuums are all steaming piles of shit, and their bad UI alone turns activating the robot into primary activity. It may be a brief activity, but it still requires full focus.
The term I know / used for this is "trivial inconveniences", via an old article of Scott Alexander[0].
The quote from example from early in the article stuck with me for years:
Think about this for a second. The human longing for freedom of information is a terrible and wonderful thing. It delineates a pivotal difference between mental emancipation and slavery. It has launched protests, rebellions, and revolutions. Thousands have devoted their lives to it, thousands of others have even died for it. And it can be stopped dead in its tracks by requiring people to search for "how to set up proxy" before viewing their anti-government website.
(Now this is more poetic, but I suppose the much more insightful example that also stuck with me is given later - companies enticing you to buy by offering free money, knowing well that most customers can't be arsed to fill out a form to actually get that money.)
I find this to be a very amusing critique. In my experience, Notion (when I stopped using it 3 years ago) was slow as molasses. Slow to load, slow to update. In comparison, at work, I almost exclusively favor Confluence Cloud. It's very responsive for me.
We have tons of Confluence wikis, updated frequently.
I think it might be the same issue as with WordPress and Jira - terrible plugins. Each company uses own special mix, and encounters issues often occurring in that one specific configuration. And it is the base platform that takes the blame.
> I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.
I personally came to that conclusion thanks to the GrapheneOS situation regarding device attestation. Insecure devices get full features from some apps because they are certified, although they cite security, while GrapheneOS get half featured apps because it's "insecure" (read, doesn't have the Google certification, but are actually the most secure devices you can get, worldwide)
It's related, but GP is still right to bring it up - it's the one question that is most important wrt. security, and also conveniently the least often asked: security for who, and from what? "Security" isn't an absolute good.
I found that banks are one of the worst organizations when it comes to authentication. They are regulated but the requirements are completely outdated and irrelevant in a risk context.
And then you have banks such as Boursobank (a French online bank) that has weak traditional authentication (and a faulty app, but they do not care) and out of the blue also provides passkeys. Making it at the same time horribly bad and wonderfully good.
The worst part is that they hide behind regulations when in fact there are only few of them.
Other instiytutions such as SWIFT are as bad and equally arrogant.
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick.
It would also stop a lot of genuine submissions unfortunately, as some literally can't pay not just won't pay (for both technical or financial reasons), and adds complexity¹. Each project working this way will need to process a bunch of payments and refunds on top of the actual bounty payments, which is not admin free nor potential financially cost free.
I can't think of an easy answer that would work for more than a very short amount of time. As soon as there is money involved and an easy way to use tooling rather than actual effort/understanding to be involved, many will try to game the system ruining it for those genuine participants. Heck, even if the reward is just credit² rather than money, that will happen. Many individual people are honest and useful, people as a whole are a bunch of untrustworthy arseholes who will innocence you and the rest of the world for a penny or just for shits & giggles.
> Assuming the host of the bug bounty program is operating in good faith
This is a significant assumption. One that is it harder to not be paranoid about when you are putting money down.
> they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password
This does not surprise me. My primary bank (FirstDirect, UK) switched the way I authenticate from “between 5 and 9 alphanumeric characters”³ to a 5-digit pin, and all their messages about it assured me (like hell!) that this was “just as secure as before”…⁴
--------
[1] Needing a payment processing option that is compatible with both the reporter and reportee, at the point of submission. At the moment that can be arranged after the bounty is awarded rather than something a project like curl needs to have internationally setup and supported before accepting submissions.
[2] ref: people submitting several simple documentation fixes, one misplaced comma or 'postrophe per pull request, to game some “pull requests accepted” metric somewhere.
[3] which wasn't ideal to start with
[4] I would accept the description “no less secure than before” if they admitted that the previous auth requirements were also lax.
Are bug reports a 100% sure black and white thing?
Could people who think they found a bug but not sure be turned off by the up front cost / risk of finding out they are wrong or not technically finding a bug?
For weak bank logins, my guess is that reimbursing all account takeovers is cheaper than having a complex login process that would scare away non-technical customers. Or, well, I could see myself making that decision if I were more versed in finance than in computer science and I had a reasonable risk assessment in front of me to tell me how many account takeovers happen.
Banks aren't even liable for losses from account takeovers, at least if their system is compliant, regardless of whether that makes it secure. Their biggest incentive is customer satisfaction, which fraud does hurt.
It's credit cards that have to reimburse for fraud, but they charge the merchant for it, plus fees, so they have absolutely no incentive to prevent fraud, if not an incentive to outright encourage fraud. That would explain why their implementation of the already compromised EMV was further nerfed by a lack of a PIN in the US.
That anecdote is hilarious and scary in equal measures. Optional passwords are certainly more convenient than required ones, but so are optional PINs. The most convenient UX would be never needing to log in at all! Unless you find it inconvenient for others to have access to your bank account of course
That's what eBay does to me. You get to choose, at the time of login, between entering a password and getting an email verification, or just getting an email verification. At least with the bug report I had submitted to my bank, the password requirement had to be disabled from inside a settings menu, instead of being a clear option in the login prompt, but it that case it wasn't even a 2nd factor.
I hate this as well, especially since I have greylisting enabled on some email addresses, so by the time the email login is delivered, the login session has already timed out and of course the sender uses different mail servers everytime. So in some cases, it's nearly impossible to login and takes minutes...
Long long ago the google toolbar queries could be reverse engineered to do an i feel lucky search on gmail. I created a login that (if @gmail.com) forwarded to the specific mail.
Unlikely to happen but it seems fun to extend email [clients] with uri's. It is just a document browser, who cares how they are delivered.
Agreed, although the reimbursement should be based on whether a reasonable person could consider that to be a vulnerability. Often it’s tricky for outsiders to tell whether a behaviour is expected or a vulnerability
cURL would operate such a program in good faith, and quickly earn the trust of the people who submit the kind of bug reports cURL values.
Your bank would not. Nor would mine, or most retail banks.
If the upfront cost would genuinely put off potential submitters, a cottage industry would spring up of hackers who would front you the money in return for a cut if your bug looked good. If that seems gross, it's really not - they end up doing bug triage for the project, which is something any software company would be happy to pay people for.
> An entry fee that is reimbursed if the bug turns out to matter would stop this, real quick.
The problem is that bug bounty slop works. A lot of companies with second-tier bug bounties outsource triage to contractors (there's an entire industry built around that). If a report looks plausible, the contractor files a bug. The engineers who receive the report are often not qualified to debate exploitability, so they just make the suggested fix and move on. The reporter gets credit or a token payout. Everyone is happy.
Unless you have a top-notch security team with a lot of time on their hands, pushing back is not in your interest. If you keep getting into fights with reporters, you'll eventually get it wrong and you're gonna get derided on HN and get headlines about how you don't take security seriously.
In this model, it doesn't matter if you require a deposit, because on average, bogus reports still pay off. You also create an interesting problem that a sketchy vendor can hold the reporter's money hostage if the reporter doesn't agree to unreasonable terms.
I don’t think it works for curl though. You would guess that sloperators would figure out that their reports aren’t going through with curl specifically (because, well, people are actually looking into them and can call bullshit), and move on.
For some reason they either didn’t notice (e.g. there’s just too many people trying to get in on it), or did notice, but decided they don’t care. Deposit should help here: companies probably will not do it, so when you see a project requires a deposit, you’ll probably stop and think about it.
Triage gets outsourced because the quality of reports is low.
If filing a bad report costs money, low quality reports go down. Meanwhile anyone still doing it is funding your top notch security team because then they can thoroughly investigate the report and if it turns out to be nothing then the reporter ends up paying them for their time.
It seems open source loses the most from AI. Open source code trained the models, the models are being used to spam open source projects anywhere there's incentive, they can be used to chip away at open source business models by implementing paid features and providing the support, and eventually perhaps AI simply replaces most open source code
Extending on the same line, we will see programs like Google Summer of Code (GSoC) getting a massive revamp, or they will stop operating.
From my failed attempt, I remember that
- Students had to find a project matching their interests/skills and start contributing early.
- We used to talk about staying away from some projects with a low supply of students applying (or lurking in the GitHub/BitBucket issues) because of the complexity required for the projects.
Both of these acted as a creative filter for projects and landed them good students/contributors, but it completely goes away with AI being able to do that at scale.
> they can be used to chip away at open source business models by implementing paid features and providing the support
There are a lot of things to be sad about AI, but this is not it. Nobody has a right to a business model, especially one that assumes nobody will compete with you. If your business model relies on the rest of the world bring sucky so you can sell some value-added to open-core software, i'm happy when it fails.
When LLMs are based on stolen work and violate GPL terms, which should be already illegal, it's very much okay to be furious about the fact that they additionally ruin respective business models of open source, thanks to which they are possible in the guest place.
> the fact that they additionally ruin respective business models of open source
The what now? Open source doesn't have a business model, it's all about the licensing.
FOSS is about making code available to others, for any purpose, and that still works the same as 20 years ago when I got started. Some seem to wake up to what "for any purpose" actually mean, but for many of us that's quite the point, that we don't make choices for others.
>“Free software” means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software.
> Being able to learn from the code is a core part of the ideology embedded into the GPL.
I have to imagine this ideology was developed with humans in mind.
> but LLMs learning from code is fair use
If by “fair use” you mean the legal term of art, that question is still very much up in the air. If by “fair use” you mean “I think it is fair” then sure, that’s an opinion you’re entitled to have.
Competition is extremely important yes. But not the kind of competition, backed by companies that have much bigger monetary assets, to overwhelm projects based on community effort just to trample it down. The FFMPEG Google stuff as an example.
I wouldn't say open source code solely trained the models, surely there are CS courses and textbooks, official documentation as well as transcripts of talks and courses all factor in as well.
On another note, regarding AI replacing most open source code. I forget what tool it was, but I had a need for a very niche way of accessing an old Android device it was rooted, but if I used something like Disk Drill it would eventually crap out empty files. So I found a GUI someone made, and started asking Claude to add things I needed for it to a) let me preview directories it was seeing and b) let me sudo up, and let me download with a reasonable delay (1s I think) which basically worked, I never had issues again, it was a little slow to recover old photos, but oh well.
I debated pushing the code changes back into github, it works as expected, but it drifted from the maintainers own goals I'm sure.
This is not a technology, but ethics and respect problem.
From the same article:
> Not all AI-generated bug reports are nonsense. It’s not possible to determine the exact share, but Daniel Stenberg knows of more than a hundred good AI assisted reports that led to corrections.
Meaning: developers and researchers who use the tool as it's meant to work, as a tool, are leveraging it to improve curl. But they are not skipping the part of understanding the content of their reports, testing it, and only then submitting it.
How so? I think the Bazaar model has the most to gain - contributors can use LLMs to create PRs, and you can choose from a vast array of projects depending on how much you trust vibe coding.
already decades ago when we were kids eating pudding with a fork was a fun past time, and i am sure the idea is as old as pudding or forks themselves. i mean, the fact that it spread so fast shows that there are many who already practiced it. it's actually surprising it took this long to become a meme.
heck, my cousin bet with me or let me compete eating pudding with chopsticks. (and that was long before i went to china)
practically speaking, the only downside of using a fork (or chopsticks) is scraping the bottom when you are finishing up.
I feel AI will have the same effect degrading Internet as social media did. This flood of dumb PRs, issues is one symptom of it. Other is AI accelerating the trend which TikTok started—short, shallow, low-effort content.
It's a shame since this technology is brilliant. But every tech company has drank the “AI is the future” Kool-aid, which means no one has incentive to seriously push back against the flood of low-effort, AI-generated slop. So, it's going to be race to the bottom for a while.
It'll stop soonish. The industry is now financed by debt rather than monetary assets that actually exist. Tons of companies see zero gain from AI as its reported repeatedly here on HN. So all the LLM vendors will eventually have to enshittify their products (most likely through ads, shorter token windows, higher pricing and whatnot). As of now, not a sustainable business model thankfully. The only sad part is that this debt will hit the poorest people most.
Outside of direct monetary gain like bounties are efforts to just stand out, in terms of being able to show contributions to a large project or getting say a CVE.
Stenberg has actually written about invalid/wildly overrated vulnerabilities that get assigned CVEs on their blog a few times and those were made by humans. I often get the sense some of these aren't just misguided reporters but deliberate attempts to make mountains out of molehills for reputation reasons. Things like this seem harder to account for as an incentive.
The company I work for has a pretty bad bounty system (basically a security@corp email). We have a demo system and a public API with docs. We get around 100 or more emails a day now. Most of it is slop, scams, or my new favourite AI security companies sending us an AI generated pentest un prompted filled with false positives, untrue things, etc. It has become completely useless so no one looks at it.
I had a sales rep even call me up basically trying to book a 3 hour session to review the AI findings unprompted. When I looked at the nearly 250 page report, and saw a critical IIS bug for Windows server (doesn't exist) existing at a scanned IP address of 5xx.x.x.x (yes an impossible IP) publically available in AWS (we exclusively use gcp) I said some very choice words.
It makes sense. This process of searching for bugs was slow and time-consuming so it needed to be incentivized. This is no longer the case. Now the hard part is in identifying which ones are real.
To paraphrase a famous quote: AI-equipped bug hunters find 100 out of every 3 serious vulnerabilities.
The process of finding bugs is still slow and time consuming. The kinds of vulnerabilities you find in codebases like cURL are still beyond AI. Binary exploitation is still a human only field.
In the second report, Daniel greeted the slopper very kindly and tried to start a conversation with them. But the slopper calls him by the completely wrong name. And this was December 2023. It must have been extremely tiring.
December 2023... that was early AI era. Had to double-check the dates actually, because I misremembered the release date of GPT-4 as being in 2024; turns out it was in 2023, and that was when LLMs first became remotely useful for even this kind of slop.
I looked at two reports, and I can’t tell if the reports are directly from an ai or some very junior student not really understanding security. LLms to me sound generally more convincing.
Yeah, that one is pretty clearly written with the help of AI. This could well be the work of a larger group, say a state actor, trying to overwhelm reviewers and crowd out real reports. And if not yet, then for sure going forward ...
The solution for this, IMO, is flags. Just like with CTFs, host an instance of your software with a flag that can only be retrieved after a successful exploit. If someone submits the flag to you, there is no argueing about wether or not they found a valid vulnerability.
Yes, this does not work for all vulnerability classes, but it is the best compromise in my mind.
How exactly would that work? Curl isn't exactly software that can be "hosted" somewhere, and I'm not sure where you'd hide the flag in the software? Either very few actual vulns would end up being able to retrieve the flag, or it would be trivial to retrieve the flag without an exploit.
In most basic form it would just be form with URL that (lib)curl is later supposed to fetch. And target server (controlled by researcher) is supposed to send payload that triggers RCE in client.
Sure, it covers a very narrow scope but I am afraid the bigger issue would be that it is going to get spammed with submitted links. And those links will often be to strait up illegal content, it might not matter that such server instantly deletes all downloaded files.
What I wonder is if this will actually reduce the amount of slop.
Bounties are a motivation, but there's also promotional purposes. Show that you submitted thousands of security reports to major open source software and you're suddenly a security expert.
Remember the little iot thing that got on here because of a security report complaining, among other things, that the linux on it did not use systemd?
I dont think bounties make you an "expert". If you want to be deemed an expert, write blogs detailing how the exploit works. You can do that without a bounty.
In many ways one of the biggest benefits of bug bounties is having a dedicated place where you can submit reports and you know the person on the other end wants them and isn't going to threaten to sue you.
For the most part, the money in a bug bounty isn't work the effort needed to actually find stuff. The exception seens to be when you find some basic bug, that you can automate scan half the internet and submit to 100 different bug bounties.
They don't care. They generate large amounts of these, spam them out, and hope for some small success. If they get banned or blocked, they make new accounts. Shame isn't even a factor; it's all about money. They don't even attempt to understand or care about a product.
This was partially the case before, where you'd still get weird spammy or extortive reports, but I guess LLMs enable random people to shoot their shot and gum up the works even more.
That's because we stopped calling others out for shameful, disrespectful or unethical behavior as a rule. So there is less or nothing to be ashamed about anymore.
The LLM models give the most likely respond to a prompt. So if you prompt it with "find security bugs from this code" it will respond with "This may be a security bug" than you "you fucking donkey this curl code has already been eyeballed by hundreds of people, you think a statistic model will find something new?"
Because LLMs are bad at reviewing code for the same reasons they are bad at making it? They get tricked by fancy clean syntax and take long descriptions / comments for granted without considering the greater context.
I don't know, I prompted Opus 4.5 "Tell me the reasons why this report is stupid" on one of the example slop reports and it returned a list of pretty good answers.[1]
Give it a presumption of guilt and tell it to make a list, and an LLM can do a pretty good job of judging crap. You could very easily rig up a system to give this "why is it stupid" report and then grade the reports and only let humans see the ones that get better than a B+.
If you give them the right structure I've found LLMs to be much better at judging things than creating them.
Opus' judgement in the end:
"This is a textbook example of someone running a sanitizer, seeing output, and filing a report without understanding what they found."
https://hackerone.com/curl/hacktivity Add a filter for Report State: Resolved. FWIW I agree with you, you can use LLMs to fight fire with fire. It was easy to see coming, e.g. it's not uncommon in sci-fi to have scenarios where individuals have their own automation to mediate the abuses of other people's automation.
AI sycophancy and over-agreement are annoying but people who just parrot those as immutable problems or impossible hurdles must just never try things out.
"Tell me the reasons why this report is stupid" is a loaded prompt. The tool will generate whatever output pattern matches it, including hallucinating it. You can get wildly different output if you prompt it "Tell me the reasons why this report is great".
It's the same as if you searched the web for a specific conclusion. You will get matches for it regardless of how insane it is, leading you to believe it is correct. LLMs take this to another level, since they can generate patterns not previously found in their training data, and the output seems credible on the surface.
Trusting the output of an LLM to determine the veracity of a piece of text is a baffilingly bad idea.
>"Tell me the reasons why this report is stupid" is a loaded prompt.
This is precisely the point. The LLM has to overcome its agreeableness to reject the implied premise that the report is stupid. It does do this but it takes a lot, but it will eventually tell you "no actually this report is pretty good"
The point being filtering out slop, we can be perfectly find with false rejections.
The process would look like "look at all the reports, generate a list of why each of them is stupid, and then give me a list of the ten most worthy of human attention" and it would do it and do a half-decent job at it. It could also pre-populate judgments to make the reviewer's life easier so they could very quickly glance at it to decide if it's worthy of a deeper look.
>However, I should note: without access to the actual crash file, the specific curl version, or ability to reproduce the issue, I cannot verify this is a valid vulnerability versus expected behavior (some tools intentionally skip cleanup on exit for performance). The 2-byte leak is also very small, which could indicate this is a minor edge case or even intended behavior in certain code paths.
Even biased towards positivity it's still giving me the correct answer.
Given a neutral "judge this report" prompt we get
"This is a low-severity, non-security issue being reported as if it were a security vulnerability." with a lot more detail as to why
So positive, neutral, or negative biased prompts all result in the correct answer that this report is bogus.
How would it work if LLMs provide incorrect reports in the first place? Have a look at the actual HackerOne reports and their comments.
The problem is the complete stupidity of people. They use LLMs to convince the author of the curl that he is not correct about saying that the report is hallucinated. Instead of generating ten LLM comments and doubling down on their incorrect report, they could use a bit of brain power to actually validate the report. It does not even require a lot of skills, you have to manually tests it.
Funny how we are now sensitivized to these AI slops, at first I fixated on the En dashes in the lead of the article, made me doubt of the article's author for a few seconds.
Then again, I once submitted a bug report to my bank, because the login method could be switched from password+pin to pin only, when not logged in, and they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password. (And that's not even getting into the difference between real two-factor authentication the some-factor one-and-a-half-times they had implemented by adding a PIN to a password login.) I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.
Assuming the host of the bug bounty program is operating in good faith, adding some kind of barrier to entry or punishment for untested entries will weed out submitters acting in bad faith.
Honestly bug bounties are kind of miserable for both sides. I've worked on the recieving side of bug bounty programs. You wouldnt believe the shit that is submitted. This was before AI and it was significant work to sort through, i can only imagine what its like now. On the other hand for a submitter, you are essentially working on spec with no garuntee your work is going to be evaluated fairly. Even if it is, you are rolling the dice that your report is not a duplicate of an issue reported 10 years ago that the company just doesn't feel like fixing.
If I have to pay money to submit a vulnerability to the developers with on guarantee that I'll even get refunded for a high quality and good faith report, let alone any actual payout, there's much less incentive for me to do so compared to selling them to someone else who won't charge me money for the privilege.
Sadly, yeah. And will do anything only if they believe they can actually be caught.
An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago.
A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.
I refer to this as the Notion-to-Confluence cost border.
When Notion first came out, it was snappy and easy to use. Creating a page being essentially free of effort, you very quickly had thousands of them, mostly useless.
Confluence, at least in west EU, is offensively slow. The thought of adding a page is sufficiently demoralizing that it's easier to update an existing page and save yourself minutes of request time outs. Consequently, there's some ~20 pages even in large companies.
I'm not saying that sleep(15 * SECOND) is the way to counter, but once something becomes very easy to do at scale, it explodes to the point where the original utility is now lost in a sea of noise.
Ironically, the cordless vacuum is even better than vacuum robots in this regard! I was surprised to hear from some friends and acquaintances that they prefer the manual vacuum to robotic one, and find it a better time/effort saver - but I eventually realized they're right, simply because the apps for controling the robotic vacuums are all steaming piles of shit, and their bad UI alone turns activating the robot into primary activity. It may be a brief activity, but it still requires full focus.
The quote from example from early in the article stuck with me for years:
Think about this for a second. The human longing for freedom of information is a terrible and wonderful thing. It delineates a pivotal difference between mental emancipation and slavery. It has launched protests, rebellions, and revolutions. Thousands have devoted their lives to it, thousands of others have even died for it. And it can be stopped dead in its tracks by requiring people to search for "how to set up proxy" before viewing their anti-government website.
(Now this is more poetic, but I suppose the much more insightful example that also stuck with me is given later - companies enticing you to buy by offering free money, knowing well that most customers can't be arsed to fill out a form to actually get that money.)
--
[0] - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...
We have tons of Confluence wikis, updated frequently.
As someone working on Confluence to XWiki migration tools, I wish this was remotely true, my life would be way easier (and probably more boring :-)).
I personally came to that conclusion thanks to the GrapheneOS situation regarding device attestation. Insecure devices get full features from some apps because they are certified, although they cite security, while GrapheneOS get half featured apps because it's "insecure" (read, doesn't have the Google certification, but are actually the most secure devices you can get, worldwide)
It's not about securing your device from external threats or bad actors; it's about securing the organization from any blame / wrongdoing.
Most organizations today are looking high and low to shove the blame to others instead of taking responsibility.
And then you have banks such as Boursobank (a French online bank) that has weak traditional authentication (and a faulty app, but they do not care) and out of the blue also provides passkeys. Making it at the same time horribly bad and wonderfully good.
The worst part is that they hide behind regulations when in fact there are only few of them.
Other instiytutions such as SWIFT are as bad and equally arrogant.
It would also stop a lot of genuine submissions unfortunately, as some literally can't pay not just won't pay (for both technical or financial reasons), and adds complexity¹. Each project working this way will need to process a bunch of payments and refunds on top of the actual bounty payments, which is not admin free nor potential financially cost free.
I can't think of an easy answer that would work for more than a very short amount of time. As soon as there is money involved and an easy way to use tooling rather than actual effort/understanding to be involved, many will try to game the system ruining it for those genuine participants. Heck, even if the reward is just credit² rather than money, that will happen. Many individual people are honest and useful, people as a whole are a bunch of untrustworthy arseholes who will innocence you and the rest of the world for a penny or just for shits & giggles.
> Assuming the host of the bug bounty program is operating in good faith
This is a significant assumption. One that is it harder to not be paranoid about when you are putting money down.
> they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password
This does not surprise me. My primary bank (FirstDirect, UK) switched the way I authenticate from “between 5 and 9 alphanumeric characters”³ to a 5-digit pin, and all their messages about it assured me (like hell!) that this was “just as secure as before”…⁴
--------
[1] Needing a payment processing option that is compatible with both the reporter and reportee, at the point of submission. At the moment that can be arranged after the bounty is awarded rather than something a project like curl needs to have internationally setup and supported before accepting submissions.
[2] ref: people submitting several simple documentation fixes, one misplaced comma or 'postrophe per pull request, to game some “pull requests accepted” metric somewhere.
[3] which wasn't ideal to start with
[4] I would accept the description “no less secure than before” if they admitted that the previous auth requirements were also lax.
You still need to complete a SMS auth to do anything other than view records though, like transfer money.
Could people who think they found a bug but not sure be turned off by the up front cost / risk of finding out they are wrong or not technically finding a bug?
It's credit cards that have to reimburse for fraud, but they charge the merchant for it, plus fees, so they have absolutely no incentive to prevent fraud, if not an incentive to outright encourage fraud. That would explain why their implementation of the already compromised EMV was further nerfed by a lack of a PIN in the US.
Ugh, I hate this. I've seen it in other places. Just waiting for them to decide that actually it should be an SMS or a phone call...
Unlikely to happen but it seems fun to extend email [clients] with uri's. It is just a document browser, who cares how they are delivered.
Your bank would not. Nor would mine, or most retail banks.
If the upfront cost would genuinely put off potential submitters, a cottage industry would spring up of hackers who would front you the money in return for a cut if your bug looked good. If that seems gross, it's really not - they end up doing bug triage for the project, which is something any software company would be happy to pay people for.
The problem is that bug bounty slop works. A lot of companies with second-tier bug bounties outsource triage to contractors (there's an entire industry built around that). If a report looks plausible, the contractor files a bug. The engineers who receive the report are often not qualified to debate exploitability, so they just make the suggested fix and move on. The reporter gets credit or a token payout. Everyone is happy.
Unless you have a top-notch security team with a lot of time on their hands, pushing back is not in your interest. If you keep getting into fights with reporters, you'll eventually get it wrong and you're gonna get derided on HN and get headlines about how you don't take security seriously.
In this model, it doesn't matter if you require a deposit, because on average, bogus reports still pay off. You also create an interesting problem that a sketchy vendor can hold the reporter's money hostage if the reporter doesn't agree to unreasonable terms.
For some reason they either didn’t notice (e.g. there’s just too many people trying to get in on it), or did notice, but decided they don’t care. Deposit should help here: companies probably will not do it, so when you see a project requires a deposit, you’ll probably stop and think about it.
If filing a bad report costs money, low quality reports go down. Meanwhile anyone still doing it is funding your top notch security team because then they can thoroughly investigate the report and if it turns out to be nothing then the reporter ends up paying them for their time.
From my failed attempt, I remember that
- Students had to find a project matching their interests/skills and start contributing early.
- We used to talk about staying away from some projects with a low supply of students applying (or lurking in the GitHub/BitBucket issues) because of the complexity required for the projects.
Both of these acted as a creative filter for projects and landed them good students/contributors, but it completely goes away with AI being able to do that at scale.
There are a lot of things to be sad about AI, but this is not it. Nobody has a right to a business model, especially one that assumes nobody will compete with you. If your business model relies on the rest of the world bring sucky so you can sell some value-added to open-core software, i'm happy when it fails.
The what now? Open source doesn't have a business model, it's all about the licensing.
FOSS is about making code available to others, for any purpose, and that still works the same as 20 years ago when I got started. Some seem to wake up to what "for any purpose" actually mean, but for many of us that's quite the point, that we don't make choices for others.
https://www.gnu.org/philosophy/free-sw.html
Being able to learn from the code is a core part of the ideology embedded into the GPL. Not only that, but LLMs learning from code is fair use.
I have to imagine this ideology was developed with humans in mind.
> but LLMs learning from code is fair use
If by “fair use” you mean the legal term of art, that question is still very much up in the air. If by “fair use” you mean “I think it is fair” then sure, that’s an opinion you’re entitled to have.
It is not up in the air at all. It's completely transformative.
LLMs don't (cannot, by design) provide attribution, nor do LLM users have the freedom to run most of these models themselves.
On another note, regarding AI replacing most open source code. I forget what tool it was, but I had a need for a very niche way of accessing an old Android device it was rooted, but if I used something like Disk Drill it would eventually crap out empty files. So I found a GUI someone made, and started asking Claude to add things I needed for it to a) let me preview directories it was seeing and b) let me sudo up, and let me download with a reasonable delay (1s I think) which basically worked, I never had issues again, it was a little slow to recover old photos, but oh well.
I debated pushing the code changes back into github, it works as expected, but it drifted from the maintainers own goals I'm sure.
This is not a technology, but ethics and respect problem.
From the same article:
> Not all AI-generated bug reports are nonsense. It’s not possible to determine the exact share, but Daniel Stenberg knows of more than a hundred good AI assisted reports that led to corrections.
Meaning: developers and researchers who use the tool as it's meant to work, as a tool, are leveraging it to improve curl. But they are not skipping the part of understanding the content of their reports, testing it, and only then submitting it.
I think you should try eating pudding with a fork next
Depends if you are in UK or not.
heck, my cousin bet with me or let me compete eating pudding with chopsticks. (and that was long before i went to china)
practically speaking, the only downside of using a fork (or chopsticks) is scraping the bottom when you are finishing up.
It's a shame since this technology is brilliant. But every tech company has drank the “AI is the future” Kool-aid, which means no one has incentive to seriously push back against the flood of low-effort, AI-generated slop. So, it's going to be race to the bottom for a while.
Stenberg has actually written about invalid/wildly overrated vulnerabilities that get assigned CVEs on their blog a few times and those were made by humans. I often get the sense some of these aren't just misguided reporters but deliberate attempts to make mountains out of molehills for reputation reasons. Things like this seem harder to account for as an incentive.
I had a sales rep even call me up basically trying to book a 3 hour session to review the AI findings unprompted. When I looked at the nearly 250 page report, and saw a critical IIS bug for Windows server (doesn't exist) existing at a scanned IP address of 5xx.x.x.x (yes an impossible IP) publically available in AWS (we exclusively use gcp) I said some very choice words.
To paraphrase a famous quote: AI-equipped bug hunters find 100 out of every 3 serious vulnerabilities.
So it’s still a slow and time consuming process.
https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...
First new word of 2026. Thank you.
[0] https://hackerone.com/reports/2298307
Seeing Bard mentioned as an LLM takes me back :)
Yes, this does not work for all vulnerability classes, but it is the best compromise in my mind.
Sure, it covers a very narrow scope but I am afraid the bigger issue would be that it is going to get spammed with submitted links. And those links will often be to strait up illegal content, it might not matter that such server instantly deletes all downloaded files.
Bounties are a motivation, but there's also promotional purposes. Show that you submitted thousands of security reports to major open source software and you're suddenly a security expert.
Remember the little iot thing that got on here because of a security report complaining, among other things, that the linux on it did not use systemd?
In many ways one of the biggest benefits of bug bounties is having a dedicated place where you can submit reports and you know the person on the other end wants them and isn't going to threaten to sue you.
For the most part, the money in a bug bounty isn't work the effort needed to actually find stuff. The exception seens to be when you find some basic bug, that you can automate scan half the internet and submit to 100 different bug bounties.
It depends to who.
> If you want to be deemed an expert, write blogs detailing how the exploit works.
That's necessary if you sell your services to people likely to enjoy HN.
https://hackerone.com/reports/3293884
Not even understanding the expected behaviour and then throwing as much slop as possible to see what sticks is the problem with generative AI.
This was partially the case before, where you'd still get weird spammy or extortive reports, but I guess LLMs enable random people to shoot their shot and gum up the works even more.
That is general trend in society now.
https://news.ycombinator.com/item?id=46678710
Am I doing this right?
Give it a presumption of guilt and tell it to make a list, and an LLM can do a pretty good job of judging crap. You could very easily rig up a system to give this "why is it stupid" report and then grade the reports and only let humans see the ones that get better than a B+.
If you give them the right structure I've found LLMs to be much better at judging things than creating them.
Opus' judgement in the end:
"This is a textbook example of someone running a sanitizer, seeing output, and filing a report without understanding what they found."
1. https://claude.ai/share/8c96f19a-cf9b-4537-b663-b1cb771bfe3f
I tried your prompt with https://hackerone.com/reports/2187833 by copying the markdown, Claude (free Sonnet 4.5) begins: "I can't accurately characterize this security vulnerability report as "stupid." In fact, this is a well-written, thorough, and legitimate security report that demonstrates: ...". https://claude.ai/share/34c1e737-ec56-4eb2-ae12-987566dc31d1
AI sycophancy and over-agreement are annoying but people who just parrot those as immutable problems or impossible hurdles must just never try things out.
It's the same as if you searched the web for a specific conclusion. You will get matches for it regardless of how insane it is, leading you to believe it is correct. LLMs take this to another level, since they can generate patterns not previously found in their training data, and the output seems credible on the surface.
Trusting the output of an LLM to determine the veracity of a piece of text is a baffilingly bad idea.
This is precisely the point. The LLM has to overcome its agreeableness to reject the implied premise that the report is stupid. It does do this but it takes a lot, but it will eventually tell you "no actually this report is pretty good"
The point being filtering out slop, we can be perfectly find with false rejections.
The process would look like "look at all the reports, generate a list of why each of them is stupid, and then give me a list of the ten most worthy of human attention" and it would do it and do a half-decent job at it. It could also pre-populate judgments to make the reviewer's life easier so they could very quickly glance at it to decide if it's worthy of a deeper look.
>However, I should note: without access to the actual crash file, the specific curl version, or ability to reproduce the issue, I cannot verify this is a valid vulnerability versus expected behavior (some tools intentionally skip cleanup on exit for performance). The 2-byte leak is also very small, which could indicate this is a minor edge case or even intended behavior in certain code paths.
Even biased towards positivity it's still giving me the correct answer.
Given a neutral "judge this report" prompt we get
"This is a low-severity, non-security issue being reported as if it were a security vulnerability." with a lot more detail as to why
So positive, neutral, or negative biased prompts all result in the correct answer that this report is bogus.
The problem is the complete stupidity of people. They use LLMs to convince the author of the curl that he is not correct about saying that the report is hallucinated. Instead of generating ten LLM comments and doubling down on their incorrect report, they could use a bit of brain power to actually validate the report. It does not even require a lot of skills, you have to manually tests it.
Brave new world we got there.