• Jeff Luszcz , Vice President of Product Management at Flexera


• 03.08.2018 07:15 am
undisclosed , Jeff Luszcz is a Vice President of Product Management at Flexera. Previously, Jeff was Founder and CTO of Palamida. He has helped software companies learn how to use open source while complying with license obligations and keeping on top of security issues.

Only a decade or so ago, organisations knew exactly what was being written and used in their software applications because employees were responsible for the building and, occasionally, the management of a few third-party components.

Today, the story is very different. Because of the availability of millions of free open source components, the volume of third-party components used has increased significantly. In fact, up to 50 percent of the code found in commercial software packages is made up of open source or commercial components. Along with that use, comes the onus to understand legal, security and compliance obligations.  In the banking and finance industry, with regulation and enhanced compliance oversight; and the responsibility of managing trillions of dollars for customers and stakeholders; it’s critical to have a complete view of open source software (OSS) use and the inherent associated risks. In other words, it’s imperative to make the “great unknown” known.

There are steps that organisations can take, to not just manage security vulnerabilities, but take advantage of the benefits provided by OSS, including the cost savings via:

1. Creating an educational programme for all levels in the organisation

As with other security and compliance tasks, there isn’t a single solution to addressing the business processes required to manage these actions.  At the heart of putting in place a solution is enacting an education programme to help all levels of your organisation understand the obligations and management needs required by open source and third-party software.  At the most basic level, anyone tasked with building or managing a software product should have at least a passing understanding of open source licensing, compliance obligations and your organisation’s processes and requirements to manage them.  The act of deploying or distributing software often requires a long list of obligations to be followed (such as giving credit in about boxes or sharing source code used to build the application), but current data shows that most organisations are out of compliance with even the most basic view of license compliance.

To successfully manage these obligations, development teams must be given time to actually comply with the requirements. Any organisation that doesn’t have explicit gates or time allotted to confirm compliance, can’t be expected to be in compliance!

Often, training around open source is limited to basic compliance discussions and is typically only required when an employee is first hired. This leads to a few problems. The training is sometimes rushed, limited in scope and lost in an ocean of other onboarding activities. 

In fact, training should occur yearly, especially as new policies are enacted, and the level of compliance and management in a company increases in maturity. It should include security and non-compliance topics, as well as expanded topics around selecting components, complying with open source license obligations and working with open source projects on code contributions. 

1. Developing an Open Source Review Board to set policy

Regardless of the level of education, and time set aside in the schedule, there will still be questions that can’t be answered by line-level engineers.  This is where an Open Source Review Board (OSRB) can be used to manage requests for assistance as well as set policy for the proper use of third-party software.  While they’re commonly known as “OSRB”, they’re often tasked with managing open source and commercial, third-party components.  The OSRB commonly comprises representatives from legal, engineering, security and other interested parties.  Additionally, the OSRB can be a loosely organised group of individuals meeting in an ad-hoc manner, all the way to a highly structured dedicated team.

The basics of an OSRB is that there’s a team tasked with answering policy and permission requests, managing non-trivial compliance tasks and providing institutional memory around OSS decisions.

Supporting remediation of license compliance problems is a core role for many OSRBs. This can include helping surface the problem, managing the remediation process and sometimes bringing in outside help to mitigate serious problems.

An OSRB should work with the training teams to update training content to reduce the load on the OSRB. They should have clear ways to be communicated with, and lastly should set clear expectations on what their role is. An OSRB that never gets contacted by developers leads to compliance and security problems that could have been easily prevented. 

The OSRB also should be looking to the future to anticipate future OSS needs. This includes selecting tooling to manage OSS, discovering new risks, or tracking legal changes like the GDPR or other regulatory changes.

1. Establish best practices including knowing and following through on OSS obligations

An important part of building this knowledge and putting lessons into practice is to confirm that best practices and obligations are indeed being followed. Confirmation that each application has the appropriate attribution or license disclosure is very important.

Making sure that you’re using the most recent patched version of a software component is important to stay ahead of vulnerabilities in the field.  Managing well-known components like OpenSSL, which have periodic disclosed vulnerabilities, is an important aspect of staying safe.  Also, key is discovering embedded components and less commonly seen ones.  This level of detail helps remove risk with every new component that gets discovered.

Increasingly companies are finding that they’re required to provide open source disclosures and enact vulnerability patching schedules based on contracts signed with customers, vendors and commercial suppliers.  The financial industry also finds itself needing to follow regulations and certifications.  Many of these require an understanding of who wrote the software and how it was assembled. The software supply chain has grown very long in the last decade, and you’re not always able to get things documented or fixed quickly due to this change.  You’ll also find that you may be responsible for all the vulnerability and compliance problems you inherit from this supply chain.  To put is simply, the buck stops with you.

A set of checks and balances should be put in place to ensure that compliance tasks are being performed. This includes setting a standard to which engineering teams are expected to follow, requiring developer or manager sign-off of release disclosures, and in some cases, having an outside team do spot checks or a full review. 

Checklists and expectation setting through policy documents are very helpful in setting the expectations for compliance and security reviews. A centralised repository of best practices and other OSS management documents should be created and periodically shared with development teams. Feedback from the development teams should be incorporated in updates to the best practices as well as reviews of similar documents from similar companies.

Through educating your development community, proper discovery of your third-party dependencies, and continuous management of these dependences and their potential vulnerabilities, you’ll be able to stay ahead of security and compliance issues in your products.  Additionally, you’ll be better able to take advantage of open source’s benefits beyond just cost savings.  By understanding the OSS development model, you can create new open source packages, contribute to existing ones or better manage your use of them.  Without management’s attention none of this can get done.  Your developers and your customers will greatly benefit from your time and guidance.