Best Practices for Open Source Governance
Table of Contents
Open source code is the unsung hero of modern software development, powering everything from small startups to global enterprises.
Yet, despite its ubiquity, many organizations remain in the dark about the open source components lurking within their applications. With industry giants like Forrester and Gartner estimating that 80-90% of commercial software relies on open source, it’s clear that a blind eye to open source management is no longer an option. But how is open source usage accounted for? How is it managed? Or is it?
In this article, you will learn how effective open source governance is essential to mitigate security, legal, and operational risks associated with widely used open source components.
This article is part of a series of articles about Open Source License Compliance
The move from blind eye to a governance policy
Historically, open source usage was largely ignored, with developers given unrestricted freedom to select components without documentation or oversight.
Unrestricted open source component selection often leads to unforeseen consequences. Developers, unaware of potential vulnerabilities, license implications, or the severity of security risks, can inadvertently introduce significant problems into the software development lifecycle, requiring costly remediation efforts.
In today’s fast-paced development environment, companies are grappling with how to effectively govern open-source usage while preserving developer agility and productivity.
A dialogue that needs to happen
Open source governance comes into play firstly as a conceptual idea. The idea being that an organization acknowledges the extent of its reliance on open source and agrees that there are too many risks involved in not knowing what components go into their code.
As open source concerns grow, organizations must engage cross-functional teams, including legal, security, development,and production, to understand current coding practices. This collaborative process informs the development of a governance policy that prioritizes developer feedback.
This is the move from a conceptual governance policy to a practical one. From the understanding that an open source inventory needs to be managed somehow, to the policy by which the company tracks, approves, controls and maintains the open source components used in its software. The practical manifestation of a governance policy encompasses a detection and approval process, an organizational chain of command to deal with open source usage, and a decision regarding the automation of these processes.
Real solutions for real problems
Open source code carries with it the potential for security, legal, and operational risks. If not handled properly, these risks can result in delayed release dates, extended go-to-market timelines, hundreds of thousands of dollars in remediation efforts, not to mention faulty usability and an unwanted customer experience for your end uses.
So what’s a CTO to do? The answer is two-fold. Primarily, avoid affected components from entering your code. Secondly, know about vulnerable components and treat them before hackers exploit them. The answer is, in other words, formulate a governance policy for your organization and execute it.
It is at the solution stage that a governance policy will get into the nitty gritty of choosing automation tools. Software composition analysis tools (SCA) come in all shapes and sizes and their functionalities vary from one product to the next. These tools range in ability from detecting vulnerable components in the pre-pull stage and blocking vulnerable components from getting selected by developers, to detecting vulnerable components already in your code and pinpointing their location. SCA tools can be set to fit the security measures decided upon in your governance policy, so that they block vulnerable components of a certain severity but not another.
