Protección de aplicaciones móviles con un enfoque de ciclo de vida seguro para el desarrollo

En la era actual es común traer su propio dispositivo (BYOD), el teléfono inteligente es uno de los dispositivos móviles preferidos para acceder a la información de la empresa. El software es un componente clave en cualquier activo de tecnología de la información. Los dispositivos inteligentes están incorporados con software de aplicación o permiten a los usuarios instalar software en los dispositivos para agregar funciones que logren los objetivos previstos. Por lo tanto, las aplicaciones son vitales para los dispositivos móviles. Asegurar estas aplicaciones de las vulnerabilidades de seguridad y el riesgo es fundamental.¹

Este artículo se centra en las prácticas de desarrollo seguras en el desarrollo de aplicaciones móviles y sugiere algunas herramientas de seguridad de código abierto para realizar una evaluación de la seguridad de las aplicaciones para fortalecer las aplicaciones móviles.

Los problemas de seguridad de las aplicaciones web conducen a infracciones a las empresas

En los últimos años se han producido violaciones importantes de la seguridad de la información. Los investigadores de seguridad examinaron de cerca las razones subyacentes de algunas de estas infracciones y sus estudios revelan que la seguridad de una aplicación web es de suma importancia para el perímetro de la empresa y la seguridad a nivel de puerta de enlace.^{2, 3, 4, 5, 6, 7, 8}

Una aplicación web insegura puede comprometer los mejores arreglos de seguridad de la empresa y puede ayudar a los adversarios a robar datos y obtener un punto de apoyo en la red interna de la empresa.

Problemas de seguridad de aplicaciones móviles

Los problemas de seguridad no son diferentes en el caso de aplicaciones móviles, en las que la aplicación se descarga desde Internet (por ejemplo, Apple Store o Google Play Store) e instalada en el dispositivo del usuario. Al igual que las aplicaciones web expuestas en Internet, las aplicaciones móviles instaladas en dispositivos BYOD son puntos de entrada a la red empresarial.

Las aplicaciones móviles instaladas, si no están protegidas adecuadamente, pueden ser ingeniería inversa para obtener su código fuente, que está en forma legible por humanos. Plataformas como iOS y Android, las dos plataformas móviles más populares hoy en día, no son inmunes a la amenaza de la ingeniería inversa. Algunos pasos sencillos y herramientas ampliamente disponibles (a menudo gratuitas) hacen que sea fácil para un atacante:

• Extraer la aplicación instalada del dispositivo móvil
• Analizar o realizar ingeniería inversa del código para encontrar información vital, por ejemplo, lógica empresarial, interfaz de programación de aplicaciones (API) utilizada e URL internas incorporadas
• Modificar el código para cambiar el comportamiento de la aplicación
• Inyectar código malicioso

La ingeniería inversa de aplicaciones móviles es un problema de seguridad que las empresas deben tener en cuenta. La ofuscación del código es una técnica bien conocida que dificulta la ingeniería inversa de una aplicación móvil,⁹ pero esta técnica es a menudo ignorada por la comunidad de desarrollo. Las aplicaciones móviles presentan las siguientes debilidades de seguridad:¹⁰

• Falta de consideraciones de privacidad
• Falta de protección binaria
• Almacenamiento de datos inseguro
• Seguridad del transporte
• Controles del lado del servidor débiles

La investigación realizada por dos expertos en seguridad que representan a diferentes empresas de seguridad revela que las aplicaciones de banca móvil de los bancos más influyentes de todo el mundo tienen muchas vulnerabilidades de seguridad comunes.^{11, 12} Estos investigadores realizaron sus pruebas en la aplicación móvil (cliente) y excluyeron cualquier prueba del servidor (back end). El lado del cliente representa sólo una pequeña porción de la superficie de ataque de la banca móvil, porque la mayoría de procesamiento ocurre en el back-end. Los problemas de seguridad que los investigadores revelaron no son lógica de negocios o problemas específicos de la aplicación. Los problemas son debilidades en el desarrollo de aplicaciones, es decir, las tareas de seguridad que los desarrolladores deben realizar, pero no lo están haciendo.

