AMERICAS BUSINESS
This change has happened faster than management best practices have been able to keep up. The knowledge of what tasks are required to get into legal compliance is lacking in most organisations. Additionally, without a system in place to keep track of the hundreds to thousands of third-party components you use (also known as the “Software Bill of Materials”) it is impossible to know if a reported vulnerability affects your product. Recent vulnerabilities that have affected the financial industry included ones targeting the OpenSSL and Struts 2 open source components. While most organisations were pretty sure they were affected by these vulnerabilities someplace in their organisation, they were not able to quickly discover the exact product or location before it was too late. Time for Education As with other security and compliance tasks, there is not 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 program to help all levels of your organisation understand the obligations 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 what your organisation’s processes and requirements to manage them are. 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, should not expect to be in compliance!
138 | Issue 8
Open Source Review Board No matter 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 the place that 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 are commonly known as “Open Source Review Boards”, they are often tasked with managing both open source as well as commercial, third-party components. The OSRB is commonly comprised of 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 manor, all the way to a highly structured dedicated team. Best Practices and Obligations An important part of building this knowledge and putting these lessons into practice is to confirm that best practices and obligations are being followed. Confirmation that each application has the appropriate attribution or license disclosure is very important. Making sure that you are 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 important is discovering embedded components and less commonly seen ones. This level of detail helps remove risk with every new component that gets discovered. More and more companies are finding they are 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 true an understanding of who actually wrote the software and how it was assembled. The software supply chain has grown very long in the last decade, and you are not always
able to get things documented or fixed quickly due to this change. You will 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. Through educating your development community, proper discovery of your third-party dependencies, and continuous management of these dependences and their potential vulnerabilities, you will be able to stay ahead of security and compliance issues in your products. Additionally you will 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.
Jeff Luszcz Vice President of Product Management Flexera Software