Yet, for all the positive open source components bring to the table, there is a dark side. For hackers, open source components are a goldmine. Unlike with custom applications developed in organizations, if a hacker finds just one critical vulnerability in the open source code, they can attack any of the hundreds of thousands of systems that use that component in their applications. Just last month, a buffer overflow vulnerability was discovered in the glibc library, allowing attackers to remotely execute malicious code.
That isn’t to say that open source code is somehow less secure than proprietary code – it’s just more visible. And because of the public forum in which open source components are offered, downloaded, and contributed to, it’s up to organizations to make sure any open source components they use are updated and secure.
Our applications are composed of nearly 90% of open source components and libraries – and yet we’re actually doing less to secure them as we are for code developed in-house. One study recently found that 67% of companies don’t monitor their open source code for security vulnerabilities and that only 16% have an automated process for open source code analysis.
These aren’t necessarily small businesses either – another study found that Global 500 organizations alone downloaded nearly 3 million insecure components over a year.
The myth is that the more eyeballs on a piece of code, the more likely someone is to detect a vulnerability and fix it. By that ‘Linus Law’ logic, organizations needn’t worry about vulnerabilities in their code if they continue to update the components in a timely manner.
But the problem with that is that we have so many non-security minded developers writing and using open source projects that they wouldn’t know what they would need to fix. Especially if code analysis isn’t being conducted, any vulnerability left in your application at release time can threaten the whole of the application.
Our apps today are complex in the ways different components and libraries rely on each other, making for more robust applications – and more room for vulnerabilities to risk the success of your security program, and the organization at large.
It’s not a hypothetical risk – we’ve seen the damage open source component security vulnerabilities can do with Heartbleed, Shellshock and the Drupal flaw. So how can you ensure your open source components are a benefit and not a risk, and avoid your organization from getting stung by the next open source vulnerability? Here are five practices to consider implementing in your organization:
One way to improve your open source component security is by enforcing policies that require the developers using open source components to prove that they don’t have known vulnerabilities.
Many developers are still unaware of the risks posed by open source components, and it’s important to make them understand that vulnerabilities brought from open source components into the application puts the whole app at risk – not to mention the organization. By creating and enforcing policies that require security team or team leader approval or another method of requiring the developer to prove the security of the tool (which could be as simple as a Google search), you’re already setting the bar higher for developers who may not be aware of such issues.
Another crucial aspect to open source component security is doing an inventory of your open source libraries both in development and in production. There are plenty of organizations who have no idea which open source components are being used in their applications, and that poses a major risk. And that’s not including any indirect open source dependencies, even when a 2013 WhiteSource study discovered that “91% of software projects contain indirect open source components”, with an average project relying on 64 different libraries spanning eight types of licenses.
Start by surveying your development teams on which open source components they use and when the last time each were updated. That will already offer a good way to see how in touch with open source component security your developers are, along with getting a list of projects in use. If you have the resources, creating a central repository of open source components – where you can manage their security, licenses and updates – is a major step towards getting control of your open source code.
Probably the surest way of improving the security of your open source code, and in turn your whole app, is to detect which open source components are used within your organization and then test their security, if you’re not already doing so.
Open source analysis is just as important as proprietary code, because not only could the code hold unknown security vulnerabilities, its’ dependencies and functions may differ between use cases, so that a component that is secure in one application may be found to be insecure when used in a different application – and only security testing along with code review could detect those issues.
One often-overlooked aspect of open source component security is making sure your usage of the open source component is in line with the license granted to avoid business or compliance risks. The lack of awareness can cause major issues down the line, if licenses are not honored. Last year, a prominent developer and Linux contributor sued VMWare over the company allegedly violating the GPLv2 license that would require VMWare to release its’ source code, in allegiance with the license.
Often times the licenses don’t require much more than requiring you to mention the components in your release notes. But when you don’t know what licenses your components carry in the first place – you’re just hoping for the best, but could swiftly get hit by the worst.
Like any security process, managing your open source components is never a one-and-done process – it is on-going for as long as an app is in deployment. Once you’ve run through the four steps above, it’s a rinse-and-repeat, as long as open source components are being used in your apps. Ensuring your policies regarding open source libraries are being followed, monitoring how they’re being used, and managing your inventory are essential in your overall application security program, and as such, must be kept up.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.