Las aplicaciones móviles que fueron probadas durante la investigación estaban filtrando información a través de codificación insegura. Por ejemplo, estas aplicaciones eran vulnerables a:

• Ataque de Hombre en el Medio (MitM)
• Ataques de secuencias de comandos entre sitios (XSS)
• Fuga de información confidencial a través de los registros del sistema
• Credenciales codificadas en el código
• El uso de protocolo de capa de socket no seguro (SSL) (HTTP) para transmitir información confidencial entre el servidor remoto y el dispositivo de usuario

Las recomendaciones de los investigadores para mejorar la seguridad de las aplicaciones móviles incluyen:¹³

• Asegúrese de que todas las conexiones entre las aplicaciones móviles y los servidores back-end se realizan mediante SSL. La verificación del certificado SSL es reforzada por la aplicación cliente para protegerse contra la intercepción y MitM.
• Proteger los datos sensibles que se almacenan en el dispositivo (cliente) con cifrado.
• Utilizar trucos de obfuscación de código y antidepuración para disuadir a los atacantes de la ingeniería inversa del binario de la aplicación.
• Habilitar las protecciones proporcionadas por la plataforma operativa móvil, tales como:
  • Recuento automático de referencia (ARC)
  • Ejecutable independiente de la posición (PIE)
  • Protección de la pila en la plataforma iOS
  • Utilizar el kit de desarrollo de software más reciente (SDK)
  • Deshabilitar la función de depuración en el binario compilado
  • El endurecimiento de permisos para aplicaciones basadas en Android

Construyendo seguridad en el desarrollo

Realizar evaluaciones de seguridad de las aplicaciones e incorporar la seguridad en la aplicación justo antes de la publicación del software no es un enfoque ideal. La corrección de las vulnerabilidades de seguridad en las etapas posteriores del ciclo de vida de desarrollo de software (SDLC) requiere mucho tiempo y es muy costosa.

El ciclo de vida de desarrollo seguro tiene como objetivo incorporar la seguridad en todas las fases del desarrollo de software, desde la recolección de requisitos hasta la prueba, la liberación y el mantenimiento (figura 1).^{14, 15}

Las siguientes secciones tienen como objetivo proporcionar orientación al personal de desarrollo y seguridad de aplicaciones para incorporar actividades específicas de seguridad de la información en cada fase del SDLC.

Recolección de requisitos

La incorporación de seguridad en el desarrollo de aplicaciones comienza en la fase de recopilación de requisitos. Aparte de los requisitos funcionales del software, determine:

1. Requisitos de seguridad específicos del usuario esperados en la aplicación. Esto puede incluir confidencialidad, integridad, disponibilidad y autenticación.
2. Importancia de los datos manejados por la aplicación y requisitos de seguridad para proteger los datos
3. Cumplimiento y mandatos reglamentarios aplicables a los usuarios, la región donde se utilizará la aplicación y la información manejada por la aplicación
4. Uso y mal uso de los casos desde una perspectiva de seguridad
5. Matriz de trazabilidad de requerimientos para mapear requerimientos con riesgo de seguridad

Diseño

En la fase de diseño de la aplicación, los requisitos funcionales se convierten en arquitectura. Es importante incorporar controles de seguridad para la seguridad de las aplicaciones en la fase de diseño. La construcción de un diseño seguro minimiza la mayoría de los problemas de seguridad, ya que los problemas de nivel de código pueden identificarse con análisis estáticos o revisión manual del código. Además, las herramientas automatizadas no pueden identificar inconsistencias de diseño a menos que se realicen esfuerzos para realizar una revisión de modelo y arquitectura de amenazas.¹⁶ La estricta observancia de los principios de diseño seguro mejora en gran medida la seguridad.

