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.

Go ahead, read these papers, share them with your team—and remember that security is a top-down process.

DevOps is not merely vendor hype
Too often, the technology press can get swept up in the vendor hubbub. Just look at SOA: While some elements of Service-Oriented Architecture remain, about three years ago everyone began to figure out that, for the most part, SOA-focused tools were essentially useless. If SOA tools were ever of any use, they wouldn’t have dropped off the face of the Earth when cloud and RESTful Web services took over. SOA was, for the most part, vendor hype. But the problems it was supposed to solve were, and still are, very real.

One thing that is not merely vendor hype is Development Operations, or DevOps. While vendors are now making tools targeted directly at DevOps-oriented teams or professionals, this should not be confused with those tool companies driving the market. With SOA, the entire process was driven by businesses and standards efforts, rather than by users in the field trying to solve problems.

But that’s why DevOps is so real and tangible: It is a user-developed solution to the problems that arise when Development goes agile, but Operations stays the same. Another name for the movement could simply be “Agile Administration with a Focus on the Cloud.” But frankly, AAWAFOTC isn’t as cool a name as DevOps.

So while big companies tout tools and their pet analysts bespeak best practices that require those tools, remember that DevOps is essentially about one thing: Operations and Development coming together to build deployment environments quickly, collaboratively and in an optimized fashion. This is why, for many organizations, DevOps is all about Puppet and Chef, and this is why an outsider could be forgiven for mistaking it for some merging of the two disciplines.

In truth, DevOps is less about merging Development with Operations, and more about collaboratively designing the environments into which applications will be deployed, and then deploying those environments in an agile fashion.

Now, try defining SOA in a single sentence… if you can even remember what it is.