There's probably a kernel of truth to your comment, but that last graf makes no sense. The "security specialists" aren't writing the code with vulnerable direct object references; the "average decent developers" are. It's true that there are consultants out there that don't improve the (poor) seaworthiness of typical developer output, but few of them are so bad as to make the situation worse.
And, the notion that "good" developers turn out uniformly secure code is delusive. We're lucky to have gotten to work with some of the best run, most carefully recruited teams in the industry. You find terrifying things on all these engagements.
My advice, again as a practitioner: if your security firm isn't finding terrifying things, at least on the first go-round with an app, ask very tough questions. Ask if they need an extra week or two to catch up and get real findings. Then ask which of the two of you should pay for those weeks.
We are still finding code execution on a good chunk of our web gigs, even at the "good" companies.
Just as a corroborating point, although I'm not a professional security developer I've been an interested bystander since I was a stupid, self-taught, grey hat 16-year-old 5 years ago.
Anyway, I once found myself writing some PHP code to demo a slightly complex SQL injection attack for the class I co-lecture at Northwestern (Network Security and Penetration). This code purposefully had a SQL injection vulnerability in it. It wasn't until the third reading of my own code that I noticed that I mistakenly dropped a CSRF vulnerability in alongside it. CSRF was literally the topic I was teaching next Monday and I put one into my own security code accidentally.
Secure code is so difficult to write that I can't believe that even the best developer writes secure code much of the time. Hell, apparently even I can't write secure PHP when I'm looking straight at it.
I worked at a company where we had an individual hired as a "security specialist" who wrote code and got more or less a free on his behavior and approach. I suppose that's different than a full security consultant.
Your pentest firm should not be writing code for you. That conflict of interest is pretty obvious. If I had a consultant doing that for my company, I'd retain a rival firm to review the code, and make sure both the consultant coder and the pentester team knew about each other.
If you told me someone at, say, iSec Partners (a firm I like) wrote something I was pentesting, I'd go f'ing nuts trying to find flaws in it. If you told me iSec was reviewing something I wrote, I'd stay up nights thinking of ways to shore it up.
And, the notion that "good" developers turn out uniformly secure code is delusive. We're lucky to have gotten to work with some of the best run, most carefully recruited teams in the industry. You find terrifying things on all these engagements.
My advice, again as a practitioner: if your security firm isn't finding terrifying things, at least on the first go-round with an app, ask very tough questions. Ask if they need an extra week or two to catch up and get real findings. Then ask which of the two of you should pay for those weeks.
We are still finding code execution on a good chunk of our web gigs, even at the "good" companies.