I think that vendors should react faster when a vulnerability is identified. Putting it on the some-time-maybe-never inclusion in the next release simply isn't good enough.

Similarly it would be a great to see commercial software relying on a database showing evidence that it has had a thorough going over by a professional DBA. There are a number of systems with flashy front-ends and/or even relatively bug free code but rely on elevated privileges in the database.

One thing I have come to realise is that if you see a DB with weak design then it will be fronted by code with a weak design.

Where a single individual is responsible for a product then you can put it down to individual lack of knowledge. Where it is a team that produces a product then it is more likely to be a systemic attitude within the organisation.

My principles for attempting to design a secure database are as follows:-

• Look to minimize the attack surface area
• Make sure that functional interaction with the database is tightly defined, not open ended
• Make sure the audience for each function is tightly defined
• Do not abdicate responsibility for security to the n-tiers above the DB. Security is a war of attrition. Every layer of security will lose a proportion of hackers even if it is through loss of interest rather than lack of competence
• Don't use default settings (including TCP/UDP ports) or accounts

Isolate the stuff you want to keep secure, don't keep it in the same schema, preferably not the same DB and even go as far as to have a specific server. If it is that important to you then it is worth the cost.