As with most technological advances that were once new on the scene, the story of open source’s rising star has its origins in academic and community ideas of resource sharing. It grew on the concepts from the old school hacker ethos of collaborative production and free access to code, that boldly went against the grain of proprietary code creation. Brave developers who “ventured west”, tapping into the unknown terrain of third party contribution and integrating it into the holy grail of their proprietary code.
The open-source-first movement turned a corner somewhere circa 2015, establishing itself as an industry standard that was adopted by the large corporates like Google and Facebook who chose to engage more broadly with the open source community to make their products more robust. By 2018 it is unarguably the default choice of software production.
As any project that matures to obtain mainstream status, the open source community needed to adopt a new approach that would fit its growing popularity. A “grown up” approach meant that a strategy needed to be established for the use of open source, as well as ways to monitor the components used, track bugs in the code, and offer fixes.
These days development teams are under orders to create a strategy for their open source usage to keep their products secure and compliant. They need to establish a policy that will encompass all aspects of open source usage, from selecting components,integration with their proprietary code, to bug detection and license management.
No longer a lone cowboy choosing open source components seemingly at random with no regard for checking vulnerabilities or if they were using the right licenses, no deep-dive into dependencies, no strings attached, companies across all industries are ushering in the age of the “Open Source Programs Offices’ that take the secure and compliant usage of open source components seriously.
The Open Source Program Office
Open Source Offices are designated work environments where open source consumption and production is supported. The central nervous system of open source usage within a company, these open source activity hubs establish policies surrounding code selection, component adoption and usage, and auditing practices. They train new developers on the company’s open source policy and ensure license compliance. In Microsoft, their “Open Source Programs Office” facilitates strategy and approval discussions and decisions throughout the company.
Such offices have been popping up at an increasing rate, along with many enterprises choosing to scout out open source leaders to head up these teams.
In the case of Microsoft, they are utilizing these open source strategy superstars to manage their policy on a team level, opting to operate on a local basis instead of one that is corporate wide.
The choice to invest in these new titles 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, companies do the math that it is more cost effective to strategize a policy and workflow that will keep them on the right side of security and compliance than it is to repair damage once it is already hit.
Open Source Strategy: 3 Steps Along the Way
Open source components are the building blocks of software, and are used by developers to create innovative products without the need to reinvent the wheel with new code. It provides them with powerful features that they need for their applications, saving them time and effort.
These are a few of the concepts that need to be considered when planning out your organization’s open source strategy.
Establishing an Open Source Office
It begins with a strategic consideration. 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.
Formulating an Open Source Policy
Once the strategic decision involving the location of the Open Source Office is made, it sets the tone for the open source policy that will follow. It is here that rules and guidelines for working with open source are formulated and distributed company wide.
These range from the percentage of your product which you would like to be open source — software these days rely heavily on open source, using it for 60%-80% of their code base — to the licensing policy you would like to enforce. You will need to decide which 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 utilize automated solutions to enforce your policies, ensuring that those licenses which 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 which 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 actually block risky open source components from entering the product, even failing the build if need be to keep the code base safe.
Another policy 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 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.
Implementing an Open Source Policy
Open source usage cannot be lumped in with the greater group of third party contributions and, as we have discussed above, requires a different set of policies.
As its name indicates, commercial third-party applications are purchased from the companies that develop them. These pieces of code have a licensed go-to mother and father who are responsible for their legality and functionality. Moreover, since this code is written by a single organization, it is a bit easier to manage when it comes to receiving updates on issues that can arise, whether they be for security or quality concerns.
Conversely, open source components are usable for free so long as they stick to the terms of the license and the responsibility for their maintenance is distributed amongst the members of the project’s managers and contributors. The practical implication is that information regarding new vulnerabilities or other issues is not held in a central location. While there are major databases like the National Vulnerability Database (NVD), often times important information will be posted first to a variety of security advisories or issue trackers. So even as open source can save developers a ton of time, it needs to be managed differently, using 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 can 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 DevOps. .
Due to the responsibility of use falling to the shoulders of the user, it is paramount to have a company strategy around vulnerability detection and remediation before any commitment to open source usage is made, and of course adopt the right tools for the job.
Summary: A Plan of Action
Any company looking to bring in open source needs to first define its goal. How heavily will your product rely on open source components? How will open source integrate with your proprietary code? What kind of functionalities in your product will you want open sourced? Are these key functionalities that affect the basic workings of your product? Once the goal is set, it is time to strategize how to evaluate, join, launch, utilize and maybe even contribute to the open source community.
Purposeful adoption of open source needs to be part of a corporation’s larger governance policy as far as it pertains to security and licensing of third-party contributions.
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 has its particular set of challenges which are wholly other to those of proprietary code and even third-party commercial contribution.
From there on out, it is up to the open source experts in the company to put together a strategy and a policy for open source automation, documentation, vulnerability detection, remediation and licensing compliance.
*** This is a Security Bloggers Network syndicated blog from Blog – WhiteSource authored by Anat Richter. Read the original post at: https://resources.whitesourcesoftware.com/blog-whitesource/open-strategizing-key-considerations-for-an-open-source-strategy