Para cada empresa en cada industria, es probable que la competencia provenga de una empresa desconocida como de los rivales establecidos hace mucho tiempo. En la economía moderna, si no estás innovando lo suficientemente rápido, te atropellará alguien que lo haga. Solo pregunte a las compañías de televisión por cable y televisión acerca de Netflix. Pregunte a Hilton y Marriott sobre Airbnb. El miedo a la muerte puede ser un poderoso motivador..

Algunos de los mayores desafíos para los incumbentes son los equipos de liderazgo que se apoyan en sus laureles, normas culturales profundamente arraigadas y silos de larga data creados por los equipos de desarrollo de software, seguridad de aplicaciones y operaciones de TI. Las normas culturales y los silos arraigados reducen la velocidad de fricción y disminuyen la innovación..

Esta cruda realidad, y el miedo a la muerte, es la razón por la que muchas organizaciones ya no ven el desarrollo de software como un costo de hacer negocios, sino como una competencia central y un imperativo estratégico que define a toda la empresa. Todas las empresas son ahora empresas de software. También es la razón por la que las organizaciones de todo el mundo están adoptando cada vez más un concepto llamado DevOps, donde los muros entre las operaciones de TI y los desarrolladores se derrumban, las prácticas inútiles y la colaboración a escala se ven recompensadas. Las empresas más rápidas aportan valor al mercado, cuanto más las recompensa el mercado.

La magia del código abierto.

Ingrese a las prácticas de desarrollo de código abierto: la droga milagrosa elegida para impulsar DevOps y la innovación de software moderna.

Los componentes de código abierto, o las partes de software desarrolladas por la comunidad y reutilizables, permiten a las empresas ahorrar tiempo y dinero, mejorar la calidad, ofrecer agilidad comercial y mitigar (algunos) el riesgo empresarial. El concepto no es nuevo. Mucho antes de la llegada del código abierto, Isaac Newton dijo famoso: "Veo más lejos al pararme sobre los hombros de gigantes y descubro la verdad al basarme en descubrimientos anteriores". Esta idea es la razón principal por la que los componentes de código abierto son tan atractivos para los equipos de desarrollo. Lo mismo es válido para el uso creciente de aplicaciones en contenedores. En pocas palabras, el acceso libre y abierto a los componentes y contenedores de software preexistentes elimina la reinvención de las ruedas y expone el software a una comunidad global de “co-desarrolladores,” para idear y expandir.

Con tantos beneficios, no es de extrañar que el 80 - 90 por ciento de una aplicación moderna esté compuesta de componentes de código abierto. Y también por qué el 80 - 90 por ciento de la infraestructura moderna está siendo contenedorizado.

Usted podría preguntarse: ¿cuál es el problema? Bueno, si bien estas partes desempeñan un papel vital para impulsar la innovación y potenciar el mundo como lo conocemos, no todas las partes son iguales. Nuestro análisis de los componentes de código abierto descargados desde el Repositorio Central (la base de datos más grande y activa de componentes de código abierto de Java) encontró que en 2017, 1 de 8 componentes descargados por desarrolladores del Reino Unido contenía una conocido vulnerabilidad de seguridad.

Estas verdades no son desconocidas en el mercado. Heartbleed fue una notoria vulnerabilidad de código abierto. Equifax fue violado a través de un componente de código abierto vulnerable. Y de acuerdo con la Encuesta de la Comunidad DevSecOps de 2018 de más de 2,000 profesionales de TI, 3 de cada 10 sospechan o confirman una violación de fuente abierta relacionada con 2017.

De acuerdo con la misma encuesta, solo 6 de cada 10 organizaciones tienen políticas que requieren la evaluación de componentes de código abierto en alguna etapa del ciclo de vida del desarrollo. Pero, debido a que gran parte de ese requerimiento se basa en tediosas revisiones manuales fuera de las líneas de desarrollo, la realidad es que las políticas a menudo se ignoran (46% del tiempo) y los defectos continúan avanzando hacia las aplicaciones terminadas. El código abierto y los DevOps le dan a las compañías el poder de mantenerse con vida, y en muchos casos prosperan más que sus competidores, pero esa innovación no debería, y no tiene que ser, en detrimento de sus clientes.

El papel de la regulación.

La Estrategia Nacional de Seguridad Cibernética del Reino Unido 2016-2021 declaró que “Las empresas y organizaciones deciden dónde y cómo invertir en seguridad cibernética basándose en una evaluación de costo-beneficio, pero en última instancia son responsables de la seguridad de sus datos y sistemas..” Esa noción de responsabilidad se está aplicando cada vez más no solo en el Reino Unido sino en todo el mundo, a medida que los gobiernos establecen regulaciones..

