Database source code analysis can flush out weakly-authenticated database users, over-privileged users and roles, or stored procedure code that concatenates a parameter directly into the dynamic SQL string that is to be executed, and so is vulnerable SQL injection. This is great for the development team, but it is also wonderful for the hacker.

Getting hold of the results of static code analysis for a database could save the attacker a lot of time. To know even just the names of tables can save hours of work in a SQL injection attack. If you know the columns too, then it all becomes easy. Getting the code for views and routines is a gift. Knowledge of where the vulnerable areas of the databases lie, makes the hacker’s task much easier.

Does this mean that database source code analysis is a bad thing? Not at all: it just illustrates how important it is to get database source control security and access control right. It also emphasizes how misleading it is to assume that database source control as just the same as application source control. It isn’t. In many organizations, the finance and medical professions in particular, the live database will be subject to rigid security procedures, enforced by legislation; users will only be able to see those parts of the database to which they have the appropriate access rights. To comply with current security standards, even database developers will only be able to view or change database objects that are within their remit. To make the source accessible would be to subvert all this security!

No, the source will need to be ‘tied down’ too, so that it reflects the access control regime in place within the database itself. It doesn’t mean more security: just consistent security. It’s likely that application developers, for example, will have access only to the published interface, rather than the underlying base tables and routines. Likewise, the reports from source code analysis that expose this metadata will have to be restricted.

We can all agree on the many advantages of database version control, but as always for certain organizations the way it has to be implemented is more nuanced, and requires a lot more careful planning than one might first anticipate.