I am currently finishing a college degree in programming and I find that security topics are often barely understood by both students and teachers. It leads me to think that there are a lot of developers out there with nearly no basic knowledge about security. I will eventually work with those developers and I am a bit clueless about how I can, as a programmer, help them to be aware of security issues and keep them informed about security issues. What are the good approaches and what are the things to avoid?
If you work with these developers on a coding assignment or some other project, you can bring up security issues while you're working together. That could either be during "pair programming" if you work that way, or as part of a code review.
Should you choose this approach, you need to come up with realistic problems based on actual threats. If you mention every paranoid possibility for attacks, then it's likely you'll just annoy people and not get your message across effectively. Even when I was working for a security vendor I found the paranoiacs frustrating.
Take a look at this question What security resources should a developer follow? as this is geared for developers.
If you want a more information, take a look a these links:
I have worked in very development centric environments during my career, and can confirm that "most" developers will always take the shortest route to victory, and short-cut wherever possible unless it causes slow code execution. Typically Security concerns just don't get a look in at all.
There is no right or wrong answer to this as every developer / development group has a different dynamic and responds in different ways. That said, there are things you can do, such as:
Invest in some in-house secure coding training. Most major PenTest houses will offer this as a service where they will send along one of their brightest and best to come and work with your devs for a period of a few days, walking them through the perils of not escaping characters and leaving buffers unchecked :) This is a great starting point as it gets them at least starting to consider the error of their ways, but it shouldn't be in isolation or a one off activity.
Next you may want to try running a bit of an in-house capture the flag / hack-fest that gets them all working in an attack and defend capacity to really start living the issues they inadvertently create. Free Beer & Pizza usually helps drive these sessions :)
After that, for me, the next step in the equation is giving them the tools and intelligence they need to fix these problems at source as they go. Most Pen Test boutiques will tell you that the only people that should/can do code analysis are trained Pen Testers with years of experience. This, of course, is a sales based lie. There is some truth to it, in so much as a seasoned source code reviewer can trawl through thousands of lines of code much more efficiently than your average developer, when they are looking for bugs, but what if the developer actually does this as they code? in that case, the developer is going to be more efficient than the pen tester, and this is where this starts to pay dividends. Essentially, grab a bunch of free source code review tools such as AppCodeScan, Checkstyle, Hammurapi, JCR (Java Code Reviewer) o2 OWASP and then make them part of the developer build, and give them the time they need to get up to speed with them. If your devs can drop the latest function they wrote, or major change, into a quick and dirty tool like the above before they hit compile, and get a clue that something is going to cause an issue, they can fix it quick, pre release, pre alpha even.
The final part of the equation for me is that pre and post release pen testing MUST feed the results back into the development cycle, so that the developers can see the issues they cause and put strategies in to stop repeat offending. Sounds simple, but is often overlooked!
As I said at the start, there is no right or wrong answer here, but hopefully the above may give you an idea or two to go away and play with.
I suggest finding something like a local chapter of OWASP, or something like that.
Go to their monthly meetings (or whenever they have it), and bring your colleagues with you.
Even if some of the lectures may not be relevant, it will bring security to the forefront of their minds, and get them thinking about it. Usually, you'll get some really great content too.
Give them a CISSP course / certification. It is better for their career, is internationally accepted and covers basic concepts of security in depth. However, don't expect them to become experts on one area in security. So programmers won't become software security experts, but at least they will be very well aware of security threats.
Besides "forcing" them to do CISSP is easier than forcing them to read blogs or websites. You can "sell" getting CISSP certification by presenting it as something useful for themselves which helps them in their career.