SD Times has been banging the software security drum for years. We’re not alone: Many consultants and analysts have been trying to focus everyone’s attention on unsafe coding practices. Security testing is taught in universities, built into IDEs, and incorporated into application life-cycle management stacks and source-code configuration tools.

What are the goals of most development teams? Develop code on time, on budget, that meets requirements. Those requirements rarely incorporate application security (beyond the phrase “be secure”). That’s why we still see unchecked buffers, code that can fall prey to SQL injection, bad hashing techniques, flawed crypto algorithms, passwords transmitted in plain text, cross-site scripting vulnerabilities, you name it.

We know how to solve these problems. We have known how to solve them for years.

What’s the answer? We keep beating on this drum, and so do other voices. We are pleased that a vendor consortium, called SAFECode (Software Assurance Forum for Excellence in Code) has jumped in.

SAFECode has released a 33-page document called “Practical Security Stories and Security Tasks for Agile Development Environments.” Despite the unwieldy name, for the most part the paper is a clear, objective set of prescriptive practices for secure coding. Particularly strong is a listing of 36 security-focused agile stories, backlog tasks and fundamental practices. This should be required reading, as should a shorter list of operational security tasks.

A previous document from SAFECode, called “Fundamental Practices for Secure Software Development,” was revised in 2011 to cover the design, programming and testing parts of the software development life cycle, going beyond the first edition’s look at requirements, training, code handling and documentation.

There are many other efforts in the industry to improve secure coding practices, beyond SAFECode’s papers and insistent carping by the editors of SD Times. There are books, conferences, you name it. The place to start is at the top, not at the bottom. Talk to the suits, not the IDE jockeys.

If your organization’s development management, IT management and executive management lack a consistent focus on secure architecture, design, coding, testing and deployment, all the preaching and training in the world won’t make a difference. But if the brass make it clear that security must be part of every requirement, every QA review, every design document and every training session, that’s how it will get done.