Because that's expensive and time-consuming to set up, and the ROI is often not there compared to spending those same resources on professional help.

Also, be careful what you wish for. A bug bounty that doesn't come with rules of engagement for a staging site to test is one that gives you permission to test the company's real properties. A bug bounty with staging server rules of engagement is one that doesn't, and you can be sued or even prosecuted for hitting the real servers in that case.

As a rule, big companies with bug bounties are never relying on those bounty programs. When a giant company announces a bug bounty in 2015, they're outing themselves as early adopters (relative to the F500); they'll have been spending buttloads of money on pentesting already.

It's basically an additional QA or acceptance environment, capacity being a fraction of what is running live, that's no more costly and time consuming really then all the effort it takes to setup a bug bounty program, and you can get far more useful take aways from it if they can fully red team it. If someone finds an exploit that takes down the system or compromises account data, no real data or systems are at risk, no more so then they would be to actual malicious users.

The rules of engagement would obviously limit you from testing the real properties and restrict you to said servers that are completely isolated from the working production environment. DDOS attacks would be things that hang the application, or database, not simply flooding it with bot requests. Then they could do code injection, etc.

I spent 10 years negotiating for complete staging environments for professional pentests, on engagements with a median price somewhere in the mid-5-figures, and we rarely got them. Whatever you may think about the simplicity of setting up staging environments on a message board, they are empirically not easy in the real world.

There was no correlation between how savvy the target was and how likely they were to have staging environments for us. The modal organization that gave us a complete staging environment tended to be back-office IT for some huge company. Smart startups virtually never did.

One reason for this is that the environment a pentester needs is different from the one a developer needs. Large portions of the production environment can be stubbed out for a developer, and they can still get testing work done by focusing on their own component. Virtually every part of the environment needs to work, the way it does in prod, for a tester to do their job.

I'm still unclear on why code injection is such a big deal. The company isn't saying you can't test for vulnerabilities that lead to code injection. They're saying you can't actually inject code. There are two reasons you might, as a tester, want to do that: first, to "pivot" through the target to find more vulnerabilities, and second, to confirm a sev:hi flaw.

Neither of those goals are important here, as long as the company is good about acknowledging prospective sev:hi flaws.

Also, it adds ongoing costs to change management, as now you have to modify two environments for each change, test two environments, ensure data is refreshed into your non-prod environment (while ensuring you don't use production data in it), monitor two environments, pay licensing and support costs (hardware and software) for two environments, etc.

Having a secondary 'test' environment isn't as easy as 'oh just clone the VMs'.