Paul Farrington, Director of EMEA and APJ at Veracode
Open source is exploding, writes Paul Farrington Director of EMEA and APJ at Veracode.
Every company is building its products and services with software using open source components. When software is released as open source, it means that the original author intends to give the code to the tech community as free to use study and improve upon.
This is because the amount of collaboration these projects can foster brings forward some of the greatest advancements in tech, and it makes the software more accessible for individuals who cannot afford licensing fees.
Using open source code speeds up development cycles and reduces cost. But it comes with risks – open source code doesn’t get the same level of scrutiny as your internally developed software. And when a vulnerability is identified, it can be difficult and costly to pinpoint all your applications that use a risky component.
Open Source Affects the Software Supply Chain
There are 5 million open source libraries now but the growth rate is exponential – we will see millions more developers releasing up to half a billion libraries within the next decade. This increases the threat vector for businesses who use open source in their applications because while open source creates efficiency, developers also inherit vulnerabilities in the components they use.
It’s no longer enough to focus only on your first-party code – making sure developers understand how to code securely and are scanning their code. This focus would leave a gaping hole in your security coverage.
Content from our partners
You also need to think about the open source libraries developers are pulling into their code. For instance, much of the current application security landscape is built around public Common Vulnerabilities and Exposures (CVEs). But that list was created before DevOps, and before the explosion in open source. Now, waiting for a vulnerability to be added to a public list is simply unfeasible.
In good news, using a vulnerable library doesn’t necessarily make you vulnerable. The crucial thing to keep in mind about vulnerable components is that it’s not just important to know when a component contains a flaw, but whether that component is used in such a way that the flaw is easily exploitable. Prioritization is key to getting open source security right.
In many cases, when developers pull in an open source library, they are only using one small piece of it – one method or function. That means even if the library is tagged as being vulnerable, your data might not be passing through the vulnerable part, or the method or function you are using might not be vulnerable.
Organisations that manage their software supply chain effectively have a competitive advantage over those organisations that do not. A well-managed software supply chain kept secure via frequent scanning that prioritizes fixes based on the riskiest components can keep the organisation secure.
Trends in Open Source Security
Vulnerable open source components run rampant within most software. In addition, Veracode research found open source software was among the slowest to be fixed once companies identified flaws – on average, it takes 93 days for companies to close just the first 25 percent of their open source flaws. That is just a snapshot of why open source security is a prominent concern.
At the same time, there is a changing mindset among attackers. The proliferation of open source has changed the economics of cybercrime for attackers. Rather than having to attack every app, they can create one attack that leads to many breaches. So, not only are open source libraries increasingly targeted in cybercrime, but attackers have begun creating malicious open source code that organizations are unknowingly incorporating into their code bases. Ransomware is one of the more frequently seen threats in this scenario.
Increased use of the cloud is also fundamentally changing the way we think about security. With more cloud-based apps and an increased need to scan for vulnerabilities, companies need to scale quickly. This need is compounded by the rapid pace of business innovation. Without the scale of cloud, it is nearly impossible to keep up with the speed of the digital economy.
We are also starting to see a shift in the focus on automation and continuous delivery that is enabling organizations to embed security into developers’ processes. Although industry benchmarks such as OWASP, PCI, CISQ, NIST and FS-ISAC, now require explicit policies and controls to govern the use of components, many organisations struggle to execute effectively on these policies.
Open Source Collaboration Will Prosper in 2019
There are changing trends in both the production and consumption of open source software. In terms of consumption, it would be difficult to identify a company that is not utilising open source code when building its products and services.
There are more open source libraries created all the time and those libraries are also being distributed much more quickly and in increasingly smaller sections. This fast growth in quantity and speed ultimately means that it is essential to quickly and frequently assess application security.
At the same time, the speed of app development is steadily increasing, meaning that any security checks that slow or interrupt developer workflows will not be effective. Application security today needs to be frictionless and easy, which in large part means becoming automated. We will need increasingly powerful automation and machine learning to identify, track and call out vulnerabilities to developers.
Collaboration between development teams and security teams will lead to growth, and needed scrutiny around security within open source components.
