Tim Mackey, Principal Security Strategist, Synopsys Cybersecurity Research Center (CyRC), highlights how recent research has shone a light on growth and gaps in open source adoption, while offering advice to organisations on how to create secure applications.
Open source plays a critical role in today’s software ecosystem. The overwhelming majority of modern codebases contain open source components, with open source comprising 70% or more of the overall code.
One major reason for this is that with open source usage, teams can tap into expertise that they would be hard pressed to hire on as employees. And yet, as its adoption grows globally, so too do the mounting security risks posed by unmanaged, or poorly managed, open source usage. After all, you can’t manage, and importantly patch, what you don’t know you have.
A recent survey of 1,500 IT professionals working in cybersecurity, software development, software engineering and web development was conducted by the Synopsys Cybersecurity Research Center (CyRC) and Censuswide, an international market research consultancy.
The report explores the strategies that organisations around the world are using to address open source vulnerability management as well as the growing problem of outdated or abandoned open source components in commercial software.
Survey response shows open source security is top-of-mind, but patching is too slow
Security and vulnerability to exploit of an open source component were top of mind to 50% of respondents – cited as the primary selection criterion when vetting new open source components. With over half (51%) of respondents saying that it takes two to three weeks for their organisation to apply an open source patch. And 24% noting that it can take up to a month – even when a patch addresses a critical issue – teams are right to prioritise security during the selection phase.
Organisations using open source need to increase investments in SCA
The ability to patch any software starts with knowing that you’re running a version of that software. Without the use of a software composition analysis (SCA) tool, which is designed to identify open source usage, knowing where open source components are used and what the current patch status of each component is can be a challenge. The survey respondents indicated that only 38% were using an SCA tool, which in addition to providing an inventory of open source usage, would help teams quickly identify outstanding patches. As to the frequency of when the patch is applied, that will be something governed by the release cycle and QA effort employed by each team.
The results also indicate that corporate adoption of SCA tooling is still at a relatively early stage. In its 2020 “Market Guide for Software Composition Analysis” report, Gartner notes that SCA usage is in the early stages of adoption, but that interest in SCA is growing rapidly, with inquiries to the analyst firm on the topic increasing nearly 40% from 2019 to 2020.
Yet, 72% of respondent organisations state they have a published policy for open source use. This leads into the question around how the other 35% who aren’t using SCA are managing open source to comply with their policies. Are they employing manual processes to manage open source? Are they depending on a developer honour system that policies are being followed? DevOps principles are based in part on automated validation of the state of a system, meaning that teams reliant upon manual efforts or honour systems are likely one incident away from a major disruption.
Media coverage plays a role in open source risk management
One finding from the research that I find particularly surprising is that 46% of respondents noted that media coverage around open source issues influences how their organisations manage open source risk. This caught my attention in part because most media coverage of open source issues highlights a headline-worthy component such as a vulnerability in Docker, Kubernetes or Linux, or a headline-worthy victim, such as Equifax. Such high-profile scenarios increase overall awareness of application security issues, but if a business relies on the media as their primary security news feed, then they’re exposing themselves to greater risk than necessary.
Media, in this regard, is reactionary. The last thing that any business leader wants is negative press stemming from a cybersecurity incident. Embracing security information flows using DevSecOps principals can help development and operations teams keep pace with the constantly evolving threat landscape. Automation of AppSec tooling then provides a prime source of security information about any weaknesses in the software powering a business – but only if that information is shared amongst the teams involved in the lifecycle of that software.
A growing problem in the open source community around project sustainability
The 2020 Open Source Security and Risk Analysis (OSSRA) report showed that 91% of codebases audited in 2019 contained open source components that were either more than four years out of date or had no development activity in the past two years. This speaks to a situation where either the component used was abandoned by the author and associated community, or that when the component was adopted, the origin point for the component wasn’t properly vetted to ensure that it was under active development.
While an argument can be made that for some components they are functionally complete, this is different to being properly secured against the current threat landscape. To properly address this, consumers of open source components need to look at how projects are being sustained; because if a security issue arises, it can be difficult to get the issue fixed when no-one is looking at the code.
Security risks increase when obsolete code is deployed, including the threat of an open source component being hijacked. Such a situation occurred in 2018 when the event-stream component was hijacked to target Bitcoin in Copay accounts. Without policies in place to identify and manage the risks that legacy open source can create, organisations open themselves up to the possibility of issues in the software.
No universally adopted application security testing tool
And one element to support such policies involves tooling. Survey responses note that there is no universally adopted application security testing tool. Responses to the survey questions also indicate that there is no shortage of application security testing tools and techniques. However, even the AST tools with the highest adoption rate is still only utilised by less than half of respondents.
Summing it up
The key to creating secure applications is a cohesive and comprehensive testing process that extends from the beginning of the design phase, all the way through development and into deployment and production.
And as the pace of software development and innovation continues to increase, it is important to recognise that open source technologies are part of that success. They enable teams to focus on creating unique and valuable solutions while tapping into domain expertise in areas that aren’t core to their business.
Properly managing that relationship should be a key priority and I find it promising that 63% of survey respondents reported that they are incorporating some measure of DevSecOps principles into their software development practices. This is certainly a step in the right direction.