Reconociendo la importancia del diseño en la seguridad de las aplicaciones, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) lanzó la iniciativa del Centro para el Diseño Seguro (CSD). CSD identificó las 10 principales fallas de diseño y las maneras de evitarlas.¹⁷ La recomendación de la CSD puede proporcionar valiosa guía para considerar en el diseño de una aplicación.

Realizar el modelado de amenazas y el análisis de riesgo de la arquitectura del diseño da una medida de lo probable es que el software será atacado y la extensión del daño que un ataque podría causar. Iniciar el análisis mediante la elaboración de una visión general de alto nivel del sistema propuesto; luego, analizar el diseño desde la perspectiva de un atacante, es decir, encontrar maneras de explotar la aplicación.

Codificación

Durante la fase de codificación, los requisitos de empresa/cliente/producto se convierten en una aplicación. La entrada para esta fase proviene de las fases anteriores en SDLC (recopilación de requisitos y diseño). Los desarrolladores convierten los documentos de diseño en software funcional. La escritura incorrecta de un código produce errores de software. Los errores de codificación pueden reducirse considerablemente cuando se aplican directrices de codificación segura en el desarrollo de aplicaciones.

Las directrices de codificación pueden ser cualquiera de las siguientes:

• Generic, que se aplican en todos los entornos de desarrollo independientemente de la plataforma elegida para construir una aplicación. El proyecto de seguridad móvil de la aplicación web abierta (OWASP)¹⁸ y las directrices para aplicaciones móviles seguras de la Agencia de la Unión Europea para la seguridad de las redes y la información (ENISA) son pautas genéricas.¹⁹
• Directrices de codificación específicas de la plataforma relacionadas con una plataforma de desarrollo, por ejemplo, Android²⁰ o iOS²¹

Uso de código de terceros
Otra consideración importante durante la codificación es el uso de marcos de desarrollo y bibliotecas de terceros, incluyendo componentes de fuente abierta. Hoy en día, muchas aplicaciones se forman a partir de múltiples conjuntos de bibliotecas, la mayoría de las cuales son de código abierto, permitiendo al desarrollador centrarse en la aplicación principal Funciona al tiempo que confía en código de terceros para proporcionar capacidades de soporte. Aunque esto es beneficioso para desarrollar la funcionalidad rápidamente, algunas infracciones de seguridad han ocurrido debido a las vulnerabilidades encontradas en las bibliotecas. Los ejemplos incluyen el defecto de OpenSSL que condujo a la vulnerabilidad de Heartbleed.²²

Se recomienda crear un inventario de opensource y bibliotecas de terceros que se utilizan en la aplicación que se está desarrollando y mantener el inventario como parte de los artefactos de desarrollo. Debido a que el código abierto proviene de múltiples partes y se introduce en el código de la aplicación por desarrolladores de socios internos y/o tercerizados, es esencial que el inventario rastree el componente de código abierto en el código y determine si estos componentes se ven afectados por vulnerabilidades conocidas. Una ventaja del inventario de código abierto es que cuando ocurre algún incidente de seguridad que involucre a estas bibliotecas, la remediación puede ser muy rápida, especialmente cuando la empresa tiene varias aplicaciones en su cartera. La falta de información sobre los componentes de código abierto que se utilizan en las aplicaciones puede dificultar la iniciación de actividades de remediación.²³

Otra ventaja del inventario de código abierto es el monitoreo proactivo de las vulnerabilidades en los componentes de código abierto al referirse a la hoja de inventario (figura 2) y tomar las medidas correctivas apropiadas cuando algo indeseable es inminente.La hemorragia conduce a una situación de crisis para aquellos que utilizan OpenSSL cryptolibraries en su Las aplicaciones móviles, y la actualización a la versión actual era un desafío.^{24, 25} En circunstancias como esta, tener una hoja de inventario es útil. El personal responsable del soporte y mantenimiento conoce los detalles de las aplicaciones y puede usar la hoja de inventario para encontrar dónde está el componente vulnerable y luego planificar la remediación.

