26% of firms suffered breaches in 2018 due to vulnerable open source components

News by Jay Jay

A number of factors including the lack of open source governance programmes has resulted in a 71 percent rise in open source breaches over the past five years.

The lack of open source governance programmes, the inability of a large number of organisations to implement elite DevSecOps programmes, and the inability of organisations to impart application security training to employees have resulted in a 71 percent rise in open source breaches over the past five years.
A survey of over five thousand IT professionals has found that even though organisations are now doubling down on DevSecOps programmes, creating cyber-security response plans, and adopting open source governance programmes, a lot of work remains to be done to completely secure organisations' IT systems from malicious actors who exploit vulnerabilities in open-source components in enterprise applications to find their way in.
The threat factor is huge considering that a modern organisation now uses hundreds of Internet-facing applications and open-source components now form as much as 80 percent to 90 percent of any application. Therefore, building a security programme that can analyse every open source component and can routinely monitor it for vulnerabilities seems extremely challenging, yet is necessary for all organisations.
According to Sonatype's sixth annual DevSecOps Community Survey, over one in four companies (26 percent) suffered breaches due to security weaknesses in open source components in the past year alone. This was a direct result of a large number of companies not following an open source governance programme even though it is a well-known fact that as many as 50 percent of downloaded components contain known vulnerabilities.
 
Sonatype pointed out that the flawed open source component that led to the Equifax data breach was downloaded by over ten thousand organisations, including 65 percent of the Global Fortune 100. Had such organisations followed open source governance programmes, their security teams would have been able to alert their application developers when such components were being integrated with enterprise applications.
Through its survey, Sonatype found that 62 percent of firms that did not have elite DevSecOps programmes did not have a cyber-security response plan in place, that elite DevSecOps companies were three times more likely to provide application security training, and that only 25 percent of companies without DevOps practices lacked open source governance programmes.
"Every organisation with a DevOps framework should evolve towards a DevSecOps mindset. The objective is to treat security as a core component throughout the software delivery pipeline as opposed to thinking of it as an afterthought. As security threats continue to evolve it's easy to see the value of evolving towards DevSecOps," said Shawn Ahmed, vice president of product marketing, CloudBees.
"Key DevOps principles including: continuous learning via collaboration, automation (CI/CD), infrastructure as code, and monitoring, help ensure effective and timely responses to any breach. We must all recognise security is a living thing and organisations should be prepared to prevent and respond to breaches at any moment within their application lifecycle. It is difficult to imagine proper cyber-security hygiene and sufficient preparations for a breach without DevSecOps in place," said Hasan Yasar, technical manager and adjunct faculty member for Carnegie Mellon’s Software Engineering Institute.
According to Sonatype, automated application security testing is the way forward as in-house security teams just don't have the time to screen all applications and open source components for vulnerabilities and half of all IT professionals have already outsourced security to cloud providers instead of managing themselves. 
Commenting on Sonatype's findings, Tim Erlin, VP of product management and strategy at Tripwire, said that to begin with, organisations must create a complete inventory of the software in their environment, including open source components. This is because only when an organisation has complete visibility over its applications, it will start understanding which software needs updating and how to run security updates.
When asked if DevSecOps programmes are too expensive for small and medium-sized organisations, he said that incorporating security into DevOps is, in fact, more efficient and less costly than with alternative development methodologies. 
"Organisations of all sizes are challenged with securing DevOps not because of cost, but because of culture and technology. Security hasn’t been part of the DevOps culture so far, and in some cases the tools to secure the Dev side of DevOps are limited. If an organisation can afford to adopt DevOps, they can afford to adopt DevSecOps," he said.
According to Simon Roe, product manager at Outpost24, if organisations choose to take the plug-and-play approach to open source components, they must ensure they have effective tools and processes in place to assess and mitigate the risks involved. 
"Tools such as Software composition Analysis tools (SCA) allow organisations to not only understand any vulnerabilities and risks that using these components could pose, whether there are newer and more up-to-date versions available that mitigate the risks and also, to ensure that their usage meets any license requirements of the 3rd party component.   
"Using SCA alongside traditional application security tools helps organisations to better understand and mitigate risks that are present in the application.  Doing so earlier in the development lifecycle ensures that costs are limited to $10’s rather than $1000’s if these are addressed during production," he said.
Commenting on the costs incurred by organisations to incorporate security into their DevOps, he added that the cost to address bugs and vulnerabilities in applications are reduced as companies adopt a shift left security mentality and start to use security tools earlier in the SDLC.
"If a vulnerability is identified in the production system, often the cost to address this can run into the $1,000’s usually due to the tools and methods employed to identify these vulnerabilities, and then the impact of the fixing them.  Finding them during code development, whether it’s an in house application or one that’s built through the use of 3rd party, open source components, costs little to nothing in terms of the applications budget," he said.
Dave Mound, principal cyber security engineer at Furnace Ignite, told SC Magazine UK that an organisation can mitigate the risks of using open source software by implementing patch management, creating a 'Usage Policy for OSS', implementing testing tools such as Dynamic Application Security Testing (DAST), and carrying out static code analysis and penetration testing.
For web-based applications, he recommends that security teams should use best practices with things like SRI Integrity Attributes to ensure scripts that are loaded from external sources haven't been tampered with.

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Video and interviews

Interview - Everyone has an Achilles heel: The new security paradigm

How can we defend networks now that the perimeter has all but disappeared?
Brought to you in partnership with ExtraHop