Just as software security has become strategic for many organizations, so too has the use of open source in development become strategic. And, as organizations realized they needed to create the role of chief information security officer (CISO), they are now coming to understand the importance of creating an open source program office to be run by a chief open source officer (COSO).

The COSO’s function is to monitor and advise corporate finance on the use of open source within the organization. Yet, until recently, searches for people who actually use the COSO title yielded few results.  

The main reason developers are grabbing open-source components and libraries is because of the pressure on them to deliver software faster. According to Javier Perez, chief open source evangelist and senior director of product management at software company Perforce,  developers know that if something has already been written, it will save them hours of work. If that piece of code comes from a company-supported project, or one that has a large community of contributors, it’s probably the most recent version and it’s likely to be secure. But, he noted, “There is still a lot of open source out there that has one or two or three guys working on it, but I think it just shifts the bottleneck from upfront, where it would take longer to write the code securely yourself, and just moves it down the line. Now we have to test it longer. This is the age-old argument of, are you sacrificing quality for speed? Are you sacrificing speed for quality?”

Few developers start from scratch anymore, Perez pointed out. “Everyone takes packages, and they don’t even know what they’re getting with the dozens or hundreds of packages they’re using for a specific library. Remember, open source is built with other open source, which is built for another open source … and that’s the full software supply chain.”

This creates challenges for software testers as well as security teams. Open source comes with dependencies upon dependencies, so tools such as software composition analysis and SAST and DAST give organizations insights into what vulnerabilities might exist in the code. And the chief open source officer can be on top of the teams to make sure they’re using the latest versions of the open-source software and ensure that they’re uploading fixes that erase vulnerabilities.

Further, a COSO can help define which packages or components are critical for the application being built, and can create a program on how the organization can work with the community behind that project.

This is why governance, coming from an open source program office, is critical for organizations who wittingly or otherwise use open-source pieces in their code. “Typically, the open source program offices start by the way not on security; they start on tracking open-source licenses. It’s very important especially if you are commercializing software, you need to make sure that you have the proper open-source licenses.” 

And as the offices grow, they have to define and implement some policies, working with the security and engineering teams, as well as providing education on open source and developing champions or experts that can help everyone else do their job. “Everyone is a consumer of open source, but not everyone is a contributor or maintainer of open source,” Perez said, so through training individuals can become contributors, or experts, who can now influence the direction of the software.