Por ejemplo, tanto los legisladores franceses como el gobierno del Reino Unido anunciaron recientemente directrices más estrictas para los fabricantes de dispositivos. El Reino Unido exigió específicamente que la seguridad se incorpore a los dispositivos inteligentes desde el principio y que el software se actualice automáticamente..

La UE ha aprobado uno de los reglamentos más ampliamente discutidos con el próximo Reglamento General de Protección de Datos (GDPR). El artículo 32 de la GDPR establece que las empresas deben “Implementar las medidas técnicas y organizativas adecuadas.” a “garantizar la confidencialidad, integridad, disponibilidad y resistencia continuas de los sistemas y servicios de procesamiento.” Cuando se combina con el artículo 25, que exige que las medidas de protección de datos se implementen “por diseño y por defecto”, está claro que la privacidad y la seguridad deben integrarse en cada elemento de la infraestructura de TI. Si no cumple con estas reglas y las vulnerabilidades conocidas terminan ayudando inadvertidamente a los piratas informáticos para robar datos confidenciales de los consumidores, podría recibir una multa de hasta € 20 millones, o el 4% de la facturación anual global, la mayor de las dos..

Haciendo eco de las políticas europeas, cuatro senadores de EE. UU. Introdujeron una legislación bipartidista denominada Ley de Mejora de la Seguridad Cibernética de Internet de las Cosas. Según una ficha informativa publicada junto a la legislación., “Si bien los dispositivos 'Internet of Things' (IoT) y los datos que transmiten presentan enormes beneficios para los consumidores, la relativa inseguridad de muchos dispositivos presenta enormes desafíos..” La legislación exige específicamente a los proveedores que venden dispositivos de IoT. “para proporcionar una certificación por escrito de que el dispositivo no contiene, al momento de enviar la propuesta, ningún componente de hardware, software o firmware con vulnerabilidades de seguridad o defectos conocidos.”

Con un gran poder viene una gran responsabilidad

Esta línea de regulación dirigida a la protección del consumidor no es nueva. Hace cinco años, ningún fabricante de automóviles podía enviar bolsas de aire Takata defectuosas conocidas en un vehículo. Los reguladores introdujeron pautas de alimentación del ganado para limitar la propagación de la enfermedad de las vacas locas hace más de 20 años.

Pasar la responsabilidad a los fabricantes de dispositivos y organizaciones que desarrollan software para garantizar que sea seguro desde el principio y en el tiempo, refleja regulaciones similares que guían la seguridad del consumidor en otras industrias. Es especialmente importante cuando el software ahora controla nuestra salud (por ejemplo, marcapasos conectados a internet), nuestro transporte (por ejemplo, vehículos autónomos) y nuestras finanzas (por ejemplo, aplicaciones de banca en línea).

Hoy en día, los ataques e infracciones de las aplicaciones suelen ser el resultado de vulnerabilidades de fácil explotación y rectificación. Si bien nos gusta pensar que las empresas autorregularían su seguridad de ciberseguridad en nuestro mundo impulsado por el software, los titulares diarios de incumplimiento indican que las regulaciones gubernamentales pueden ser un motivador necesario para la acción..

Si a ninguna otra industria de fabricación se le permite enviar piezas conocidas vulnerables o defectuosas en sus productos, ¿por qué los fabricantes de software deberían ser diferentes? En cualquier otra industria se consideraría negligencia grave..

Nunca pase defectos conocidos aguas abajo

Afortunadamente, muchos de los desafíos relacionados con el uso de componentes de software vulnerables conocidos se resuelven fácilmente. Tanto las empresas grandes como las pequeñas están poniendo en práctica los principios y prácticas de DevSecOps. Uno de los principios más importantes se origina en el líder de DevSecOps, Gene Kim y su novela, el Proyecto Phoenix, que dirige, “Enfatice el rendimiento de todo el sistema y nunca pase un defecto hacia abajo”.

Para las empresas que decidan seguir esto, la automatización es imperativa. El enorme volumen de artefactos consumidos por las organizaciones hoy en día superaría cualquier intento de revisarlos manualmente para determinar su estado de salud. Las máquinas pueden realizar verificaciones en milisegundos, donde los humanos pueden tardar horas en llegar a conclusiones similares. Esta realidad es similar a la necesidad de un análisis robótico de las piezas que se ensamblan en una línea de manufactura electrónica de alta velocidad: los exámenes humanos nunca podrían seguir el ritmo y son propensos a errores.

La pregunta no es, ¿podemos desarrollar software seguro? Ciertamente podemos. La economía de la aplicación puede crecer y prosperar en entornos regulados y seguros, si se administra adecuadamente. Por otro lado, si las empresas deciden ignorar la higiene adecuada de la seguridad cibernética, pensando que están optando por la innovación, puede ser más que solo su muerte de la que serán responsables..

Derek Weeks, Vicepresidente en Sonatype

  • También hemos destacado las mejores suites de seguridad de internet.