OWASP Top 10 & Open Source Code: Why Watching Your Back Means Watching Everyone Else’s

At times, being a developer can feel a little bit like being back in school and getting partnered up on projects. You would work your butt off, fastidiously checking and rechecking your part of the assignment until you’re sure it’s perfect only to show up at school on Monday and find that your partner hasn’t fulfilled his end of the deal. And there goes the project.

The open source components you can tap into as a developer are, for the most part, wonderful things. But while you’ve doubtlessly spent endless hours checking the security of your own code, you’re often put in a position where you have to trust that all of that third party code was checked as closely as yours was. Sometimes, those open source components that saved you all kinds of time and trouble may have glaring security issues. The good news is, there is a solution.

There are a number of reasons why you can’t take the security of your open source components for granted, and, luckily, many things you can do to secure that open source code right alongside your proprietary code.

The pesky OWASP Top 10

They say knowing is half the battle, and that is quite possibly true. But the other half of the battle is actually doing something with that knowledge, and that seems to be the half of the battle we as humans so often stumble on.

Take the OWASP Top 10, for example. The Open Web Application Security Project is an open-source community project that aims to spread awareness about application security issues, and every few years they compile the OWASP Top 10. To perhaps overstate it, these are threats that are widely publicized as the 10 biggest threats facing developers. These are known entities. There shouldn’t be a developer who is unaware of them. And yet, there’s a reason they’re the top 10. The threats that should be the most protected against are routinely the biggest sources of devastating attacks and data breaches.

Not MY code

Well, you might be thinking, as a responsible developer, my code will certainly be secured against the top 10 application security threats. And if you’ve got a secure software development lifecycle, yes, your code is probably very secure. But that ‘your’ in the last sentence is the operative term. What about all that third party code that goes into your build?

There’s a reason the number 9 threat in the OWASP Top 10 is using components with known vulnerabilities – it happens all the time. Open source libraries and frameworks with known vulnerabilities can leave an application open to attacks like SQL injections and cross-site scripting (XSS), two of the other OWASP Top 10.

A vulnerability in one of your open source components is bad enough, but a known vulnerability? That’s the line between somewhat understandable and completely inexcusable. It undermines the entire application, and possibly even your organization.

SQL, XSS, BAD

SQL injection and XSS are the number 1 and 3 threats in the OWASP Top 10, respectively. They are very good at what they do. In the case of SQL injection, what it does is allow attackers to inject an SQL query into a database to modify data, read sensitive data, execute administrative operations and even issue commands to the operating system in the more extreme cases. What XSS does is allow attackers to fool a browser into accepting data from an untrusted source, leading to an attacker being able to take over a user session and harm the website, or force the user to visit another site, possibly hosting more malicious code.

XSS made the news last fall when attackers used an XSS vulnerability on the popular image sharing site Imgur to infect targeted Reddit users with malicious code. Because the attacker essentially used this attack as a prank, the damage was limited. Theoretically, he could have targeted every Imgur user. One of last year’s most famous SQL injection-based attacks was the data breach of UK ISP TalkTalk, where attackers were able to steal the personal information of 150,000 users.

Proprietary code, open source code, whatever it may be – it needs to be analyzed for these threats as well as other OWASP Top 10 threats.

A truly comprehensive application security testing platform

This may all read as aggravating news to anyone who dedicates a significant amount of time to making sure their own code is secure, but there is a bright side, and it comes in the form of the new version of Checkmarx’s application security testing platform.

This platform combines Checkmarx’s leading source code analysis with WhiteSource’s open source analysis for a solution unparalleled in comprehensiveness. It covers all code security aspects and all leading coding languages, and is available both on-demand and on-premises.

Just as you couldn’t control your class partner’s laziness back in school, you can’t control how the open source components you need to use in your build were originally coded. However, you can seamlessly integrate a comprehensive application security testing platform into your development lifecycle to check for vulnerabilities and recommend fixes. Common sense plus the OWASP Top 10 indicates that you should probably do that.