App terminada: ¿la subo a producción o hago pruebas de seguridad?
Hace dos días me tocó ir a la ventanilla de Alsa para cerrar un billete de vuelta. Sí, a la ventanilla. Mis argumentos sobre que puedo comprar hamburguesas del mercado con Amazon Prime, la comida del mes en Carrefour, pantalones vaqueros con Vibbo, pedir «taxi» con Uber o «conocer amigas» con Tinder… todo desde mi móvil, no fueron suficientes para convencer a la simpática persona que me atendía de que no tenía sentido que no pudiera hacerlo por internet a estas alturas de siglo.
Hoy en día todas las empresas que quieren estar «a mano» de sus usuarios invierten en apps móviles o web (responsive). Es imprescindible que sean sencillas, rápidas y con un diseño fabuloso.
Seguro que alguno ya lo ve venir… ¿reconocéis lo que falta?
Seguridad. Cerca del 70% de las vulnerabilidades se encuentran en la capa de aplicación y apenas el 10% de los desarrolladores reconocen haber realizado pruebas de seguridad antes, durante y tras el lanzamiento de las apps [1].
Tampoco es para tanto…?
Quizás parezca que no, pero un error en una aplicación puede derivar en graves violaciones de seguridad. Lo que para un desarrollador puede ser un pequeño fallo, puede ser la entrada a la red interna de la organización y convertirse en el principio de una serie de escalados en horizontal y vertical que terminen con un magnífico acceso de administrador.
Una aplicación que no ha pasado las necesarias pruebas de seguridad puede terminar costando millones al negocio. Todavía me acuerdo de aquella charla de Antonio Ramos (www.leetsecurity.com) en la RootedCON titulada ¿Y si la seguridad afectara al valor contable de la empresa?. Que le pregunten a Yahoo si afecta a las cuentas o no un fallo de seguridad…
Si no te preocupas por la seguridad, quizás deberías preocuparte por la tesorería… ¿Qué tal unas recomendaciones mínimas?
Versiones cerradas, no metas parches de última hora
A veces, con las prisas, metemos características que no están del todo maduras. Tienen que estar aunque no estén demasiado finas, que «ya lo iremos arreglando». La realidad es que se suele dejar como está, ya que tras la release, una lista de nuevas features está en tu nuevo sprint y no tienes tiempo para arreglar cosas.
Si algo no está pulido, probado y validado, no debería ponerse en producción, a la larga lo agradecerás.
Pruebas de todo tipo (sí, de seguridad también)
Una batería de pruebas es esencial en el desarrollo, pero no hablo de las pruebas funcionales mínimas que realiza el desarrollador conforme escribe código. Haz todo tipo de pruebas, automatiza, audita tu código, incluso busca expertos en QA testing que te enseñen cómo hacerlo.
Nunca dejes de revisar
Las pruebas no deben terminar una vez se publica una versión. Si tienes algo en producción durante mucho tiempo, ponlo a prueba, «putéalo» para que seas tú el primero en encontrar una vulnerabilidad y no el primero en sufrirla.
No es tan complicado, no te olvides las pruebas y tus usuarios, tu negocio y tu tesorería te lo agradecerán.