Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Experts flunk out on secure coding practices

A recent survey shows software professionals have a basic understanding of application security concepts, but they lack the knowledge to fix the resulting security issues.

When it comes to secure coding practices, software pros and the businesses they serve fall woefully short.

That's a big problem in a business climate where security breaches at companies like Target, Home Depot and JP Morgan Chase make headline news. If software pros understood how to write attack-resistant code -- and top management made secure coding a priority -- perhaps these and other data thefts could have been prevented.

Secure coding practices -- writing software in a way that leaves no holes open to attackers intent on stealing data -- is not a new idea. Application security experts have been spreading the secure coding message for more than a decade. "The way you change the security of software is by changing the way it's built," said John Dickson, a principal at application security consultancy Denim Group in San Antonio.

But this message still falls on deaf ears. A 2014 survey conducted by Denim Group found that software pros have a basic understanding of application security concepts, such as SQL injections, but they don't know the coding strategy to fix them, Dickson said.

Denim Group's 2014 Application Security study surveyed 600 software developers, architects and quality assurance professionals. It tested their basic knowledge of application security concepts, such as threat modeling and input validation, as well their understanding of defensive coding.

Software pros fail security test

Here are some of the Denim Group findings Dickson, who was the principal author of the study, shared with me in a recent conversation:

Dickson said that most software developers are aware of certain application security concepts, but they don't necessarily understand how to put those concepts into practice. "When asked how to write more secure code, they fared poorly," Dickson said. They answered questions about application security correctly 56 percent of the time [on average], he said, noting that "seventy percent is considered a passing grade." Software pros also aren't getting enough application security training. One of the survey questions was, "How much previous application security education have you received?" Half of the respondents said they received one day or more. The other half said they received less than one day of training, or none at all.

The way you change the security of software is by changing the way it's built.
John Dicksonprincipal at Denim Group in San Antonio

I would like to think that minimal training in application security is better than no training at all. But one result in particular suggests that isn't necessarily so. The survey asked those who said they received application security training the following question: "Did your organization implement any SDLC or process improvement steps to formalize concepts learned in training?" Of the respondents, 33% said yes, while the other two-thirds said, "I don't know," or "no." In other words, despite application security training, their respective organizations "kept on doing things the same old way," Dickson said.

Top management failure

Assuming the survey results accurately reflect current business thinking around application security, this is a pretty grim situation. An organization invests time and money to get software pros up to speed on application security. However, once the trainees return to day-to-day tasks, no effort is made to reinforce the concepts taught in training. While business executives who authorize training expenditures pay lip service to the idea of application security, they fail to insist on the adoption of secure coding practices to prevent security breaches. The message to software pros may not be articulated out loud, but it is still painfully clear: Application security is not a high priority.

As long as this situation persists, software pros aren't likely to take application security training seriously. Sure, there will always be a few software pros who invest their own time in becoming a resident application security expert. But most will simply see secure coding practices as a set of skills that are nice to know but have no real bearing on job performance.

When professional success depends on skills acquired through training, we give training our whole attention. We take notes. We ask questions. We seek support when we need it, and where we can find it. We do it because our success or failure at work depends on acquiring those skills.

When it comes to understanding application security and mastering secure coding practices, we are not there yet. This means a failing grade not just for software pros but also for top managers.

How do we get better at this? Let me know what you think.

Next Steps

Best practices for PHP and programming language security

Secure coding ignored by some IT pros

Denim Group Application Security survey results

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How can software developers learn to prioritize application security training?
It's often a situation of "baptism by fire". Until they either experience or see a malware attack or a hack to their apps directly, developers are going to lack motivation. Simulations can help.
This may seem like an excuse, but developers who belong to companies that take security seriously, are far more likely to prioritize it when building, and updating code.   The reality is many companies may be taking short cuts to get to market, and security is unfortunately an easy category to just presume 'that will never happen to us'. 
One of the challenges that comes with "coding securely" is staying on top of security threats and heading them off when they become known issues. For many organizations, that can add a significant overhead to their software development processes. Is it necessary? Yes, but with how much overhead it takes, it's not surprising that organizations take a "wait and see" approach and react only after they fail an audit or a breach becomes known and they discover they are vulnerable. Even with significant focus on these efforts, the challengers get ever more creative, and we as software developers and testers need to try to be as creative as the attackers. As an added bonus, though it's an older title now, I'd suggest looking at  Pavol Cerven's book"Crackproof your Software".