In my (admittedly limited) experience, whilst payouts for bugs might be seen as a positive internally, payments for bad architecture/configuration choices are less so (perhaps as they're difficult to fix, so it's politically not expedient to raise them internally).

To provide one example I reported to a large cloud provider that their managed Kubernetes system exposed the Insecure port to the container network, meaning that anyone with access to one container automatically got cluster-admin rights. That pretty clearly seems like not a good security choice, but probably hard to fix if they were relying on that behaviour (which I'm guessing they were).

Their response was to say it was a "best practice" behaviour (no bounty applicable) and that they'd look to fix and asked me not to publicly mention it. Then they deprecated the entire product 6 months later :D

That's one example but I've seen similar behaviour multiple times for things that are more architecture choices than direct bugs, which makes me think reporting such things isn't always welcome by the program owners.

Repeating myself: this almost certainly has nothing at all to do with the money they'd have to give you (I assure you, if there's even a whiff of legitimacy to your report, the people managing the bounty would probably strongly prefer to pay you just to get you off their backs) and everything to do with the warped incentives of paying out stuff like this. People forget that the whole point of a bug bounty is that the rewarded bugs get fixed; the bounty is directing engineering effort. If it directs them to expensive work they already made a strategic decision not to do, the bounty is working against them.

You would prefer this company to have made a different strategic choice about what to spend engineering time on, and that's fine. But engineering cycles are finite, so whatever time they'd spend configuring K8s differently is time they wouldn't be spending on some other security goal, which, for all we know, was more important. Software is fathomlessly awful, after all.

Yep that's the point I was making, they don't want to pay out on architecture/configuration changes if making those would be expensive/difficult.

That doesn't mean the report isn't legitimate (being cluster-admin with no authentication is generally considered not to be a good security idea, in fact it's about as bad as it could get without putting the insecure port on the Internet), but that bug bounties aren't architected to accept that kind of issue. The challenge with this is it means that bug bounty researchers won't look for that kind of (legitimate) security issue as they get to know the programs often won't pay out.

Personally, I don't ever report bug bounties for the money reward, but so I don't get shouted at by companies when I write a blog or do a talk that covers the issues :) In this case I was a bit annoyed that they combined telling me it wasn't a bug, with asking me not to mention it publicly for 6+ months (IIRC they credited me like years after the fact).

Yes. Bug bounties are not a panacea, and were never intended to be. They have specific goals, and those goals surprise technologists working outside of the security teams that run the programs. They make a lot more sense when you remind yourself that they (a) direct engineering efforts and (b) create profound incentives; those facts together sharply constrain the problems they can be applied to.

> and asked me not to publicly mention it

Sounds sus. If they said it's "best practice" then certainly they'd want you to tell everyone about it.

If a bug bounty is denied I'd assume you're free to talk about it publicly.