Are Developers Responsible for Open Source Governance?

There are lots of factors in the open source software world converging to make it a big year for “shift left” in software development. Heightened security concerns, an increasing need for software supply chain visibility and the growth and complexity of open source ecosystems will continue to push the responsibility for ensuring code is secure earlier in the engineering process as far left as the request and design phases.

This means 2021 will be yet another year in which developers are challenged to take on more responsibility, and pushed further onto the front lines of open source governance. Developers will need access to the right training, resources and tools to do this job. But they also can’t be successful if they’re expected to do it alone. Shift left can’t mean shifting all responsibility to the developer as the sole protector of secure code and the only go-to open source expert. The reality is that the depth, breadth and complexity of open source governance in 2021 demands a cross-functional team and layered approach.

Equipping Developers With Governance Knowledge

Let’s start with how to better equip developers and other stakeholders in the governance process, including legal, security, IP compliance and product people. These teams need enough knowledge to be aware of the top compliance issues, and their corresponding remediation options, to be active contributors in this rapidly evolving space. Research from Forrester shows that of the top 40 computer science programs in the United States and the top five programs internationally, none include open source licensing and security coding practices in the curriculum.

Instead, it has fallen to the industry itself to impart this expertise on the job. Leading companies are packaging open source training programs into something that resembles standard HR-led and managed training, including check-ins and quizzes to test and solidify knowledge, and regularly updating content and scheduling trainings to make sure people stay abreast of changes and challenges. In the spirit of open source, many industries work collaboratively to share best practices on governance in this regard, with industry experts speaking on the topic at other companies. Others are leveraging existing management training courses, such as the ones offered by the Linux Foundation.

The growing importance of the Software Bill of Materials (SBoM) also points to the need for cross-functional collaboration. Software supply chain visibility will become even more crucial in 2021 so that companies can build and sell secure and safe products, as well as ensure compliance. More people across the organization will need to access and view the SBoM in ways relevant to their functional needs. As a result, its assembly is transforming from being assembly-line-esque (passed along and viewed in the context of siloed business functions) to becoming much more collaborative. The SBoM is becoming akin to a business intelligence tool, providing the ability for different functions and stakeholders to filter for relevant information.

Depending on your function, you may be interested in a top-down view of the open source and third-party components across your portfolio of products in order to understand risks in the organization. For instance, as an engineering leader, you may want to understand if you are impacted by a new security vulnerability, where in your portfolio of products you may be exposed and the current status of remediation work for that vulnerability. If you are in legal, you may be interested in a significant licensing change for a component in use at your organization. This allows you to be prepared with changes to legal policies for automated reviews and obligation fulfillment guidance for engineering when the next build occurs and a more recent version of a dependency is pulled in. If you are in the export control function, and are required to provide your application’s encryption capabilities as part of the certification process, understanding which open source components are part of the application, and which provide cryptographic capabilities is essential. Finally, don’t overlook your customers, who today are requiring open source disclosures as part of commercial software contracts to protect themselves from insecure software.

Collaboration has also been made simpler by the fact that new industry standards now enable an asset portfolio view of open source security. Open Chain obtained ISO certification in late 2020, ISO/IEC 5230:2020, providing a clear and effective process management standard for open source license compliance. It allows companies of all sizes and in all sectors to adopt the key requirements of a quality open source compliance program. Coupled with ISO/IEC 27001–the de facto standard for managing security in information security management systems (ISMS) – organizations can now take a more holistic view of all of their software assets in an effort to make the information they hold more secure.

Open Source Program Office

The best way to ensure developers aren’t left footing the bill for open source governance is to create a centralized team dedicated to it. Savvy organizations could form an Open Source Program Office (OSPO), which brings together key stakeholders in legal, engineering, product and security to develop, communicate and operationalize open source strategy for their entire organization. This team works to define a framework and process for consuming open source software as part of their development work (inbound use case) and/or contributing code to the community via open source projects (outbound use case). The mission and main charter of these teams is to help their organization create and manage an open source strategy in terms of the adoption, use, support, participation and development of open source software. However, they’ve also found their role has evolved to become the experts on open source internally and evangelists of the technology and its use.

The bottom line is that the developer’s job is to develop software – and every piece put in place for stronger open source governance means less time spent focusing on the problems that could be in the open source code and more time on the promise of using it to rapidly innovate for the benefit of their customers.