Insecure example code leads to insecure production code

The sad reality in the software world is that developer education and training, if it doesn’t outright neglect software security, often teaches developers the wrong way to secure their code. Poor training outcomes range from developers adopting a “get it to work and move on” mindset to their reuse of insecure code samples in tutorials and forums. A study published in 2017 shows that insecure code examples in tutorials, vulnerable to things like SQL injection and cross-site scripting (XSS), manage to find their way into real-world production code.

Insecure code examples lead to real-life vulnerabilities

In April 2017, seven researchers published a paper called Leveraging Flawed Tutorials for Seeding Large-Scale Web Vulnerability Discovery. They used known insecure code samples from popular tutorials on the web to find similar weaknesses in actual software projects on GitHub. The aim was to use the tutorials to find weaknesses. The results prove that bad examples end up in real-world code.

The researchers created a method to look for tutorial-derived code in projects. Then they applied it to both little-known and little-used projects to well-known and well-used projects. When they found a match, they manually verified that the code in question was substantially the same as the code in the insecure tutorial and that it did, in fact, replicate the weaknesses.

The results are telling

Across 64,415 codebases on GitHub, their spider found 820 pieces of code that looked similar to the tutorial code they were looking for. Manual verification confirmed that 117 matches were substantially the same code and contained the same weaknesses as the tutorial code samples. They found these problems in both more and less popular software.

While the numbers may look small, these instances reflect just a few specific insecure code examples that appear to have directly led to the same weaknesses in real-world code in open source projects. They don’t reflect all other bad sample code that developers use each day.

This should be alarming

Developer education all too often teaches developers to do exactly the wrong things when it comes to securing software. These wrong techniques appear in production code, often with little change. When developers learn the wrong methods, they practice and implement those methods in the real world. Combine that with the “get it to work and move on” mindset so many developers pick up along the way, and it’s clear why they aren’t likely to correct their methods before the project’s release. As a result, organizations get hacked.

How to fix the problem of insecure sample code

In a perfect world, developers wouldn’t learn insecure practices or produce insecure sample code. However, demanding that all code be secure from the moment it’s written is a tall order. We’re seeing improvements, but as the study shows, we have a very long way to go.

If you produce sample code to teach developer lessons, make sure your code examples are secure. Until everybody does that, it largely falls to the developers and their teams to come up with a solution for insecure code.

If you're a developer, remember that code examples in tutorials are almost always incomplete (and insecure). Tutorial writers simplify code examples so their lessons are easier to follow. They often leave off necessary steps, such as input validation and error checking. Instead, you need to add these yourself. The same is true of other elements affecting code security. When you reuse insecure sample code, make sure you fix it so your code can’t be hacked. Tutorial writers may have the luxury of writing insecure code, but as a real-world developer, you don’t.

A secure coding action plan for the future

Development teams play a major role in ensuring that bad code doesn’t make it into production. Conduct peer code reviews to identify and correct any mistakes made during development. “Get it to work and move on” leaves room for error. Peer review puts other eyes on the code and can help identify errors before the code is checked in.

Establish a Security Champions program

A best practice is to have security-aware developers involved in this process. They should specifically look for code that may cause security issues. Many firms establish the role of Security Champions, developers who compose a satellite of the main software security group (SSG). They are located close to development teams to be their resident security experts. Peer review and the participation of security experts go a long way toward keeping insecure sample code out of production.

Use secure coding tools

The many static analysis tools available can help locate problems in code before they reach production. These tools, both commercial and free, can scan code for problems relatively quickly and identify common security bugs created in development. Tools like Black Duck’s Code Sight act like a spell checker for developers. They identify security problems in code as developers are writing it and provide immediate remediation advice.