Automate Software Security Checks to Find Open Source Software, SDK Perils
The reusability and convenient utility of open source software (OSS) and software development kits (SDKs) has been a boon to mobile application developers. Both types of software shortcuts help developers save time and money and accelerate development life cycles.
The hockey-stick growth of SDKs in just the past five years has been phenomenal, and for good reason. A high-quality SDK typically provides a developer with many of the necessary features to build a dynamic mobile app. Coders know that a truly helpful set of tools and features can increase the versatility of their app, allowing it to appeal to a wider range of users.
It also happens that SDKs are a big driver of “the API economy” we keep hearing about. Modern SDKs are generally connected to back-end microservices that add rich capabilities via application programming interfaces (APIs). These API-enabled capabilities create new opportunities for individuals and companies to develop revenue streams by processing data from applications built with these OSS development kits. There’s great value in OSS, too, proven by the growing number of open source components in various applications.
The Risks of Using Third-Party Software
While the value proposition of using OSS and SDKs is obvious to most, there’s also a downside to incorporating someone else’s code into an application. One very big problem is that many times once included in a project, there is no distinction into what’s first-party or third-party code anymore. There is no separation, or “sandboxed,” environment in which the SDKs operate. They become part of a single unit of software, which means those third-party components can access the exact same actions, data and resources as the internal code, creating all sorts of potential risks. By including a third-party SDK, companies often give it full access to the entire app and all its data, as well as the device’s photos, contact lists, geo-location data, camera, microphone, etc.—not to mention the ability to tamper with secure communications (e.g. disabling TLS on all endpoints, not just SDKs). There does not need to be a malicious end goal, but blindly trusting someone else’s code with the same level of privileges as internal code could expose apps to all sorts of major security threats. There can be privacy violations, security vulnerabilities and other risks embedded in third-party code.
Consider what happened a few years ago with the OpenSSL cryptography library, a de facto standard open source software component whose implementation ranges from end user mobile apps to the immensely complex server infrastructures that power the internet itself. A bug dubbed “Heartbleed” made all of these systems vulnerable to information theft and eavesdropping on communications that developers had assumed were secure. While a fix for Heartbleed was developed and made available, there are undoubtedly some servers and apps that never got patched and which are still at risk from the vulnerability. Further, the duration and breadth of data breaches is still unmeasured from this open source vulnerability that impacted a large percent of the internet’s most visited sites.
The very nature of OSS means that an all-volunteer group of developers contributes to the code base, which is readily available to anyone. When a flaw is discovered in the software, developers can appeal to the volunteers who maintain that project to request a fix, but they are at the mercy of the volunteers’ time. Now suppose this flawed code is incorporated into commercial software applications. It’s the developers of those applications who must devote their time—or hire experts—to develop a fix to rid their software of the flaw. Of course, one big advantage of OSS is that such a fix can then be provided to the author or repository maintainers for everyone else to benefit from, but in the end the irony is that it can become very expensive, not to mention risky, to use free open source software.
There are examples of OSS authors intentionally adding malicious code to search for valuable data to extract for profit. For example, there was a widely used open source software JavaScript library downloaded more than 2 million times and used by Fortune 500 companies that had malicious code added in to help some of the open source authors steal bitcoin.
OSS is free for anyone to use, but that doesn’t mean there’s no cost to operate and maintain it, especially for SDKs. The time and expertise to create the software certainly isn’t free, so SDK developers often want something in return for allowing others to use their code. This “something” might be customer data or other sensitive information handled by the applications that incorporate their open source code. For example, a recent investigation conducted by TechCrunch revealed that certain analytics companies harvest screenshots and user interactions for their own use from applications that utilize the companies’ code. Commercial applications that leak data in this manner can be in violation of regulatory compliance requirements, or at the very least in violation of end users’ trust.
Ways to Find, Track and Fix Vulnerability Issues
Everyone can agree that software should not be released for general use if it contains vulnerabilities. This puts the onus on development teams and their security counterparts to ensure that unsound code in OSS and SDKs is found and fixed before use. Keeping apprised of the existence of software vulnerabilities is a daunting task.
There are resources available to help developers determine when there are known vulnerabilities in source code, such as the National Vulnerability Database (NVD) hosted by NIST. However, the NVD is very broad and it’s not specific to keeping developers up to date on the tools and products they tend to use. A similar resource is the Common Vulnerabilities and Exposures (CVE) database compiled by the government contractor Mitre Corp. The CVE system provides a reference method for publicly known information security vulnerabilities and exposures in publicly released software packages.
The drawback of relying on these resources to learn about software vulnerabilities is that the databases might not be comprehensive or up to date. Agency resource constraints can result in some flaws not being thoroughly researched and documented, resulting in significant lag time in reporting the vulnerabilities—if they are reported at all. What’s more, even after bugs are fully documented, it can be a long time before fixes are developed and made available to the public.
What if a bug is found in an OSS project and it’s critical to get a fix right away? The classic solution is to bring in consultants to address the issue. Though consultants might be costly, the expense can be worth it if the security issues are holding back the release of a revenue-generating application, or might put users’ data at risk.
Another option is to visit developer forums and see what recommendations peers can make. Many development teams use a peer review process before product release to have others manually check their work to determine if there might be problems with the code. Peer reviews, though helpful, are time-consuming and assume that the review team members are knowledgeable on all things related to security and compliance and will conduct their audits in a timely manner.
Automated Security Checks and Fix Recommendations are More Effective
A better approach is to automate the security validation checks of all code—including OSS, SDKs, and even external API-enabled services—and to incorporate this function into the existing application development cycle. This ensures that all necessary security checks, along with dynamic and static code analysis, are done continuously without the need for any sort of manual intervention.
There are security tools today that scan all the code of an application, including third-party code, to check for the presence of vulnerabilities and other issues such as data leakage. No specific security expertise is required to utilize the tools, which essentially do the job of human penetration testers in a much more efficient and cost-effective way. The insights and knowledge of a security team that would conduct application pen testing is instead built into the scanning engine to drive the security automation process. What’s more, these tools guarantee to stay up to date with the latest vulnerabilities publicly disclosed and provide explicit recommendations with secure code samples on how to fix them—something no vulnerability database can provide.
Applications increasingly reach out to external APIs on third-party platforms. A developer might not even be aware of this outreach if it happens through OSS or an embedded SDK. A security automation engine with a run-time dynamic analyzer can readily identify any APIs and whether they put the application’s data or compliance status at risk.
Automated security analysis can easily become part of the DevOps process. The results of the automated tests are fed back into the DevOps workflow, making security an integral part of the normal DevOps CI/CD cycle. Every time there is a code change, it can be validated automatically. Security validation is done continuously and at the speed needed to keep up with development processes today.
Virtually every application development team uses open source software, SDKs and third-party API services to reduce their development time and avoid reinventing the wheel. The best way to gain confidence in the use of third-party code is through automated security analysis and recommendations for fixing the vulnerabilities before software is released.
