Part One: Secure Coding Urban Myths
A developer and security expert takes a look at three secure coding myths and debunks them while highlighting the importance of proper secure coding practices.
Join the DZone community and get the full member experience.Join For Free
Urban myths – whether rooted in reality or fabricated entirely – have the power to change perception. In software development, where the security of your applications relies on best practices and proven methodologies, such urban myths can perpetuate risk by making prevention and remediation seem cumbersome. In turn, common conundrums like securing open source code or properly managing cryptography feel like too much of a hassle.
While urban myths about secure coding can seem daunting, the reality that is easy to manage with the right tools and best practices in place. Read on for part one of Veracode’s two-part series featuring secure coding urban myths (and their realities).
Securing Coding Myth #1
Myth: Open source code is more secure because there are "more eyes" on it.
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.
Secure Coding Myth #2
Myth: 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 seven 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.
Secure Coding Myth #3
Myth: 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.
Opinions expressed by DZone contributors are their own.