National Coding Week: Closing the skills gap with secure code training

Beyond security basics

But as is the case with any skill, it’s crucial to go beyond the basics. If you want to keep the job and get promoted, the next step is to learn to make sure that code is secure. It’s not enough to get a computer to behave the way you want it to. You also need to ensure it behaves only the way you want it to.

Because as is documented every day of the year, criminal hackers can exploit vulnerabilities in software code not only to steal personal or financial information but also to undermine the purpose of applications and systems. Cyberattacks can shut down a business, healthcare facility, or government agency. They can take down or undermine critical infrastructure, putting lives at risk.

That continues to happen because even the most expert coders are fallible—their code is almost certain to contain vulnerabilities. Call them bugs, defects, or flaws, but the bottom line is the same—they all create risk, and software risks are business and personal risks.

NCW also reports that in the tech world (which is embedded into the entire business world) “92% of executives believe American workers are not as skilled as they need to be.”

Steven Zimmerman, security solutions manager with the Synopsys Software Integrity Group, noted in a recent blog that “the workforce is rife with professionals who can put hands to keys and generate functional applications. But most of these developers have not been trained in secure coding practices.”

Which means if you want to get ahead of the average coding crowd, you need to add security skills to your resume. Experts say secure code is the result of both defensive and offensive efforts. Defensive security is the use of automated tools to detect vulnerabilities throughout the software development life cycle. Obviously that’s not actually coding, it’s testing the code.

Offensive security, by contrast, trains code writers to avoid vulnerabilities. As the saying goes, the easiest vulnerabilities to fix are those that are never introduced into a codebase.

The obvious solution, then, is to expand training in secure coding practices. And the good news is that guidance and training are available. It’s just that some of that off may be a bit overwhelming for a beginner.

Secure coding best practices

The Open Web Application Security Project’s (OWASP) Secure Coding Practices Quick Reference Guide is comprehensive but anything but quick, with 218 recommendations grouped into the following 14 categories:

• Input validation
• Output encoding
• Authentication and password management
• Session management
• Access controls
• Cryptographic practices
• Error handling and logging
• Data protection
• Communication security
• System configuration
• Database security
• File management
• Memory management
• General coding practices

But there is also less daunting training to get coders started. Secure Code Warrior, which notes on its website that “the same 10 software vulnerabilities have caused more security breaches in the last 20-plus years than any others,” offers guidance on how to recognize and avoid them. They include file upload, server-side request forgery, cross-site scripting, SQL injection, password storage vulnerabilities, and the use of components with known vulnerabilities.

Finally, there are more general principles and techniques that can help coders develop a security mindset.

Verify, then trust. One of the first things to understand is that coding includes using more than what a single developer has written.

Vineeta Sangaraju, senior research engineer with the Synopsys Software Integrity Group, said that “no one typically writes every single piece from scratch. You depend on the programming language’s libraries.”

And those libraries don’t always come from the creators of the programming language. “As the world of coding progressed, some libraries were not the official parts of that programming language or framework,” Sangaraju said. “They were being created by third parties.”

There are benefits to that. “Coders have even more options when choosing the libraries,” she said. “Instead of writing a method from scratch, they will just import the third-party library and use its methods instead.”

But that also leads to an important rule of offensive security. To trust any library, coders need to check both what they’ve written and what somebody else wrote. “They need to scrutinize the third-party library and only trust verified publishers,” Sangaraju said. “In the current world, sometimes these libraries have unsecure code so if a coder uses them, they’re inadvertently introducing security weaknesses into their code.”

That principle also applies to any external data. “When you’re coding functionalities that deal with external input, it is important to understand the risks involved and to mitigate them with controls,” Sangaraju said. “For example, are you requesting profile details from the user? Then sanitize user input before it is saved in the database.”

Secure coding saves time

Ksenia Peguero, research engineer with the Synopsys Software Integrity Group, believes “think like an attacker” is one of the most important pieces of advice she ever heard. “If you expect a user to do one thing, like send an address in a string field, the user—benign or malicious—will definitely do another, like sending a string of gibberish, also known as an attack payload, into that field. In this case, sanitizing or validating all input would help to build the protections into your application.”

These, along with the lengthy lists of best practices, may make it sound as though implementing secure coding techniques will never work in the hyperdrive environment of modern software development, where speed is the top priority.

But Zimmerman said implementing secure coding practices can speed things up in the long run. Code writers who do so will “spend less time reworking code they’ve already pushed downstream that gets kicked back to them because of a failed security test,” he said.