The good, bad and ugly of using open source code components


The role of the developer in securing the use of components

The use of open source and third-party components is changing from an optional practice to a best practice, if not necessary. It is simply impossible for developers to keep pace with today’s digital world without incorporating these pre-made snippets into their applications.

At CA Veracode, we analyze data from our platform every year to create our Software security status report, and we’ve been using that data to sound the alarm bells about component insecurity for years. For example, in 2017, we found that 88% of the Java applications we analyzed had at least one flaw in a component.

But what do the developers think of our alarm? What do they think of the use of the components? Are they aware of the risks, are they concerned? We recently sought answers to these questions in a joint investigation with Vanson Bourne. For this research, we interviewed 400 application developers in the United States, United Kingdom and Germany regarding their use of the components.

Do developers want to use components?

We know that the use of components is widespread. In fact, this survey found that 93% of respondents use commercial and / or open source components, and among these organizations, the average number of components per application is 73.

But would app developers choose to use them if it was up to them? Just over nine in ten (91%) confirm they would use components. This high number suggests that developers realize that using components 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 are there. to stay.

Are developers aware of the risks?

A little, but not enough. Among survey respondents who reported at least some knowledge of the OWASP Top 10 Application Risks, only 43% said they were very aware of OWASP recommendations to prevent the use of components with vulnerabilities. known.

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

This is not particularly surprising, as we know that developers are generally focused on the speed at which they produce code and the functionality of that code, which prevents them from seeing security as a priority. In fact, a third of the 400 IT pros we recently surveyed rated the functionality of their code as their most important metric. And in a survey we conducted with, seven in 10 developers said their organizations didn’t provide adequate security training, and 76% said they weren’t required to take any courses. security during their studies. If developers don’t have the training to identify security issues and don’t have the incentive to pursue them anyway, you can’t expect them to produce secure code or care about security. of the open source components they download.

On the other hand, security concerns (49%) are the main reason organizations not using open source components, which suggests that there might additionally be a lack of knowledge and awareness on how open source components can be secured.

Not aware of security, but responsible for it

Once these components have been implemented, who is responsible for their maintenance? Forty-four percent say the development team is responsible for maintaining commercial and open source third-party components, while only 31 percent say the security team.

This suggests a shift towards responsibility for the development team. But this development does not appear to have come with the systems or tools, or even the know-how, needed to use components safely.

Among organizations using third-party components in their applications, only 52% update these components when a new security vulnerability is announced. In my mind, these numbers are a red flag. If you leave the responsibility for component maintenance to developers, be sure to allow them to do so.

What does it look like? Making component use work begins with technology that creates a dynamic inventory of components used and their locations. Ideally, this inventory would include information as to whether the specific vulnerable feature is being used and advice on how to troubleshoot security issues. This way, when a large vulnerability makes the news, developers have the information they need to resolve the issue quickly. Accelerate the developer process even further by creating a repository of developer-approved components, taking the guesswork out of component security, and dramatically reducing downstream labor.

At the end of the line

The reality is that developers have to use components, have to use components, and want to use components. But that reality requires both more education around component risk, and the tools and technology that allow developers to keep using components, but in a secure way that doesn’t slow them down.

Copyright © 2018 IDG Communications, Inc.

Source link


Comments are closed.