También vale la pena examinar las bibliotecas de código abierto y de terceros. El objetivo de examinarlas es minimizar vulnerabilidades, por ejemplo, puertas traseras incrustadas en ellas u otros problemas de seguridad. La seguridad del código de código abierto de terceros se puede abordar de dos maneras: incrustando controles administrativos e incorporando controles técnicos a través del SDLC.

El primer enfoque consiste en controles administrativos, tales como políticas y procedimientos. Este enfoque puede incluir:

• Capacitación de concientización del desarrollador para educar cómo los desarrolladores heredan inadvertidamente el riesgo de seguridad de los componentes de código abierto a su aplicación cuando el código de terceros no está validado
• Auditoría de cualquier software de código abierto en uso, especialmente en aplicaciones de alta prioridad
• Creación y mantenimiento de una lista de códigos de código abierto aprobados/listados en blanco y uso restringido de software no aprobado. Sin embargo, la lista blanca puede no ser útil cuando el volumen de aplicaciones que libera una empresa es alto y cuando hay una mayor necesidad de utilizar código de terceros. En tales situaciones, la combinación de un enfoque de lista blanca con los controles técnicos puede ayudar a lograr un equilibrio fino.

El segundo enfoque consiste en controles técnicos y realizar análisis de código fuente y análisis de tiempo de ejecución en el código de terceros mediante herramientas automatizadas. Todos los códigos de terceros que se utilizan en la aplicación deben someterse a estos análisis para asegurarse de que el posible riesgo de seguridad se identifica y administra adecuadamente.

Herramientas gratuitas, como Androwarn,²⁶ LinkedIn Quick Android Kit de Revisión (QARK),²⁷ FindBugs²⁸ y Facebook Infer²⁹ pueden utilizarse para analizar el código.

Pruebas de seguridad de aplicaciones estáticas
Ejecutar análisis estáticos en el código fuente temprano en el ciclo de vida ayuda a corregir errores de nivel de código antes de que la aplicación se libera para uso general. El análisis estático encuentra la codificación incorrecta que puede potencialmente causar riesgo de seguridad. El análisis se realiza sin ejecutar realmente el programa. En este tipo de análisis se cubre todo el código fuente o binario. Se puede construir en el proceso de desarrollo y se realiza temprano en el ciclo de vida de desarrollo de software.

Los desarrolladores pueden estar facultados para realizar análisis estáticos de su código y corregir la codificación incorrecta con regularidad. La integración del análisis estático con servidores de integración continua, por ejemplo, Jenkins, minimiza la necesidad de intervención manual, reduce la dependencia del equipo de seguridad y soluciona errores que pueden convertirse en vulnerabilidades de seguridad antes de que se vuelvan inmanejables. Las herramientas de seguridad, como Androwarn, QARK, FindBugs e Infer, se pueden utilizar para este análisis también.

Entrenamiento para desarrolladores
Una organización de TI que se esfuerza por ofrecer aplicaciones seguras (incluido el móvil) debe comprometer a sus desarrolladores y capacitarlos en prácticas seguras de codificación. El enfoque debe incluir la entrega de una aplicación sin riesgos de seguridad aparte de las funcionalidades y características.

Por ejemplo, Damn Vulnerable iOS App (DVIA),³⁰ como su nombre indica, es una aplicación móvil vulnerable. El principal objetivo de la aplicación es enseñar a los desarrolladores y entusiastas de la seguridad acerca de las vulnerabilidades en las aplicaciones móviles iOS, basadas en los “Top 10 Mobile Risks”³¹ de OWASP. De forma similar, OWASP GoatDroid proporciona un entorno de capacitación para desarrolladores y probadores de Android.

Pruebas

En la fase de pruebas, es importante realizar pruebas de seguridad junto con pruebas de garantía de calidad (QA) para integrar continuamente la seguridad en el desarrollo. QA asegura la calidad de la aplicación para ofrecer la funcionalidad empresarial necesaria. Las pruebas de seguridad ofrecen la seguridad de que la aplicación procesa de forma segura la información comercial.

