Compilers are generally supposed to make your code as efficient as possible – removing execution paths that seem superfluous is a feature that makes everything run faster. And while it may be well-established behavior, there is always danger when the behavior of code is opaque to the coder.

At worst, the maintainers of development tools need to leave developers in a security-neutral state.

The natural next question to ask is, could compilers provide options to make code more secure? Developers face significant challenges in trying to prevent attacks. Being knowledgeable about all of the existing methods for attack is a daunting-enough task.

Being perfect in applying prevention techniques when adding or changing code is even more difficult. And if it is difficult for security professionals, how are the part-time dabblers going to fare? Could the compiler, by default, fill the holes where you have failed?

Maybe. There is some precedent that might indicate we could head in that direction. Static code analysis tools will warn you about an array of potential security issues, but they stop short of modifying any code. If you can deal with the noise they produce, they can help.

Closer to the compiler are development frameworks, some of which have begun to make safe behavior the default. Frameworks like Django and Grails, for instance, will provide some protection against XSS and CSRF attacks on the front end, or SQL injection attacks on the back end. A developer would need to explicitly opt out of a secure implementation where there is a business need rather than needing to remember each time.

The challenge with frameworks and compilers is that the lower you go in the technology stack, the less context you have to make decisions. When you write code, you know to a large degree who will be using it and what they will be trying to do. You can put security logic in exactly the appropriate places based on the use cases.

A framework has no knowledge of the user or use case, but at least knows where a user is able to input information – it can safely add the overhead of checks in well-known interaction paths.

A compiler doesn’t know whether a function call involved direct user input, and could potentially introduce huge slow-downs by attempting to, say, check for buffer overruns everywhere; but if it could figure out or be told the right context it could provide an additional layer of security without any developer interaction.

As security awareness grows across the industry, the basic tools and infrastructure required to produce code will need to remove the risk of damaging side-effects in optimization. As they do so, let’s hope they take the opportunity to explore solving the difficult problems of security.

While there is certainly danger in introducing logic at such a low-level, doing so could provide a great service to us all by making security less dependent on the knowledge and diligence of the developer.