I have consulted at a lot of firms. From small to enterprise, most I have been at lacked adequate security and many violated the simplest of standard security procedures. I would run into policies about how they didn't want a developer having access to a production server, yet passwords were stored in plain text, servers went un-patched and there was little to no intrusion security protection. Hell, I found developers at more then one place, hacking into their own production servers to "fix" critical issues after hours with management being fully aware of it and turning a blind eye. Hey dumb ass, if your own developer can do it so can others.<p>At one mid-sized firm, they had personal data on millions of consumers, yet every password issued to clients and staff was defaulted to the same one and no user was ever forced to change it. Passwords were stored in plain text as well, and on a number of occasions I saw internal and external people log into the platform as another user to see the data they shouldn't be able to.<p>The answers I have heard consistently as to why not fix it; it isn't a priority, too many things "might" break, there is no revenue in fixing it, no one cares about us enough to hack us. The last one always makes me laugh, true, at most of these places no one had to care to hack them because hacking would imply that it would require effort.<p>At least in my experience, most good developers care to implement security, but are many times overruled because of either schedule or cost. I generally don't give a breakout of security procedures or time estimates (about security) simply to avoid bone headed decisions on removing security. However, when someone else is paying the bills and I am being directed to do something, I will raise the issue if I think it is wrong, document my objection and then implement what I am told so I can get paid while I find a new client or place to call home.