Vivimos en una economía de aplicaciones donde la innovación es la clave, la velocidad es crítica y el código abierto es el centro de atención. Todos, desde el CEO hasta el momento, están desafiando a los equipos de desarrollo de software a lanzar más rápido, mejorar la calidad y acelerar la innovación.
La velocidad, sin embargo, tiene sus límites. Sin control, mucho está en juego. Si bien las organizaciones de TI continúan avanzando, también necesitan controles para minimizar los riesgos, mejorar la seguridad y garantizar el cumplimiento.
Enfrentados a los requisitos de velocidad y control están los que manejan la fábrica de software moderna. Estos son los arquitectos de software, los desarrolladores, los profesionales de la seguridad y los gerentes de operaciones de TI. Para ellos, la intensa presión para innovar más rápido no proporciona una excusa para cortar esquinas. Las compensaciones no son una opción. Deben profundizar, desmantelar los silos organizativos y culturales e identificar nuevas formas de incorporar controles que funcionen a la velocidad del desarrollo.
En este mundo hipercompetitivo, los componentes de código abierto son el estimulante elegido por los desarrolladores de software. En pocas palabras, invertir tiempo y dinero para construir software desde cero es simplemente una tontería cuando los desarrolladores pueden pedirlo prestado a otra persona que ya haya hecho el trabajo y haya aceptado compartirlo de forma gratuita. De hecho, los componentes de código abierto son tan ampliamente utilizados que, según nuestra investigación, aproximadamente el 85% de una aplicación de software está formada por componentes de código abierto.
Si bien el código abierto proporciona velocidad, eficiencia y tremenda energía para los equipos de desarrollo modernos, también crea un desafío único y difícil
Si bien el código abierto proporciona velocidad, eficiencia y tremenda energía para los equipos de desarrollo modernos, también crea un desafío único y difícil para los administradores de riesgos de TI modernos y los profesionales de la gobernanza. De la misma investigación mencionada anteriormente, sabemos que aproximadamente 1 de cada 8 componentes tienen vulnerabilidades de seguridad conocidas y los desarrolladores a menudo los obtienen de manera electiva sin tomarse el tiempo para investigar manualmente qué riesgos podrían estar presentes. ¿Por qué? Una organización de desarrollo promedio puede descargar más de 200,000 componentes anualmente para acelerar las prácticas de desarrollo, y cuando se requieren de 3 a 4 horas de investigación manual para cada componente, las revisiones no pueden seguir el ritmo del consumo si se deben cumplir los plazos de publicación.
Los componentes de software de código abierto pueden manipularse en función de las vulnerabilidades de seguridad conocidas, y de las vulnerabilidades plantadas cada vez más, para obtener acceso ilegal a las aplicaciones y sus datos. La explotación de un componente vulnerable conocido en una aplicación web es lo que provocó la brecha de Equifax, pero también los ataques a la Agencia Canadiense de Ingresos, Okinawa Power, el Correo de Japón, el Correo de la India, AADHAAR, Apple, la Universidad de Delaware y la pasarela de pago de OGM .
Hoy en día, los adversarios tienen un núcleo común de motivación: quieren «poseer» (controlar y manipular) todo. Cuanto mayor sea el objetivo, y cuanto más disruptivas sean las consecuencias, mejor. La mayoría de las compañías subestiman su superficie de ataque, poniendo en riesgo las cadenas de suministro de software de misión crítica. Sin exagerar esto puede significar la vida o la muerte. ¿Quién, por ejemplo, tiene acceso a redes de transporte, dispositivos de salud, sistemas de defensa y producción de energía?
La mayoría de las empresas no están preparadas para los incidentes de ciberseguridad derivados de ataques de fuente abierta o de suministro de software, ya que operan con modelos de seguridad obsoletos. Una vez fue suficiente para proteger su negocio con un firewall de red y dispositivos protegidos por contraseña. Hoy en día todo está basado en la nube, impulsado por software y poroso. La seguridad debe ser incorporada desde el principio. Aquellos que operan sin el mantra «seguro por diseño» están aumentando su exposición a los adversarios.
En Sonatype, a menudo se nos pregunta por dónde empezar cuando se trata de la gobernanza de código abierto. Si bien creemos que la automatización es el único camino para el éxito continuo, primero debe comprender dónde residen los componentes de código abierto. Si no tiene ese conocimiento básico, no puede comenzar a comprender dónde existen componentes vulnerables que podrían necesitar una actualización hoy o en el futuro.
Entonces, comience por producir una Lista de materiales de software, a menudo denominada SBOM. En cuestión de segundos, las herramientas gratuitas (incluida una de Sonatype) pueden producir un SBOM y decirle qué componentes de software de código abierto están utilizando sus equipos de desarrollo. El SBOM también puede describir cuáles de esos componentes tienen vulnerabilidades de seguridad conocidas o riesgos de licencia.
Si desea ver lo que está dentro de su aplicación, utilice nuestro servicio gratuito: Nexus Vulnerability Scanner. Saber qué hay en sus aplicaciones es el primer paso para comprender mejor las cadenas de suministro de su software y para que pueda encaminarse hacia el gobierno completo de código abierto.
