There is a flood of new technology racing toward the financial services industry to create a complete and seamless customer experience for traditional, online, and mobile banking. Of course, technology is already deeply embedded within every FSI business, no bank or insurer could run without it, but most FSI organizations are struggling to secure the technologies they already use.
According to the recently released “State of Software Security in the Financial Services Industry” (SS-FSI) report, attacks resulting in customer data theft, system failures and downtime were experienced by more than half of the FSI organizations surveyed.
The survey illustrates the need for FSI organizations to focus more on secure coding training and using automated tools to find defects and security vulnerabilities in source code. Plus, they need more focus on an element that too many organizations currently disregard—software composition analysis (SCA) tools to identify possible security risks of open source components introduced by internal development teams or external suppliers.
The software supply chain presents a major risk to FSI
While most FSI organizations still develop their own software and systems, many are becoming reliant on third-party independent vendors to deliver the latest technology. While nearly three-quarters of respondents surveyed in the SS-FSI report were gravely concerned about the possibility of security vulnerabilities introduced by third-party suppliers, less than half of their organizations require third parties to adhere to specific cybersecurity requirements or to verify their security practices.
Few of the FSI organizations surveyed had an established process for inventorying and managing open source code either developed internally or delivered by third parties. That lack of management exposes those organizations to additional risk from vulnerabilities in open source components that they may not even realize are in their applications.
Do you have confidence that the open source components you use are cataloged and up-to-date?
Nearly 60% of all codebases used by enterprises contain at least one vulnerability from open source components, as reported in the 2019 “Open Source Security and Risk Analysis” (OSSRA) report, published by Synopsys.
Of the 1200+ applications reviewed by the Synopsys Black Duck Audit Services team in 2018, 40% contained high-risk vulnerabilities and 68% contained license conflicts.
When looking specifically at the financial services industry, the report found open source components in 100% of the FSI codebases audited during 2018, with more than 60% of the average FSI codebase comprising open source. Over 58% of the audited FSI applications contained at least one open source vulnerability, and 65% contained license conflicts, both in line with the overall industry findings of the OSSRA report.
With applications increasingly assembled from open source components, the potential for vulnerabilities turning into risk is magnified. Unfortunately, many FSI organizations don't know where their open source risks are because they are not managing their open source or the versions of the open source they are running. Their developers—internal or external—routinely take code from open source repositories to embed in their company’s products. While the efficiencies and cost savings of code reuse are clear, organizations rarely review the incoming code regularly for potential security and legal issues and remain uninformed about their open source risks and obligations they’ve acquired.
Towards better open source security for FSI
Use of open source itself is not risky, but unmanaged use of open source is risky. To defend against open source security and compliance risks, FSI organizations should take the following four steps:
- Create and enforce open source risk policies and processes, both internally and for third-party vendors.
- Educate developers about managed open source use, especially open source license obligations.
- Perform a full inventory of the open source being used in their applications.
- Put into place an automated process to track and manage open source use.
No single method, tool, or service will ensure complete security coverage for any FSI organization. The only correct approach is the one that aligns with, supports, and protects the business. A layer of automated tools, including software composition analysis; SAST, IAST, and DAST (respectively, static, interactive, and dynamic application security testing); and activities such as code review and fuzz testing are all needed to ensure security at every phase of the software development lifecycle.
With a stronger focus on open source identification and management, especially with incoming code from third-parties, FSI organizations will have a better chance of preventing attacks stemming from open source vulnerabilities.