The Urban Myths of Secure Coding: Part 1

Urban myths about secure coding might seem daunting, but in reality, they’re easy to manage when you have the right tools in place and best practices to follow as guidelines. While urban myths might change your perception about application security (AppSec), if you arm yourself with knowledge, they won’t become a blocker in your development process. Read on to learn about common conundrums in secure coding and how to go about overcoming them before they become a hassle.

Myth 1: Fixing open source vulnerabilities requires a time-consuming refactoring of code.

Reality: As outlined above, open-source libraries are often riddled with security flaws and vulnerabilities – some of which can turn into dangerous exploits if left unattended. But there’s a silver lining: most flaws in open source libraries are fixable, and the fixes are minor.

In fact, almost 75 percent of known vulnerabilities are fixable with a simple library update to patch exploits. As most security flaw fixes are minor updates or even just patch revisions, they generally do not change APIs and thus are not likely to disrupt your work.

While some flaws that plague open source libraries in particular are scary – broken authentication and cross-site scripting for example – we know that over 90 percent of the highest priority flaws have a fix available.

To be exact: 96.4 percent of broken authentication vulnerabilities in open source libraries are fixable with a published update, as are about 90 percent of cross-site scripting and broken access control flaws.

And we know from Veracode’s State of Software Security v11 (SOSS v11) that uncovering flaws through frequent scans results in faster remediation time too. Infrequent scanning cadences can mean that organizations take 7 months to close half their open findings, while those that scan at least once a day reduce their fix time by more than a third. So, while the flaws are daunting, the fix doesn’t have to be.

Myth 2: Open source code is more secure because there are "more eyes" on it.

Reality: You know that open source code saves valuable time, providing functionality that would be tedious to build from the ground up. It’s also extremely common: according to data from GitHub, 94 percent of active repositories in JavaScript rely on open source, with Ruby, .NET, and PHP hovering around 90 percent as well. But there’s a notion that simply because open source code is used by so many people and so many languages, it must be more secure because more eyes mean better security. Right?

Not quite. It is true that open source code naturally has more eyes on it, but that doesn’t mean anyone is keeping the code updated with the latest security information or letting you know that there’s a patch available. There’s a false sense of security surrounding open source code; in reality, it’s up to you and other security-minded developers to stay on top of known vulnerabilities in the libraries you use and understand how to fix them with tools like Software Composition Analysis (SCA).

We know from Veracode’s State of Software Security: Open Source Edition report that 71 percent of applications have a flaw in an open source library upon first scan. Even more daunting, the most common flaws found in open source libraries are often nasty ones; cross-site scripting, insecure deserialization, and access-control flaws make up about 75 percent of vulnerabilities in open source libraries.

Additionally, some languages are hit harder by open source vulnerabilities as they carry more dependencies, which means that you must do your due diligence when it comes to scanning third-party code.

For example, applications written in Ruby, PHP, JavaScript, and Java have more of an attack surface from transitive dependencies – in other words, a library that is dependent on another library – but that doesn’t mean you need to shy away from leveraging open source components in these languages. Instead, select open source libraries that are actively maintained with evidence of recent commits, manage your libraries closely to keep track of them and their security needs, and implement scans for greater visibility into existing issues so that you can prioritize patches and fixes.

Myth 3: I can trust my favorite developer tools to keep my code secure and give me all the security features I need.

Reality: It’s easy to treat security as an afterthought, especially when you have security “options” already built into the software development tools you’ve been using for years. It can feel like those options are a safety net when in reality they’re simply helping you check the most basic of boxes to scan for issues without offering clear data, which means you’re likely letting very risky flaws and vulnerabilities slip through the cracks.

These additional security options built into the tools you use to write code aren’t necessarily a negative step; it’s just that they typically lack the comprehensiveness necessary to actually be effective. Without the right tools in place – meaning solutions embedded strategically to protect you at every step of the development process – you’re creating more long-term work without mitigating risk.

Alternatively, this may mean that only the security team is scanning your application, and doing so right before production, which causes security tech debt to pile up. That means more work (and rework) down the road, and likely unhappy teams that are concerned with security, productivity, and business cost.

Get comfortable with robust scanning solutions that fit into your existing workflows, instead of point solutions that fail when it comes to security. With security plugged into each stage of development, you’re ensuring coverage for your CI/CD pipeline and reducing the stress that comes from mounting security debt. That way you can continue working in an environment you know best while scanning early and often to make more secure applications.

Ready to code more securely?

The quality of your applications doesn’t have to suffer because of these and other common secure coding myths. Improving your security knowledge with fast and relevant guidance is key to producing applications that won’t result in costly (damaging) exploits or attacks, and developer training is a critical piece of that puzzle.

If you are looking for a real-world/hands-on way to learn how to write secure code Veracode Security Labs not only boosts know-how but also makes an impact on muscle memory. Learn how to navigate risk by enabling you to exploit and patch real apps in contained environments. Security Labs Community Edition is easily accessible and free for individual developers like you, too, so you don’t have to break the bank to keep up with the ever-evolving world of application security risk.

Sign up here to start testing your security skills, and stay tuned for part two of this series!