As usual, when you trust a piece of code without reading the source, the fail will be strong.
This is like java's GUID that are random but not unique, etc. you can't guess it from the function name or description, you need to know the internal process to know how it's going to explode and when.
95% of even good developers wouldn't be able to tell when a sql sanitization function is poorly coded or has a hidden gotcha. Having the source is not nearly as important as trusting the upstream to be smart and to promptly resolve security issues when discovered.
I trust noone. except maybe the pgsql guys.
However, imho on the topic of SQL injection, either escaping the escape characters is enough or you should change DBMSs / APIs right away.
But really, security without reading sources is blind more or less calculated risk, not security.
That's a really strange way of looking at things, in my opinion. There are things in life that you just have to trust implicitly. I'm not saying someone else's code falls in that category but just because it is open source and you can supposedly discover any caveats or security risks on your own does not make that task truly reasonable. I'm not in a position where I can read through all of the source code for MySQL, Apache, Passengers, Rails, Ruby, etc in order to make sure that someone hasn't made a mistake. To be honest, I'm not sure that I would recognize an error like this by just reading the code.
What do you do with proprietary/closed source software? What do you do with hardware that is just as capable of poorly implementing security? What about poor decisions that really only become apparent after a security hole is discovered?
First, I don't believe I need real security, that protects me from most of the worries you cited.
I know it's not safe, and I don't care.
It's like mail or gmail or anything, I know someone has access to my data, and I don't care because it's unavoidable/ not an issue.
You have to trust, but actively try to prove wrong, that weeds out most of the crappy software, like MySQL, MSSQL (lolwut 32 trigger chain?lets cut it here silently) or others.
You have to base your decision on stuff that really works rather than the latest fad, so fck ruby and all that crap, write in C, that's safe, proof is even the chinese and the military have their OS written in C.
Proprietary/closed source, you remain paranoid, test it yourself for what you can think, never think it cannot be the cause.
Hardware you cannot trust, have to learn where the limitations are, remain paranoid as well, question the status quo (is ECC really doing its job or am I just trusting my enterprise data to magic).
Poor decisions that you realize later ? everyone makes mistakes, who cares ?
IMO the main thing is, don't trust anyone to do it right, especially in IT, sometimes you come to trust a specific group, like linux kernel or pgsql because they're proven right time and again - and imo you have to leave it there, I don't want to write an OS at the moment.
Most poor security decisions are related to trivial things like:
-using windows
-not updating your OS / kernel / tart
-using testing tech, like the latest release of ruby, node.js, mongolianDB, etc.
-not researching tech before using it (i.e. google mysql ACID, you'll read a few of my posts from when I was pissed off to discover it was in fact just a toy db with half-implemented features)
-not actively trying to hack/destroy your own creation
-not spending a few K on a honeypot session
-not actually knowing anything about hacking
-not reading about standard hacking tactics, like SQLi for nubs, XSS, MitM HTTPS, tomato launchers and many more
etc. I'm no security pro and I wouldn't pretend being one before winning several honeypots.
This is like java's GUID that are random but not unique, etc. you can't guess it from the function name or description, you need to know the internal process to know how it's going to explode and when.