Times have changed in the software industry, and the management and best practices methods that were used just 10 years ago are no longer sufficient to protect your software product from new threats.
Some of these new threats force software vendors to take profitable products off the market, or are the result of being hacked due to a software vulnerability they didn’t even know they were exposed to.
So, what’s changed? Our industry has moved from one where almost every line of code was written by scratch, to one where more “wiring” than “coding” is being performed. The things being wired together are third-party components of all purposes and origins. These include open source and commercial components (also commonly known as libraries).
These components have rules and obligations that you must respect in order to use them legally. These rules are known as the software’s license. Additionally, as time goes on, software vulnerabilities are discovered in these components, and if a company does not work to upgrade or remediate the component, they may find themselves at risk.
In fact, open source and commercial component security and compliance risk is reaching epidemic proportions – threatening the very integrity of the software supply chain.
As much as 50 percent of the code found in most commercial software packages is made up of open source or commercial components. Most software engineers use open source software (OSS) and commercial, third-party components to expedite their work – but they don’t track what they use, understand their legal obligations for using that code, or the software vulnerability risk it may contain.
The Great Unknown
Worse yet, most software executives have no idea that this is going on. And if they don’t know what components are used, they can’t ensure the proper processes and automation are in place to address third-party security and compliance risk.
It is important that senior management confer with their chief technology officers, security officers and engineers to understand the state of their third-party compliance and security operation.
Banking and Financial Sector
This is particularly of importance in the banking and financial sector. It goes without saying that any industry tasked with managing billions or trillions of dollars must keep abreast of new threats.
Traditionally software was built line by line, file by file, by paid employees of the company who were creating the software application in question. In some cases, a few third-party components would be brought in to the product, typically through a commercial contract. It was very easy to know what you wrote, versus what you licensed in, since you would have paperwork or license keys that needed to be managed. Over the last decade or so, the software industry has greatly changed from this model. There has been a significant movement to using large amounts of third-party software components, especially ones of an open source origin. The availability of millions of high quality, free-of-charge software components has made it possible to build applications where more than half of the application was actually written by people not employed by your company.
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 Struts2 open source components.
The open source project OpenSSL made worldwide news back in 2014 when it was affected by the “Heartbleed” vulnerability which allowed for the remote collection of sensitive data held in memory, possibly leading to the theft of secret data and credentials. The vulnerability became one of the most well-known software vulnerabilities ever and resulted in actions to patch and upgrade the affected applications across the entire technology industry, with an emphasis on financial institutions.
More recently, the Apache Struts2 project was affected by a vulnerability (CVE-2017-5638) which allowed for Remote Code Execution (RCE) in affected applications. A vulnerability that allows for remote execution is one of the more feared vulnerabilities since it allows for targeted code to be run as desired. This could lead to financial theft, loss of credentials or the embedding of Trojans or similar malware.
The seriousness of this vulnerability and its related exploits also led to massive amounts of patching, application of firewall rules as well as log analysis across the financial industry.
The impact of both of these vulnerabilities shows the types of exploits that are affecting the financial industry and give hints to the potential of future vulnerabilities.
While most organizations were pretty sure they were affected by these vulnerabilities someplace in their organization, they were not able to quickly discover the exact product or location before significant time had passed.
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 organization 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 organization’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 organizations 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!
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 organized 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.
About the author
Jeff Luszcz is a VP of Product Management at Flexera Software. Previously, Jeff was Founder and CTO of Palamida. He has helped software companies how to use open source while complying with license obligations and keeping on top of security issues.