There are actions we DBAs can take to prevent unauthorised intrusion and some we can't. We can't ensure that the server room remains unbroken into. Nor can we ensure that SQL Server remains unexploitable and unexploited. We can, however, ensure that our servers are patched and up-to-date, both OS and SQL Server.
In regard to SQL Injection, we can but insist that the programmers verify all inputted data but we can't proof everything that they write. We can lay down rules for access to the DB servers. What we can do is assign the application user a public role with explicit access to the application-specific stored procedures it needs to do its job. We can assign a specific schema for objects the application may use. If the application is cursed with Entity Framework, we can allow specific read and write rights to specific tables and or columns where appropriate. Under no circumstances, do we assign it dbowner or SA roles.
We can take a paranoid attitude to login and user rights. No one outside the DBAs gets write rights or alter rights on production DBs unless explicitly authorised by the board of management. We can ensure that sensitive data or sensitive databases are encrypted, for our safety as well as that of the datas'. We can check often (and not regularly) who has what rights to what DB-servers and DBs.