Secure coding guidelines: Are they the answer to buggy software?

People are using flawed software. And, the bad guys love it. A recently formed group called the Open Web Application Security Project is working to improve secure coding, but is it practical?

The debate rages on as to why software is vulnerable. That's good, but should not overshadow a larger problem: our increased complacency about using flawed software. In a previous article of mine: "Buggy software: Why do we accept it?", I asked several TechRepublic writers why that is.

The people who responded as well as the members who commented offered a wealth of advice. But, how does that get translated into solutions?


I recently became aware of the organization, Open Web Application Security Project (OWASP ). If you are not familiar with the nonprofit, here is the group's mission statement:

"OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. We advocate approaching application security as a people, process, and technology problem. Because the most effective approach to application security includes improvements in all of these areas."

OWASP has several ongoing projects, all tasked with the following:

  • Protect: Create tools to guard against security-related design and implementation flaws.
  • Detect: Develop tools to find security-related design and implementation flaws.
  • Life cycle: Design tools to add security-related activities into the Software Development Life Cycle.

Secure coding project

The project that caught my attention is the Secure Coding Practices Quick Reference Guide Project. The team's goal is to reduce software vulnerabilities by following best-practice guidelines. To that end, they just published their Quick Reference Guide :

"A technology-agnostic set of general software security coding practices, in a comprehensive checklist format, that can be integrated into the development lifecycle. The focus is on secure coding requirements, rather than on vulnerabilities and exploits.

It includes an introduction to Software Security Principles and a glossary of key terms. It is designed to serve as a secure coding kick-start tool and easy reference, to help development teams quickly understand secure coding practices."

One of the project members, Keith Turpin, gave a video overview of the reference guide and what OWASP is trying to accomplish with it.

Some questions

Since software development is not my forte. I decided to enlist Justin James, TechRepublic's Programming and Development host. Better for everyone, that Justin offers his opinion on what OWASP is trying to accomplish. Here is what he had to say.

TechRepublic: As a software developer, what security practices do you enlist in the writing of software? Justin James: To be honest, I don't have a defined set of security practices. I pay attention to error-density rate. In my opinion, it is what differentiates good programmers from bad programmers. Everything equal, bad programmers have a higher error count. And, that translates into more exploitable vulnerabilities.

The following points are things a security-conscious programmer should do:

  • Writing clear, concise code: If the worst developer on the team cannot understand it, it is too complicated. Being able to understand the code and find/track/fix bugs is critical.
  • Not using C/C++: I've been writing the Patch Tuesday piece for a few years now. I see the security issues that come up. Time after time, the root cause is a buffer overrun issue. Among the first and second tier languages (in terms of usage), only in C/C++ do you have the ability to write code that lets this happen!
  • Stand on the shoulders of giants: I, like the experts, do things like write encryption algorithms, and leverage validated libraries, components, systems, etc.; both open and closed source. I also pick my providers with care.
TechRepublic: What do you look for in software written by other developers? Based on that, what is your opinion of security practices currently being employed by software development firms? Justin James: Most security practices are efforts to mitigate risk and damage introduced by hiring bad developers. Truthfully, the industry is filled with fakes, frauds, and phonies that get hired out of desperation and kept around in the hope that they will improve.

I've been behind the hiring desk, and when you have a critical project waiting on manpower, you don't spend nine months finding a top programmer. I'm not talking about "rock stars" either. I mean plain, old fashioned, excellent programmers. They are rare.

My previous answer addresses this one as well: Can they write efficient, clear, concise code that does exactly what is asked. If the spec is vague, can they competently fill in the blanks?

There's nothing wrong with security practices for code development, mind you. But, they would not be needed if, as an industry, we found a way to have qualified programmers focus on helping less-qualified developers write good code. Right now, programming is still Sanskrit and we don't even know about zero yet.

TechRepublic: What is your perception of OWASP and its role in the software industry? Justin James: I don't really have much of an opinion on them one way or another. But, going to their Web site and looking at their .NET Project, the information is out of date. I sampled about 25% of the articles and they were all at least five years old, which is a lifetime. TechRepublic: Having read the reference guide, what is your opinion of it? Does it touch all the right subjects? Justin James: Nearly all of the guidelines are tactics I hope developers are using anyway. That said, there are some "security theater" items in the list. For example, why say "invalid username/password" to obscure that a username exists, when "forgot password" will tell an attacker if the username is no good?

For the most part, it's a good guide. To implement all of the procedures would require a significant amount of code. Luckily, working within many of the popular frameworks will achieve the same thing.

TechRepublic: The Secure Coding Practices Reference Guide mentions that specific members of the development team should:

"Have the responsibility, adequate training, tools, and resources to validate that the design and implementation of the entire system is secure."

Is this approach currently be used? How important is it to have people with this skill set?

Justin James: Sure, forming a specialized team is possible if you are on a million-dollar project and have plenty of time. That is not the case for most developers. Following the guide would overtax their budgets and schedules.

Furthermore, software packages are increasingly large, complex, and difficult for individuals to grasp the code entirety. So, how are these specific members going to make a difference? What I consider a workable approach is having everyone involved buy into using secure development practices.

TechRepublic: Will software development companies have sufficient interest/motivation to use the check list outlined in the reference manual? Justin James: The key word is "sufficient". The failure of most companies to make security a priority is proof there is "insufficient" motivation. The OWASP list is nice, but it isn't anything we haven't seen before. In fact, I was familiar with the non-web specific material back in high school. TechRepublic: Finally, I wanted to ask if incorporating the checklist into the development process is the answer. If not, what in your opinion is needed? Justin James: I think the check list is part of the short-term answer. But, everyone has to realize something. It will take developers months to determine how OWASP's secure coding practices relate to their frameworks of choice, what changes are needed, and what code is required to address the changes.

In other words, it is difficult to turn this list into a set of recommendations for every situation. What's needed is to cross reference this checklist with system capabilities, using simple checkboxes. That way, the developer knows where they can breathe easy and where they need to work.

Long term, the secure coding checklist by itself, is not the answer. The amount of code needed to cover all the bases is ridiculously high. It would take weeks to get a basic "hello world" application 100% compliant with this list in the average system.

The answer is to have development frameworks and systems secure by design. Then, have developers build on their already-secure framework. Doing so will increase the probability of the entire software package abiding by the secure coding practices guideline.

Final thoughts

As I mentioned earlier, the members have plenty to say about buggy software. Do you think what OWASP is trying to do will gain traction? Is the checklist something you would use?

Thanks are due to Justin for his insight and taking the time to answer my questions about secure coding.