The good, the bad & the ugly of using open source code components

The developer’s role in securing component use

Open source and third-party component use is shifting from optional to best practice, and even necessary. It’s simply impossible for developers to keep up in today’s digital world without incorporating these pre-fabricated code snippets into their applications.

At CA Veracode, we analyze the data from our platform every year to create our State of Software Security report, and we’ve been using this data to sound the alarm about the insecurity of components for years. For instance, in 2017, we found that 88 percent of Java applications we scanned had at least one flaw in a component.

But what do developers think about our alarm sounding? How do they feel about component use? Are they aware of the risks, are they concerned? We recently sought answers to these questions in a joint survey with Vanson Bourne. For this research, we interviewed 400 application developers in the US, the UK and Germany regarding their use of components.

Do developers want to use components?

We know component use is widespread. In fact, this survey found that a whopping 93 percent of respondents use commercial and/or open source components, and of those organizations, the average number of components per application is 73.

But would application developers choose to use them if it were up to them? Just over nine in ten (91 percent) confirm that they would use components. This high number suggests that developers realize that component use is best practice, that it would be difficult to produce at the required speed without their use, and that components are an integral part of development processes, and here to stay.

Are developers aware of the risks?

Somewhat, but not enough. Among survey respondents who reported at least some familiarity with the OWASP Top 10 application risks, only 43 percent say that they are very aware of OWASP recommendations for preventing the use of components with known vulnerabilities.

When it comes to the selection of a new open source or third-party commercial component, functionality (62 percent), performance (48 percent) and/or cost (44 percent) are the most likely considerations, followed by security vulnerabilities (42 percent), highlighting that security is essential but less of a priority.

This isn’t particularly surprising, since we know developers are typically goaled on the speed with which they produce code and the functionality of that code – making it hard for them to consider security a priority. In fact, one-third of 400 IT pros we recently surveyed indicated that the functionality of their code is their single most important metric. And in a survey we conducted with DevOps.com, seven in 10 developers said their organizations don’t provide adequate training in security, and 76 percent reported that they weren’t required to complete any security courses while in school. If developers lack the training needed to identify security issues, and aren’t incentivized to pursue it anyway, you can’t expect them to produce secure code, or to worry about the security of the open source components they are downloading.

On the other hand, concern over security (49 percent) is the biggest reason for organizations not using open source components, which suggests that there could additionally be a lack of knowledge and awareness around how open source components can be secured.

Not aware of security, but responsible for it

Once these components have been implemented, who holds responsibility for their upkeep? Forty-four percent report that it’s the development team that is responsible for the maintenance of third-party commercial and open source components, while only 31 percent report that it’s the security team.

This suggests a move toward responsibility for the development team. But this move doesn’t appear to have been accompanied by the systems or tools, or even the know-how, needed to use components securely.

Of organizations using third-party components in their applications, only 52 percent update those components when a new security vulnerability is announced. In my mind, these numbers are a red flag. If you’re giving developers responsibility for the upkeep of components – make sure you’re enabling them to do that.

What does that look like? Making component use work starts with technology that creates a dynamic inventory of which components in use, and where. Ideally, this inventory would include information on whether the specific vulnerable functionality is being used, and guidance on how to remediate any security issues. In this way, when a big vulnerability hits the news, developers have the insight they need to address the problem quickly. Speed developers’ process even further by creating a repository of approved components for developers, taking the guesswork out of component security and dramatically reducing downstream work.

Bottom line

The reality is that developers need to use components, should use components and want to use components. But this reality necessitates both more education surrounding the risk of components, and the tools and technology that allow developers to continue to use components, but in a secure way that doesn’t slow them down.