Open sign

IoT and open source: How to boost app sec by putting quality first

Developers often fail to effectively manage the security of the open-source components they use. Unfortunately, most software incorporates at least one vulnerable component, and that means that, unless developers keep on top of their repository, they are linking vulnerabilities into their code.

The situation is more dire when the components make their way into hard-to-update Internet of Things (IoT) software, as the recent Devil's Ivy vulnerability showed. Even if the developer quickly fixes the problems, most users of IoT devices will never update their software.

Organizations focused on software security, such as OWASP and FS-ISAC, have long urged companies to focus on securing their software. Now governments are inexorably marching toward requiring that developers and manufacturers have a plan in place.

In August, four senators introduced legislation that would mandate that the software and hardware for IoT devices for sale to the federal government must be clear of known vulnerabilities and a plan put in place to update the devices when vulnerabilities are discovered.

Perhaps the most difficult piece of the puzzle is open-source software. Nearly all software products contain some open-source components, and many developers, having incorporated a needed functionality, pay little attention to whether new vulnerabilities appear in the open-source code—vulnerabilities that could flow down into their product. 

Here are five steps that experts recommend to manage the risk of open-source software.

Application security best practices: An introduction

1. Build a bill of materials

Developers first need to know what components are in their software. For that, they need to maintain the equivalent of a bill of materials.  

Once a development team or project manager has created the list, and as long as there is no change in the dependencies, the company can gauge the risk every time a new vulnerability in open-source software is announced, said Tim Mackey, technology evangelist for Black Duck Software.

With a bill of materials, companies “can monitor for security-related issues or external risk elements that will impact the security of their product,” said Mackey. “So you are in a position to identify the risk to your customers of the continued usage of your product. … Because we can map to whatever that bill of materials are, you as a developer have an idea of what the ongoing risk might be.”

2. Know thy vulnerabilities

Developers also need to have an understanding of the risks that vulnerabilities pose for the open-source software that they adopt. If the software averages one vulnerability discovered per week but the development cycle calls for updating the product once per quarter, that poses a serious risk. 

In picking a component, developers need to make a decision based on whether the risk is acceptable. 

“Known vulnerabilities will have a CVSS score,” Veracode’s Chestna said, referring to the Common Vulnerability Scoring System, “so you can understand the severity of it, and you can decide what is the extent of the known risk, and does that risk affect customers of my products? In some cases, you can put a compensating control in front of it. In others, the security team might have an idea of how to mitigate the threat.”

3. Be wary of licenses

Open-source software also comes with a wide variety of licenses—far more than the GNU General Public License, the Berkeley Software Distribution (BSD) license, or the MIT License. There are more than 2,500 different licenses used by various components that are considered open source, according to Black Duck’s Mackey. 

“When people start looking in terms of shipping some form of intellectual property, having that level of understanding of what the obligations are with their mix of licenses is not something that most developers think about,” he said. “If they simply take that code and embed it in their project, they adopt the two major risks: the risk of license noncompliance and the risk of suitability.”

While many developers understand the potential for a license to require actions—such as re-releasing any code based on the open-source component—the risk of suitability is less known. In many cases, a developer may adopt a component or, through an application programming interface, an online component that works for the current purpose. But because of its license or overall code quality or coverage, the component may not be suitable for the product. 

4. Connect often with the security team

Developers and security professionals often do not get along. While developers are focused on shipping product, many security pros are considered to be blocking progress. Some developers refer to the chief security officer, for example, as the “CS-No.”

Yet, when an open-source project releases a vulnerability report for its software, it is often the security team that first hears of the issue. Good communication between the security team and the development team means that the problems get identified and fixed faster.

“Security is good at finding the problems, but developers are the only ones that can remediate and fix the problems. By working together, they are baking quality into the products from the beginning.”
Derek Weeks, DevOps advocate at Sonatype

5. Take part in the community

Finally, developers should not just incorporate open-source components into their projects—they should take part in the open-source projects. By contributing, or at least keeping abreast of a project, they are more likely to be aware of vulnerabilities and other security issues that affect the projects.

“If you have a dependency on it, you should be in a position where you know how to raise an issue with that component's development team,” said Black Duck’s Mackey.

“Is there any local community organizations that they can be part of? Even if it is a simple thing about going to a Node meet-up in their area, then they have invested in the future and sustainability of their project.”
Tim Mackey

Why the focus on open source?

Pete Chestna, director of developer engagement at software-testing firm Veracode, said, “In our studies, the two different types of software—open and closed source—look the same in terms of defects. But the problem is that no one looks at open source once they get it integrated into their code.”

“Open source code is not more or less vulnerable than first-party code.”
Pete Chestna

Today, 1 out of every 18 components that are downloaded from major repositories has a vulnerability at the time it is downloaded, according to Sonatype. If developers do not pay attention to the quality of the code and the impact that open-source components have on their software's security, they are putting their customers at risk.

“You cannot turn a blind eye to quality. No manufacturing organization on earth can sustain a high level of defects and maintain quality.”
—Derek Weeks

Developers should not think of these efforts as focusing on security, but on code quality. In many cases, adopting and managing open-source components do not pose any security risk. Regularly incorporating updates may cost some effort at the time of release, but that effort will pay off when a vulnerability is found and exploited in the wild.

“If you only think about it as a security problem, you miss the boat on all the small things you could have done in the first place, and you end up paying a greater cost and have to make more dire choices at the time it becomes a security problem,” Veracode’s Chestna said. “It's just good hygiene for development.”

Sonatype's Weeks is encouraged by the momentum in the direction of quality-first.

“The pace is a lot faster than I would have anticipated even two or three years ago. Whether the legislation passes or not, developers will have to have a growing interest in how software is composed.”

Application security best practices: An introduction
Topics: Security