If your organization is developing applications, it's likely that some of the code is borrowed from open source software that can be found freely on the Internet. While such code makes developing applications much easier, its use can come with legal hoops to jump through and security vulnerabilities that, if left unmanaged, could pose significant risks to the organization. Conducting an audit of the use of open source software code can help companies get a handle on this emerging risk area.
"It's a big risk that maybe doesn't have a lot of awareness in many organizations," said Bruce Carpenter, vice president of internal audit at NVIDIA. Among the biggest problems is that developers in the organization may "cut and paste" open source software code for applications they are developing in-house, and not track its use. "There are a lot of bad things that can happen if you are not tracking open source software," says Carpenter.
Open source software (OSS) refers to software where the source code is made available to the public, generally in libraries on the Internet. Anyone can modify, improve, and incorporate the code into other works. There is estimated to be about 4 billion pieces of open source software, much of it available online. Rather than reinvent the wheel each time a developer needs to incorporate a certain function or feature into an application they are creating, they can plug in code from OSS to do the job.
The typical application has about 50 percent OSS code, and that number is increasing, said Jeff Luszcz, founder of Palamida, a company that makes tools to find and track open source software. Luszcz made the case, along with Carpenter, for auditing the use of OSS code during a recent conference for internal auditors. According to Luszcz, while organizations are using more OCC code, they can identify only about 2 percent of it. "Many software developers aren't paying attention to the licenses and obligations of OSS. They are focused on the features," he said.
The biggest danger of ignoring OSS licensing obligations is that it could force an organization to release its proprietary software publically as open source. "If you need a carrot to make developers pay attention, that is one of them," said Carpenter.
Compliance obligations aren't the only reason to track and manage the use of OSS. Security vulnerabilities often found in open source need to be patched or fixed. Not addressing these flaws leaves companies susceptible to attacks. In 2014, for example, the Heartbleed computer virus was found in OpenSSL, a popular piece of code that provides cryptography functions. A fixed version of the code was released on the same day the Heartbleed bug was disclosed, but organizations that weren't sure if they were using OpenSSL had no easy way to make the repair.
Developing an Open Source Process
During the risk assessment process, internal audit can take some simple steps as the department works to determine if the unmanaged use of OSS could be a problem in the organization. The first is to do some simple searching in application code for mentions of open source licenses. "If you are starting from zero, the first thing you want to do is some simple discovery of license text," said Luszcz. He says internal audit should also conduct interviews with software development professionals in the organization to gauge the use of OSS, and how well it's being managed. Something to watch out for is that developers will often underestimate the amount of OSS they are using. There are also more advanced tools to search for OSS code. Luszcz says a company may consider calling in a third-party expert to help with the search, which can be complex.
An audit of the use of open source software would look at the steps in a process to identify, track, and manage the use of OSS code. The pair identified the following steps to assess:
- Check employment agreements for developers that may contain clauses covering the use of open source code. According to Carpenter, old agreements may contain provisions that prevent its use, which isn't ideal in today's environment.
- Conduct a full scan of all software applications for OSS code. Tools are available that can match code with a database of OSS code, and identify most instances of OSS programming.
- Establish a clear policy. The policy should cover who is in charge of tracking and managing the use of OSS, how that use is documented, and how disclosures are made and compliance with OSS obligations is done. Developers should follow the process every time they use a piece of OSS code, and monitoring should be done to ensure they are.
- Create a training plan. According to Carpenter, OSS is a complex area and developers need plenty of training on how to safely use OSS, and how to manage the process to make sure compliance obligations are met.
- Establish an OSS review board. A board should meet regularly to review the use of OSS and ensure the process for disclosure and obligation compliance.
- Create a process for code storage that includes where the code is stored, that it is labeled correctly, and all instances of OSS are properly disclosed.
- Review third-party software development processes that touch the organization to ensure they are meeting OSS compliance obligations and fixing all vulnerabilities. It should include a review of cloud providers.
Companies may particularly want to review the use of OSS and processes to meet compliance obligations if they are involved in M&A activity or facing litigation involving software applications. But they don't need to wait for those reasons to conduct an audit. "As auditors, there is a big opportunity to ensure that there are good OSS processes in place or to be a spark for putting them in place," said Luszcz. "It can be a very productive audit."
Carpenter agrees that it can be an important project for internal audit to undertake. "Don't assume that someone in the organization is asking these questions," he said. "It could be going completely unmanaged."