El análisis dinámico de seguridad de aplicaciones (DAST) o el análisis en tiempo de ejecución es apropiado en esta fase del SDLC. El análisis dinámico se realiza contra una instancia en ejecución de un programa. Esta prueba mide con mayor precisión cómo un usuario malintencionado puede atacar la aplicación.

Al igual que las pruebas de seguridad de aplicaciones web tradicionales, la evaluación de aplicaciones móviles requiere un entorno de pruebas para llevar a cabo la evaluación de manera efectiva. Sin embargo, el entorno de pruebas de seguridad para móviles varía porque la evaluación implica revisar varios componentes, incluyendo cómo se comporta la aplicación cuando se instala en el dispositivo móvil.

Configuración de un laboratorio de pruebas móviles
Un laboratorio de pruebas móvil requiere los siguientes elementos esenciales:

• Una conexión de red. Este entorno debe estar aislado de la red corporativa o de producción.La creación de un hotspot Wi-Fi mediante una tarjeta de datos 3G/4G es una opción. Es importante recordar que tanto el portátil de análisis como el dispositivo en el que está instalada la aplicación móvil deben conectarse a la misma red para algunas de las pruebas.
• Un ordenador portátil Mac o Windows cargado con software de seguridad opensource
• Un dispositivo jailbreak³² para las pruebas de seguridad de aplicaciones iOS (iPhone, iPod o iPad)
• Para dispositivos Android, un SDK de Android y un entorno de desarrollo integrado (IDE) de Eclipse para configurar un emulador³³

Casos mínimos de prueba de la seguridad base
Cuatro componentes principales del entorno de aplicación móvil deben ser cubiertos en el análisis dinámico:

• Dispositivo donde está instalada la aplicación móvil
• Solicitud
• Comunicación de red entre la aplicación y el servidor de la empresa
• Datos manejados en la aplicación

Al establecer la capacidad de pruebas de seguridad de aplicaciones móviles, es posible que no sea posible concentrarse en todo. El mejor enfoque es comenzar pequeño e iterar continuamente para madurar la capacidad, incorporando las lecciones aprendidas en el proceso a lo largo del camino. Los “Top 10 Mobile Risks” de OWASP pueden ser un buen punto de partida para la construcción de los casos de prueba de seguridad móvil. Los profesionales de seguridad que participan en la seguridad de las aplicaciones voluntariamente contribuyen a OWASP, que representa de manera justa los principales problemas de seguridad con las aplicaciones móviles.

“En la fase de pruebas, es importante realizar pruebas de seguridad junto con pruebas de control de calidad (QA) para integrar continuamente la seguridad en el desarrollo”.

De forma alternativa, los casos de prueba de seguridad de aplicaciones móviles pueden crearse basándose en los cinco problemas de seguridad destacados en el informe “Estudio de seguridad de aplicaciones móviles” de Hewlett-Packard.³⁴ Los problemas de seguridad identificados en el estudio son una versión abreviada del Top 10 de OWASP, debido a que los resultados de los estudios se correlacionan con las principales cuestiones de OWASP.

Los resultados previos de las evaluaciones de seguridad de las aplicaciones desarrolladas/utilizadas en la empresa son otros recursos valiosos a consultar cuando se construyen los casos de prueba. Los intentos de establecer una línea de base mínima de casos de prueba de seguridad pueden resultar en la identificación de objetivos de seguridad de alto nivel. Estos objetivos son únicos y relevantes para la seguridad de las aplicaciones móviles, como se muestra en la figura 3.

El siguiente paso es dividir los objetivos de seguridad en casos de prueba de seguridad. Mapear los casos de prueba de seguridad con herramientas de evaluación de seguridad es otra subactividad en este esfuerzo. Las herramientas de seguridad comercial para la evaluación de aplicaciones móviles pueden no cubrir todos los escenarios de prueba. La realización de pruebas manuales con algunas de las herramientas de código abierto libremente disponibles puede proporcionar una cobertura razonable para identificar el riesgo de seguridad.

