For years, organizations have “checked the box” by doing the minimum to meet security standards like PCI and FS-ISAC, but a rising tide of breaches has caused most auditors to look more seriously at organizations’ security practices, including the security of open source components. Do your developers use open source components? Are you prepared to answer regulators about their safety?
Regulations that will look at the security of open source componentsThere are several industry regulations and security frameworks that require that you find and patch known vulnerabilities in your applications, including:
PCI DSS 6.1 / PA-DSS 7.1 : Requires the establishment of a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium” or “low”) to newly discovered security vulnerabilities. Financial Services Information Sharing and Analysis Center (FS-ISAC): In its guidelines, " Appropriate Software Security Control Types for Third Party Service and Product Providers ," this Working Group recommends financial services member firms adopt three control types. Control 3 is “policy management and enforcement for consumption of open source libraries and components.” In addition, it recommends a bill of materials that clearly identifies the open source code libraries that are part of a commercially developed software package offered to financial service firms. The Group states that it “believes that each of the three control types are required for financial institution member firms to achieve third party software security.” NIST 800-53 Security and Privacy Controls for Federal Information Systems and Organizations (SA-12, Supply Chain Protection) NIST 800-161 Supply Chain Risk management Practices for Federal Information Systems and Organizations (CM-8, Information System Component Inventory) HITRUST CSF v8 (Control of Technical Vulnerabilities): The HITRUST CSF was developed to “address the multitude of security, privacy and regulatory challenges facing healthcare organizations.” OWASP Top 10 compliance (referenced in compliance criteria such as those put forth by PCI Council, NIST, HIPAA, SOX, FTC, ISO 27k, DoD, etc.): Requires organizations to maintain an inventory of third-party components and libraries and monitor that inventory for known security vulnerabilities. How to meet compliance requirements and continue using open source componentsAs software has become a competitive differentiator for enterprises, so has the pressure on developers to get working code out the door quickly. With this need for speed, creating all code from scratch is simply no longer feasible in many cases. Integrating open source components into the code they are writing has, therefore, become a standard development practice. And rightly so, why reinvent the wheel if you don’t have to? The problem lies with the security of these components and, increasingly, the pressure regulators are putting on enterprises to provide proof of their security.
Restricting the use of components is not the answer; getting visibility into component use is. Unless developers carefully keep track of each open source component they use, companies do not have a list of components and versions. For large, global development teams, tracking open source components becomes particularly unmanageable and unrealistic. For example, when an open-source vulnerability is publicly disclosed, security professionals have no way of knowing whether or not their software has been affected. This lack of visibility not only makes it very challenging for security professionals to understand and decrease the risk associated with their applications, but it also ups the chances of failing compliance audits that require known vulnerabilities to be remediated.
The solution? Consider implementing technologies to keep track of which applications are using each component and what versions are being used . This gives your organization an easy way to update a component to the latest version if a vulnerability is discovered. And, ultimately, it keeps developers creating and innovating quickly, without introducing additional risk.
Looking for more tips and advice on your biggest AppSec challenges? Get them from someone who’s been there check out our new eBook, 5 Lessons From an Application Security Pro .