Insecure sample code in tutorials leads to insecure production code. How do you train your developers to fix and reuse insecure code examples the right way?
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.
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.
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.
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.
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.
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.
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.
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 Synopsys’ 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.
Development teams, no matter their industry, should look at where developers learn new skills and ask questions. Look at the quality of the lessons and the answers available. If the quality is consistently poor, direct your developers elsewhere. If the quality is good, list the source as a preferred source for your developers. Make sure they understand that the code they see may not meet your standards. Also, communicate that reusing sample code requires additional work beyond copying, pasting, and tweaking.
It’s sad that poor developer training actively creates security problems in software, and that insecure sample code reflecting bad practices appears so often in production code. As developers and other members of development organizations, we must remain vigilant. Remember that the lessons we learn are often incomplete and wrong. We need to enable our developers with good processes and procedures so they can catch not only their own errors but also errors they’ve imported from elsewhere.
Mike Lyman is a senior security consultant at Synopsys. He works with customers on secure code reviews, vulnerability assessments, and trains developers in secure development. Prior to Synopsys, Mike spent 12 years with SAIC and helped create their software assurance offering for DoD customers at Redstone Arsenal, AL; pioneering most of the processes and procedures used by the practice. He learned IT security in the trenches with Microsoft's network security team throughout the heady days of SQL Slammer, Code Red and Nimda. Prior to that, he was a software developer supporting US Army project offices at Redstone Arsenal and served on active duty as an officer in the US Army. He has been a CSSLP since 2008 and a CISSP since 2002.