Las Figuras 4 y 5 desglosan los objetivos de las pruebas de seguridad en casos de prueba y los asignan a herramientas de evaluación de seguridad para iOS y plataformas móviles Android.

Mantenimiento

La seguridad de las aplicaciones es una tarea continua; sigue siendo importante incluso cuando la aplicación se libera para uso público. El monitoreo proactivo de las vulnerabilidades de seguridad en el software del sistema de la plataforma y los componentes integrados, y luego iniciar la respuesta a incidentes y la remediación, según sea apropiado, son cruciales.

Identificar vulnerabilidades de seguridad utilizando fuentes acreditadas para obtener información de seguridad es un ciclo continuo. Fuentes como sitios web de proveedores de software, la National Vulnerability Database (NVD) del EEUU National Institute of Standards and Technology (NIST) y las vulnerabilidades y exposiciones comunes de MITRE Corporation (CVE) son fiables para la investigación de vulnerabilidad.

El inventario de todos los frameworks/API de terceros que se utilizan en la aplicación móvil es útil para gestionar parches de seguridad. Siempre que cualquier vulnerabilidad se convierta en conocimiento público, debe realizarse una actualización de seguridad correspondiente para las aplicaciones móviles que utilizan estas API/frameworks de terceros vulnerables.

Conclusión

Las aplicaciones móviles y web que tratan con información sensible, privada u otra en riesgo requieren un ciclo de vida de desarrollo seguro. Las aplicaciones sin consideraciones de seguridad pueden presentar una vulnerabilidad inesperada a la privacidad. Para tratar los problemas de seguridad de las aplicaciones, se anima a los desarrolladores a comprender el riesgo potencial de cada función de negocio, cambio de código y uso de marcos y API de terceros, mientras que los equipos de seguridad pueden ayudar a mejorar la seguridad de las aplicaciones a través del entrenamiento, compromiso proactivo con los desarrolladores. Incorporar la seguridad en todas las fases de SDLC en lugar de incorporar la seguridad justo antes de la liberación del software no sólo beneficia a la organización desde una perspectiva económica y de eficiencia, sino que también asegura que los servicios empresariales estén habilitados de forma segura.

Nota del Autor

Las opiniones expresadas en este artículo son del autor y de ninguna manera representan la postura de su empleador.

Notas Finales

