The Irish News has reported that cyberattacks are costing the Northern Ireland economy an estimated £100 million (€118 million) a year. Today, more than 80% of cyberattacks target software applications. Unsurprisingly, there is an array of application security tools to help companies address security risks, varying in both approach and coverage. For example, traditional application security tools – Dynamic Analysis Security Testing (DAST) and Static Analysis Security Testing (SAST) – are effective in finding bugs in the application code internal developers write. However, they are not as effective in identifying open source software vulnerabilities. Most open source vulnerabilities are reported by security researchers and not found by DAST and SAST application security tools.
Open source is an essential component in application development worldwide, with open source components comprising 50% or more of most applications. This makes open source vulnerability management imperative. Yet, many companies remain ill-informed about the amount of open source used in their applications, and blind to the vulnerabilities that may be in that open source. Audits of customer codebases consistently show that most organisations are using twice as much open source as they are able to track manually. Given the speed of development cycles, failing to include open source vulnerability management as part of comprehensive software testing process increases security risk.
Neither more nor less secure
Open source is neither more nor less secure than commercial software. However, open source vulnerabilities do pose unique security risks. Open source is used everywhere. Because of its ubiquity, attackers see popular open source components as a target-rich environment with information publicly available on known open source vulnerabilities as well as detailed information on how to exploit them. As soon as a vulnerability is reported, a means to exploit that vulnerability is almost always simultaneously published. It should be noted that patches for these vulnerabilities are often published just as quickly. But the fact remains that unless an organisation is aware that a vulnerable component is included in its application(s), it’s highly probable that that component will remain unpatched.
For example, Heartbleed, the infamous security flaw, critically exposes OpenSSL, an open source project used in hundreds of thousands of applications that rely on it to provide secure communications over computer networks. Yet 56% of all OpenSSL installations that Cisco Security Research examined in its 2015 security report were still vulnerable to Heartbleed, more than two years after the Heartbleed vulnerability was first disclosed and a patched version issued.
This illustrates the difficulty organisations have in managing open source components rather than a lack of security diligence. Without knowledge of open source components in use, it is nearly impossible for any organisation to identify specific applications that use vulnerable components.
And open source vulnerabilities abound: reports show that on average, 67% of commercial applications contain open source security vulnerabilities. Since 2014 the National Vulnerability Database (NVD) has reported more than 7,000 new open source vulnerabilities.
A three-pronged approach
As mentioned earlier, while both SAST and DAST are effective in spotting bugs in code written by internal developers, they are not as effective in identifying open source vulnerabilities in third-party code, leaving major components of today’s applications exposed. Since 2004, more than 74,000 vulnerabilities have been disclosed by the National Vulnerability Database (NVD), but only 13 of those were found by SAST and DAST tools.
For example, per the National Security Agency (NSA), the average SAST tool can only find 14% of the problems in an application. Similarly, DAST is helpful for verifying compliance and finding misconfiguration issues, but is incapable of finding all vulnerabilities, especially those that enter code via open source.
An effective approach to addressing software vulnerabilities must:
- Examine custom source code for vulnerabilities during development (SAST)
- Test compiled applications for common runtime vulnerabilities (DAST)
- Ensure that open source use is not introducing security vulnerabilities during development and monitor for newly reported vulnerabilities after the application is deployed (OSVM – Open Source Vulnerability Management)
Rather than looking solely at custom-built code or open source, this three-pronged approach looks at all the application code and configuration. Using the right tool for each job accelerates software development while reducing risk throughout the application’s lifecycle.
Deeper dive
Organisations that adopt a three-pronged approach to eliminating software vulnerabilities should expect:
- Improved product quality through early identification and selection of secure components
- Security risk visibility across custom code, open source components, and application configuration
- Lower remediation costs for vulnerabilities detected and fixed early in the development process
- Minimised risk of security breaches from attacks targeted at known open source vulnerabilities
- Optimised security testing that is both effective and compatible with agile development tools and practices
- Protection from application security breaches throughout the application lifecycle
Key questions
As noted earlier, application security tools can vary in both approach and coverage. These questions can help you determine the right mix of application tools and capabilities for your organisation.
- What types of applications do you develop (e.g. web, mobile, installed, IoT, etc.)?
Mobile and IoT apps often require specialised (e.g. smart phone pen testing) tools, while standard Dynamic Analysis Security Testing (DAST) tools can be used to test most installed and web-based applications. - What types of networks will your applications LAN, wireless, etc.)?
The application security testing tools you select must allow emulation of the attack types that your applications are likely to face. - Do you have access to all the source code in your applications?
If you use a large number of third-party components in your applications, be sure your application security tools can analyse those components effectively. - What programming languages do you use?
Know what languages are important to you and verify that the tools you are considering support those languages. - How much open source do you use in your applications?
If open source comprises a significant percentage of your code, an open source vulnerability management solution is a must. - How will you track or test for new vulnerabilities after your applications ship?
It’s important to have tools to monitor and manage vulnerabilities in every version of your applications for as long as they remain in use. - What is your application development model?
Make sure your application security tools are compatible with the development methodology and tools you use. - Who will use your application security tools?
The tools you select should provide the right balance of sophistication and ease-of-use your team needs. - What is your application security budget?
It’s important to direct your application security budget where it will have the greatest impact. If open source is a significant portion of your code, make sure you allocate your spending accordingly.
Completing the picture
Traditional approaches to application security, involving only static and dynamic testing, can leave significant vulnerability identification and management gaps. Open source vulnerability management completes the picture, providing automatic identification and inventorying of open source software, mapping components to known vulnerabilities, and streamlining and securing CI/CD activities. A three-pronged approach, incorporating SAST, DAST and OSVM, ensures a comprehensive and in-depth assessment of security across the entire application landscape.
Security is arguably the most important aspect of open source usage in the enterprise. But other important aspects of open source use are also worthy of attention, such as license terms and conditions governing an open source component’s use and distribution. Organisations that publicly redistribute open source software outside the terms of its license are at risk for litigation, compromise of intellectual property, and potential delays due to remediation of open source use issues. It is equally important to audit and enforce compliance of open source licenses. All the more reason to include tools to discover, inventory and audit the use of open source in a comprehensive application security management solution.
Patrick Carey is director of product marketing at Black Duck Software
Ltd
