Modern software is assembled using a wide variety of re-usable software ‘building blocks’ which are largely open source components downloaded from public repositories or third party commercial components. These software building blocks enable development teams to quickly add robust features to their applications, however most organizations have very little visibility into the volume, variety and quality of components that are used.
In software development, a “supplier’ is usually an open source project that contributes components to the open source community. Once uploaded to public repositories, their components remain available forever, even after newer, safer, better versions are released.
The repositories host every component and version that was ever released. For example in the Central Repository of java components there more than one million unique open source component versions, many of which have known security vulnerabilities or defects. Since developers don’t have the visibility to choose the best component, a high volume of vulnerable executable components are inadvertently downloaded and used in today’s applications.
As time goes by, the quality of a component often diminishes. Vulnerabilities might be discovered by the supplier themselves (open source project), or by component users or by security researchers. The project reports the vulnerability to the National Institute of Science and Technology (NIST) which assigns a CVE (Common Vulnerabilities and Exposures) describing the issue in the National Vulnerability Database (NVD). However there is no communications channel between the open source projects or NIST and the consumers of the components, thus high volumes of known vulnerable components continue to be downloaded and used. Of the 17.2 billion component requests from the Central Repository in 2014, 52 million had known security vulnerabilities. Not surprisingly, of the 106 component ‘parts’ used in a typical application, on average 24 have known cyber vulnerabilities, which are rated either critical or severe.
Some application security risk is unavoidable. It's impossible to write 100% perfect code and bugs and mistakes may happen which will introduce unknown vulnerabilities into your custom code. However, shipping applications with known open source vulnerable components is 100% avoidable, thus cyber insurance companies, lawmakers and industries are tightening up guidelines and expecting more due diligence from software providers.
A software bill of materials is an inventory list of all components used in an application, including open source executable components. It can also include information about any known security vulnerabilities, and point to restrictive licenses and quality issues. Sonatype’s Application Health Check can be used to quickly generate a free software bill of materials.
Without a software bill of materials, organizations can’t easily locate or remediate a defective open source component vulnerability. If a newly discovered vulnerability is announced, it's hard to know if the component is used and, if so, where. For most organizations without software supply chain visibility and automation, research requires manual assessment of dozens – even hundreds or thousands of applications. You can’t remediate a known vulnerability unless you know that you have it, then you need to prioritize the remediation efforts which can sometimes takes months or years. For example a full year after the critical Heartbleed vulnerability was announced, research showed that only 50% had completed remediation.
Lawmakers are evaluating measures to ensure that software sold to the U.S. government is free of known vulnerabilities. The Cyber Supply Chain Act, otherwise known as the Cyber Supply Chain Management and Transparency Act of 2014 proposes that “ …any organization selling software, firmware or products to the federal government provide a bill of materials of all third party and open source components used, and demonstrate that those component versions have no known vulnerabilities.”
Many security vulnerabilities are well known and published in public sources, such as NIST. Failure to avoid using known vulnerable components may suggest a failure to perform even basic due diligence. As was reported in Wired Magazine, Sony Getting Sued by Former Employees , “We’re seeing courts more willing to entertain these kinds of lawsuits because the problems are real–particularly if you have evidence of a history of known security flaws that went unfixed–a court would be more likely to consider a suit by employees or other harmed parties.”
The Open Web Application Security Project (OWASP), PCI, and FS-ISAC are among the organizations mandating that steps be taken to avoid known component vulnerabilities. Well respected for their role in establishing application security standards, OWASP announced in 2013 that A9 on their top ten threats is to “avoid using components with known vulnerabilities."
Organizations relying on cyber insurance may find it difficult to get a claim from a breach unless they “follow minimum required practices” to avoid security issues. According to Big Data Tech Law, in June of 2015, the Columbia Casualty Company (CAN) sued its policyholder, Cottage Health Systems, claiming there was no coverage for the $4.1 million settlement paid to approximately 51,000 plaintiffs. “At the end of the day, cyber coverage premium dollars are well spent only if covered losses are paid by the insurer, and the CNA case teaches that scrutiny is needed long before a loss is incurred in order to maximize the opportunities for recovery.”
Increasingly, it is ‘open season on open source’ with adversaries finding known vulnerable components an easy target and force multiplier. Unfortunately, adversaries can easily check the NIST database for newly discovered CVEs (Common Vulnerabilities and Exposures) and launch attacks on organizations long before they even know the vulnerability was announced. According to the Verizon Data Breach Investigations Report, software is the most attacked because it is the most vulnerable -- ten CVEs accounted for almost 97% of the exploits observed in 2014 and 8 of those 10 had been fixed for 12 years.
Most components – even in the world of open source – have intellectual property licenses defining how the component may be used. Components with a restrictive license or no license should be avoided, as they introduce potential copyright risk to the organization. “Copyleft” licenses, like the GNU General Public License (GPL), require you to license applications you distribute under the same Copyleft license even if they just include a single component licensed in this way. This type of license is generally incompatible with commercial software because it requires that the application’s source code be made available to the users.