Blog B-SECURE

Tercerización del desarrollo de software: quién tiene la responsabilidad de la seguridad

tercerizacion desarrollo de softwareEn la era digital, las aplicaciones hacen parte de las joyas de la corona. Esto lo saben muy bien las organizaciones, pero también los diferentes actores (criminales, hacktivistas, gobiernos, etc.) que buscan vulnerarlas para afectar sus operaciones, obtener información o simplemente cometer fraudes. Lo preocupante es que muchas de ellas cuentan con serios problemas de seguridad concebidos desde su diseño, que les facilita el trabajo a los atacantes.

Afortunadamente en los últimos años se ha empezado a cambiar el chip y se está pasando de una estrategia de protección basada en controles posteriores a la entrada en producción de una aplicación, por una donde se tiene en cuenta la seguridad como aspecto central en todo el ciclo de vida de desarrollo de software.

Tercerización y seguridad de las aplicaciones

El punto negativo que estamos viendo es que con la tercerización de los procesos de desarrollo muchas organizaciones están obviando los controles que deben hacer al interior de la organización para garantizar que cuentan con desarrollos seguros y no estén publicando sus aplicaciones sin saber si tienen múltiples vulnerabilidades que los dejan expuestos.

Aunque muchas de las obligaciones sobre la seguridad recaen en el proveedor, de alguna forma además de lo contractual, la organización debe garantizar que efectivamente sus aplicaciones no contengan vulnerabilidades en el código, que puedan poner en riesgo el negocio (operación, reputación, etc.) pues en últimas, el dueño de la aplicación es quien sufre las consecuencias de un ataque exitoso.

[VEA: Cómo se integra Veracode al ciclo de vida de desarrollo de software para hacer escaneos de vulnerabilidades]

La presentación de un informe de parte del proveedor no es suficiente para dar aceptación, pues es la empresa quien debe establecer cuáles son los niveles de seguridad o cumplimiento (PCI, OWASP, etc.) aceptables para sus desarrollos y quién garantiza que los productos entregados se reciben teniendo en cuenta los niveles mencionados.

Alternativas para recibir desarrollos seguros de terceros

Para asegurar que el software desarrollado por un proveedor cumple con los requerimientos de seguridad, las empresas deben empezar por incluir detalles específicos al respecto dentro de los contratos con los terceros. OWASP, una de las organizaciones independientes más conocida y respetada en términos de seguridad para aplicaciones tiene un anexo en donde explica los detalles que se deberían incluir en los contratos.  

Adicionalmente, las empresas tienen dos opciones para comprobar que efectivamente están recibiendo software que cuenta con los estándares de seguridad pactados. La primera de ellas consiste en implementar una plataforma para pruebas de seguridad de código. Allí, pueden establecer las políticas con las que se aceptarán los desarrollos y proveerle al tercero usuarios para que prueben tantas veces como requieran las aplicaciones hasta que estas efectivamente cumplan con los requerimientos de seguridad impuestos para ser aceptadas por la organización.

La segunda alternativa es que la empresa contrate un proveedor de seguridad para que realice pruebas por demanda cada vez que se entregue un desarrollo. El problema de esta opción es que hoy en día se entregan múltiples versiones en periodos cada vez más cortos y se tendrían que hacer tantas pruebas como entregas existan hasta que el proveedor cumpla las políticas de seguridad establecidas. Esto implicaría llevar a cabo una importante cantidad de pruebas que no es fácil de cuantificar y presupuestar con anticipación, pero que con toda seguridad terminarán siendo más costosas que la primera alternativa.

No importa cuál alternativa escoja, lo que debe tener en cuenta es que siempre será mucho más fácil y económico lidiar con los problemas de seguridad del software en etapas tempranas.Tampoco implica que pueda eliminar de sus planes otros controles como pruebas de ethical hacking o tecnologías como WAF, pues las amenazas evolucionan y lo que puede ser un software muy seguro hoy quizá no lo sea tanto mañana.

Topics: Desarrollo software