Almost every modern business and application uses open-source modules. It’s misleading to spend time distinguishing between open-source and proprietary software, because modern applications include third-party software components. Many of those components are open source, and very few companies have a solid understanding of the security vulnerabilities that come with the code.

The reach and impact of open-source code vulnerabilities may only become known after they’re exploited—in some cases, long after—but, in one form or another, the business world has moved to community-developed software. A Black Duck survey of C-level executives and senior IT professionals from 2015 showed that open-source software use has nearly doubled since 2010.

Open-source security fallacy
The well-trod “given enough eyeballs, all bugs are shallow” theory about open-source software is only true when all those eyeballs are focused on the same task. It doesn’t take into account that most users aren’t specifically looking for security vulnerabilities and, even if they are, they might not be qualified to find them.

Most developers writing and using open-source projects aren’t security-minded and, if code analysis isn’t being conducted, vulnerabilities could get through to your application, threatening its success. Open-source code does have its security benefits—it can be audited and fixed when security is in doubt—but it isn’t inherently more secure. We’ve all seen the damage open-source component security vulnerabilities, like Heartbleed and Shellshock, can cause.

(Related: Security in software needs to be Job One)

At the time of Heartbleed’s exposure, approximately half a million of the Internet’s secure web servers, certified by trusted authorities, were vulnerable to the attack. This allowed for the theft of private keys, session cookies, and passwords that might allow attackers to impersonate users. Because the attack grabbed random blocks of memory, any information that was being held in memory could have been exposed to a sufficiently persistent attacker.

Hours after Shellshock’s exposure, attackers created botnets of vulnerable computers and performed DDoS attacks. Millions of attacks and probes were recorded in the days following the disclosure. These attacks highlight the viral potential of the open-source component ecosystem. A single open-source component can be reused in hundreds of other components, meaning that a flaw will be inherited by every component that depends on it.

Delayed vulnerability patches
If attackers find one critical vulnerability in open-source code, they can attack the hundreds of thousands of systems that use the component in their applications, but that doesn’t mean patches come quickly. According to “The State of Open Source Security in Commercial Applications,” the average age of an open-source vulnerability is more than five years.

Most organizations don’t know about the open-source vulnerabilities in their code because they don’t track open-source components. Sites and applications are hijacked because third-party software remains unpatched, and open-source modules frequently have insecure versions available for download long after patched versions are out. Many organizations with particular versions specified in their builds continue to use the insecure ones because updating would create version compatibility issues.

In Black Duck’s “2016 Future of Open Source Survey,” they found that open-source security and management has not kept pace with the adoption of open source. Currently, 50% of companies have no formal policy for selecting and approving open-source code, 47% of companies have no formal processes to track their open-source code, and more than one-third of companies have absolutely no process for identifying, tracking, or patching known open-source vulnerabilities.

This problem isn’t limited to inconspicuous companies, either. Global 500 organizations alone downloaded nearly 3 million insecure components over one year, a startling number considering the uptick in cyber attacks. The vice president of security at Black Duck predicts that “the number of cyber attacks based on known open-source vulnerabilities could increase by as much as 20% in real terms.” Hackers have learned that applications are the weak spot in most organizations’ cyber security defenses, and that widely available open-source exploits have a high ROI, allowing them to compromise thousands of sites, applications and IoT devices with minimal effort.

Enterprise-grade open-source vulnerability remediation is available, but companies need to prioritize open source code security. Industries with more regulations tend to be less secure because they only fix the vulnerabilities required by regulation. They put their effort into compliance, not security, and have much slower update times because of the cost of compliance testing. A less-regulated industry can update ad hoc when a vulnerability gets fixed.

Update cycles run on a fixed clock in many organizations, so security issues get pushed back as features are prioritized. Developers and IT teams need to make security as much of a priority as functionality when developing or implementing applications. Organizations need to incentivize developers to do this, as well. If organizations only care about features, developers will only make functionality the priority.