¹ 2014 Research Into Internet Systems LLC, “Top 10 Mobile Security Risks,” Decompiling Android, 2014, www.decompilingandroid.com/mobile-app-security/top-10-mobile-security-risks/?_sm_au_=iHVjTnqfJSv0F6Nj
² Tung, L.; “Hackers Access 800,000 Orange Customers’ Data,” ZDNet, 3 February 2014, www.zdnet.com/article/hackers-access-800000-orange-customers-data/
³ TrustedSec, “CHS Hacked via Heartbleed Vulnerability,” TrustedSec Update, 19 August 2014, www.trustedsec.com/august-2014/chs-hacked-heartbleed-exclusive-trustedsec/
⁴ Mumsnet Limited, “The Heartbleed Security Breed—And What To Do,” mumsnet, www.mumsnet.com/info/the-heartbleed-security-breach-to-do
⁵ Paganini, P.; “Vulnerabilities in Alibaba Threatens Security of Million Users,” Security Affairs, 11 December 2014, http://securityaffairs.co/wordpress/31028/hacking/vulnerabilities-in-alibaba.html
⁶ Mai-Duc, C.; “Alibaba Security Flaws Exposed Data on Millions of Users, Analysts Say,” The Los Angeles Times, 10 December 2014, www.latimes.com/business/technology/la-fi-tn-alibaba-security-breach-20141210-story.html
⁷ Whittaker, Z.; “Kindle Security Vulnerability Can ‘Compromise’ Amazon Accounts,” ZDNet, 16 September 2014, www.zdnet.com/article/kindle-security-vulnerability-can-compromise-amazon-accounts/
⁸ Wallop, H.; “eBay Hacking: Online Gangs Are After You,” The Telegraph, 23 May 2014, www.telegraph.co.uk/technology/internet-security/10849689/eBay-hacking-online-gangs-are-after-you.html
⁹ Android Studio, “Shrink Your Code and Resources”
¹⁰ Hewlett-Packard Development Company L.P., Mobile Application Security Study, February 2014
¹¹ Sanchez, A.; “Personal Banking Apps Leak Info Through Phone,” IOActive, 8 January 2014
¹² Higgins, K. J.; ”Weak Security in Most Mobile Banking Apps,” InformationWeek DarkReading, 12 December 2013, www.darkreading.com/vulnerabilities---threats/weak-security-in-most-mobile-banking-apps/d/d-id/1141054
¹³ Op cit, Sanchez
¹⁴ Microsoft, “What Is the Security Development Lifecycle?,” Security Development Lifecycle, www.microsoft.com/en-us/sdl/
¹⁵ BSIMM, “What We Do,” www.bsimm.com/
¹⁶ Sareen, P.; “Updated: After Ola & ZopNow Tech Screw Up, This Time Foodpanda Becomes the Target of a New Hack for Getting Free Food!!,” Inc42, 10 April 2015, https://inc42.com/buzz/after-ola-zopnow-this-time-foodpanda-becomes-target-of-a-new-hack-for-getting-free-food/
¹⁷ IEEE Cybersecurity, “Avoiding the Top 10 Software Security Design Flaws,” 13 November 2015, http://cybersecurity.ieee.org/center-for-secure-design/avoiding-the-top-10-security-flaws.html
¹⁸ The Open Web Application Security Project, “OWASP Mobile Security Project,” 18 July 2016, www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Mobile_Security_Testing
¹⁹ Euopean Union Agency for Network and Information Security, “Smartphone Secure Development Guidelines,” 25 November 2011, www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-applications/smartphone-security-1/smartphone-secure-development-guidelines
²⁰ Android, “Security Tips”
²¹ Apple Inc., “Introduction to Secure Coding Guide,” Mac Developer Library, https://developer.apple.com/library/mac/documentation/Security/Conceptual/SecureCodingGuide/Introduction.html
²² For more information, see http://heartbleed.com/
²³ BlackDuck, “Future of Open Source Survey,” 2016, https://info.blackducksoftware.com/rs/872-OLS-526/images/FOOS_Infographic_Security.pdf
²⁴ Helppi, V.; “What Heartbleed Bug Means to App Developers? Testdroid Has You Covered,” bitbar.com, 10 April 2014, http://bitbar.com/what-heartbleed-bug-means-to-app-developers-testdroid-has-you-covered/
²⁵ Acharya, S.; “Heartbleed Bug: How to Protect Android Devices,” International Business Times, 12 April 2014, www.ibtimes.co.uk/heartbleed-bug-how-protect-android-devices-1444508
²⁶ GItHub, “Androwarn,” https://github.com/maaaaz/androwarn
²⁷ GItHub, “Qark,” https://github.com/linkedin/qark
²⁸ GItHub, “findbugs,” https://github.com/findbugs/findbugs
²⁹ GItHub, “Infer,” https://github.com/facebook/infer
³⁰ Damn Vulnerable iOS Application (DVIA), http://damnvulnerableiosapp.com/
³¹ Op cit, OWASP
³² Gianchandani, P.; “iOS Application Security Part 1—Setting Up a Mobile Pentesting Platform,” 16 June 2013, http://highaltitudehacks.com/2013/06/16/ios-application-security-part-1-setting-up-a-mobile-pentesting-platform//
³³ The Open Web Application Security Project, “SettingupMobileTestingLab,” 7 June 2013
³⁴ Op cit, Hewlett-Packard Development Company L.P.