The days of developers not keeping track of where they use third party libraries and not upgrading them are dead.
Why? Over the last year awareness of vulnerabilities in these dependencies has increased in general and also as security researchers have focused more heavily on finding vulnerabilities within libraries underlying many products across the software industry. Examples of such libraries include common Internet encryption open source implementations (OpenSSL), framework base modules (QT), as well as commercial Software Development Kits including from Esri (ArcGIS Runtime SDK for Android).
When Esri incorporates a third party (to Esri) framework or core component such as the ones above as part of our product code, we work to ensure they get updated as necessary along with supporting apps. Esri follows the same procedure when vulnerabilities are found in our own developer libraries (that both Esri Apps as well as our Developer Customer’s Apps depend on).
For example, after the ArcGIS Runtime SDK for Android vulnerability was found we have updated apps from Esri that depend on this SDK starting with Collector for ArcGIS version 10.3.1, followed by Explorer for ArcGIS version 10.2.8, and even more recently the Esri Lab apps Snap2Data and Snap2Map. You, as a developer dependent on this SDK should do the same.
If you download components or frameworks as part of an application build process, we recommend tracking vulnerabilities in those components over time to ensure they get updated in your applications. If you have built an app with the ArcGIS Runtime SDK for Android before version 10.2.6-2, we strongly recommend updating your app to include the latest SDK security fix. We also recommend that you consider advertising the SDK version utilized by your app, either on the app store or application “About” page or via other means for ease of tracking by users.
Using components with known vulnerabilities has become such a significant, widespread risk to users, it was added to the Open Web Application Security Project (OWASP) Top Ten list in 2013. Fortunately, the OWASP team built a tool for developer IDE’s called OWASP Dependency Check – you might want to check it out. Incorporating security tools like this is a great start and should be backed with security policies governing component use/management.
Last, but not least, we are working on adding a Developer section to the Trust site as we want to foster an environment for sharing secure development practices and updates. Feel free to send us suggestions for what you believe would be most valuable.
– The Security Standards & Architecture Team