Answer: You don't and can't

Slashdot has a lengthy discussion on this subject and while there's a plethora of suggestions and advice on how to know your code is secure in the end the only right answer is still that you can't.

There are too many variables involved, and if you're using any kind of third-party library then the variables in the equation increase exponentially. The truth is that security and applications must always assume the truth of Heisenberg's Uncertainty Principle: you can never be 100% sure of anything in regards to a physical system.

You can, however, mitigate risk in a variety of ways:

  1. Thorough peer code reviews
  2. Implementation and enforcement of organizational deployment standards requiring source code vulnerability assessment checks
  3. Periodic vulnerability scans of applications
  4. Deployment of an application firewall

Developers tend to agree with #1, #2, and even #3, but balk at #4. I say that the investment in an application firewall such as Traffic Shield is minimal when compared to the monetary penalties resulting from the exploitation of a vulnerability missed by the first three tactics.

And let me ask you this: do you go through #1 and #2 after the application has been deployed and a new vulnerability has been discovered? Yeah, exactly. Once the code has been deemed secure enough to be deployed it's rarely re-checked upon discovery of new exploits roaming the wilds. Even if you do employ tactic #3, how often is it applied and does a formal process exist to address new vulnerabilities discovered?

An application firewall deals with unanticipated and newly discovered exploits and prevents them from reaching your application. Sure, you may already be secured against a plethora of known attacks but unless your organization is particularly paranoid they don't require that you re-check, re-code, and re-deploy applications on a monthly - if not more frequent - basis, which is what it would take to ensure you're always up to date.

An application firewall complements existing security practices within the organization by adding another layer of security. It isn't meant to replace secure coding techniques nor should it be treated as a cure-all for all your application security woes, though they certainly can and are deployed as such in some situations. These products assist in maintaining the highest level of security possible within your organization. By stopping attacks before they reach the application these products provide the opportunity for developers to update code and re-deploy without fear of an attack penetrating their application in the interim. That means you don't have to work around the clock to address a vulnerability and you won't skip steps #1 and #2 in order to hurry a fix into production that might result in the introduction of other vulnerabilities.  

It's because you can't know for certain that your code is secure that these products exist. And while these products won't change the uncertainty of secure code, they can increase the certainty that those insecurities that do exist won't affect your application and its underlying infrastructure.

Imbibing: Coffee