Recently there has been a lot of talk in the security community about the Flash ActionScript exploit written by Mark Dowd (http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf). I will not go into a breakdown of the exploit as others have already done a great job of blogging about it. What I would like to discuss is two big takeaways that even programmers who are not "uber-hackers" can appreciate.
The first takeaway is the importance of understanding and implementing the fundamentals. The exploit above occurs because of a NULL dereference triggered by an out of memory return by malloc(). I remember in my first C programming class when I was working with a partner an a project and he was trying to properly implement malloc(). I had already been using C for a few years and always checked the return of a function. I could not figure out why he was not checking to make sure sufficient memory had been allocated. He gave me the excuse that it would require a lot of code to check the return value and that since the data structure was small the allocation would fail. Nonsense, as I demonstrated by filling up the 640K of standard memory. He then argued that we would be better off implementing XMS or EMS to access the other 3MB of "high" memory, a silly argument if ever there was one.
When non-security professionals describe what hackers do they often say that hackers look for ways to bypass restrictions and go around roadblocks. This is a somewhat fair description, but what they may not know is that often hackers are merely taking advantage of mistakes or the faulty reasoning of programmers who tried to skip or work around something simple or basic that they felt would be too much work to implement properly. The original "hacks" were simply ways of getting things done quicker, easier, or more elegantly but sometimes there is a fundamental reason for doing things one way and the "hack" just gets you into hot water. Anyone who has ever picked up a C programming book and looked at the function info for malloc() knows that it is NOT guaranteed to return the memory requested. Obviously, it is a BAD idea to simply assume that it succeeded in allocating all the memory requested. Know your functions/methods and how to properly implement them.
The second takeaway for the average programmer is the need to integrate and leverage the latest in security functionality in your code from the ground up. What do I mean by this? Follow-up research on the exploit has shown that if DEP had been turned on and opted-in the exploit would not have worked. DEP marks portions of memory as NX (No Execute). Such areas in memory will trigger a processor fault if an attacker attempts to execute shellcode they have somehow loaded into such memory. Is DEP a panacea- No. But it provides a second layer of defense. Now you might say- DEP is a system setting that users or admins or Microsoft can turn on or off, there is nothing I can do as a programmer. This is not true. First of all, you need to write your application to make sure it works properly with DEP turned on. You need to test your application to verify this. You need to inform users so they know they can safely use DEP with your application.
A number of other features like ASLR (Address space layout randomization), /GS (canary based buffer overflow detection), etc. are provided now by Visual Studio and other compilers or by the latest versions of the Windows operating system. Developers should be building their code to use these basic security tools that are in most cases so easily integrated. None of these features can prevent all security threats, but there are many applications out there using outdated compilers or failing to implementeven the simplest of automated defenses for lack of awareness or a fear of performance degradation. To the former- browse through just a few of the numerous security respurce out there and then review your compiler/linkers security related flags; to the latter- given the massive code bloat in this object oriented development world compared with the (good) old days of hand tuned assembly in a COM file what is a one or two percent more overhead 
.