How to Set Up an Open Source Strategy
Table of Contents
Open source components have become the basic building blocks of software applications, comprising 60%-80% of the software projects. As open source usage has established itself as an industry standard and the default choice of software production, software development organizations are required to set up an open source strategy.
Gone are the days when the standard practice was to choose open source components seemingly at random with no regard for checking for security vulnerabilities or open source licenses. There was no deep-dive into dependencies, no strings attached. This left organizations open to both security vulnerabilities and non-compliant usage of open source components.
Development teams today are under orders to create a strategy for their open source usage to keep their products secure and compliant. They need to build an open source strategy that addresses all aspects of open source usage, from selecting components, integration with their proprietary code, to bug detection and license management.
The importance of adopting an open source strategy
The choice to invest in an open source strategy is primarily a business one and its logic extends from other fields of business development wherein a similar rise in formalization, standardization, and documentation is already underway.
Once a company reaches a critical mass of activity, it can easily fall into an endless stream of oversights, loopholes, and casualties. It is then that companies begin to feel the need for a strategy; a “think first” approach to efficiency, profitability, and growth prospects.
Looking at the dollars and cents of remediation efforts, organizations do the math to understand that it is more cost-effective to set up an open source strategy that will keep them on the right side of security and compliance than it is to repair damage once it is already hit.
The open source program office
Companies across all industries are ushering in ‘Open Source Programs Offices’ that implement an organizational strategy to ensure open source components are used securely and compliantly by all teams.
The central nervous system of open source usage within a company, these hubs establish an open source strategy that implements policies surrounding code selection, component adoption and usage, and auditing practices. Open Source Offices train new developers on the company’s open source strategy and ensure open source security and license policies are followed.
Such offices have been popping up at an increasing rate, and many enterprises are choosing to scout out open source leaders to head up these teams. They are utilizing these open source strategy superstars to manage their policy on a team level, operating on a local basis instead of corporate-wide.
Open source strategy: Key considerations along the way
These are a few of the steps that need to be put in motion when planning your organization’s open source strategy.
#1 Establishing an open source office
Where, under which department, should the Open Source Office sit? Who will the Chief Open Source Officer report to?
This is not simply a chain of command question, but rather a question that requires an examination and mapping of the company’s focus. Software companies will want to have the Office under their R&D departments, whereas companies with extensive intellectual property portfolios may want to place the office under their legal departments.
Once the decision involving the Open Source Office is made, it sets the tone for the open source strategy that will follow. It is here that rules and guidelines for working with open source are formulated and distributed company-wide.
#2 Formulating an open source strategy
How will your strategy address open source security and license compliance? You will need to decide which open source licenses you are willing to use in your products and which should be prevented from entering your code. The quantity of code, with multiple licenses, requires that you use automated solutions to enforce your policies, ensuring that those licenses that you do not want developers to use will be banned from entering your system.
Similarly, you will need to put in place security restrictions, setting your governance policies to allow open source components that are deemed acceptable for use without additional review, whereas others may need a team leader to sign off on a potentially risky component. In more severe instances, you can use automation to block risky open source components from entering the product, even failing the build if need be to keep the code base safe.
Another strategy wrinkle that needs to be ironed out before incorporating open source components is a company’s open source reporting policy. As a vendor servicing clients, any company selling a product that contains open source elements must provide due diligence, in the form of an attribution report, to its customers. Rules of disclosure will require that a company provide its clients with a package name, version, original download URL, license obligations, included dependencies and developer’s point of contact for every piece of open source used in their software.
#3 Implementing an open source strategy
Establishing an open source strategy begins with understanding that open source management has its particular set of challenges that are separate from those of proprietary and even third-party commercial code.
While most rely on the National Vulnerability Database for security updates, often important information will be posted first to a variety of other security advisories or issue trackers. To ensure that developers are using updated and secure open source components, organizations must integrate the right tools for identifying the components in your development environment or products, and matching them with the distributed information sources regarding which ones have known vulnerabilities that pose a risk to your products.
Only Software Composition Analysis (SCA) tools bring the automated solutions to aggregate all of the relevant information, identify and monitor open source components at scale, issue alerts when new concerns arise, and run at the speed of DevSecOps.
Open source strategy: A plan of action
Establishing an open source strategy begins with a milestone event: carving out a place in the corporation for open source management. This step must be taken with the understanding that open source security and license compliance have their particular set of challenges that are unique to those of proprietary code and even third-party commercial contribution.
Purposeful adoption of open source should be part of a corporation’s larger governance strategy as far as it pertains to security and licensing of third-party and open source contributions. It is up to the open source experts in the company to put together a strategy for open source automation, documentation, vulnerability detection, remediation, and licensing compliance.
