Comentario: El código abierto nunca ha sido más common, lo que significa que es hora de descubrir cómo proteger eficazmente el código abierto que utiliza. Dos expertos opinan.
Imagen: Getty Illustrations or photos / iStockphoto
El mundo está hecho de software y más del 99% de cualquier computer software que utilice, de código abierto o propietario, incluye componentes de código abierto. Algunos de esos componentes vienen con un proveedor que los respalda, dispuesto a indemnizarlo en caso de que algo salga mal. Para otros componentes, es posible que pueda obtener una suscripción a través de una empresa como Tidelift para garantizar un mantenimiento constante.
Pero luego algo como el Mistake de Heartbleed abre un agujero en OpenSSL, y te quedas pensando, «¿Cómo pude haber evitado esto?» La respuesta corta pero esperanzadora es: no puedes. Realmente no. No completamente. Como destacó el cofundador de Chef and System Initiative, Adam Jacob en un reciente Entrevista Open Resource in Company, la verdadera pregunta es «¿con qué rapidez puede reaccionar ante la interrupción de su cadena de suministro?» no cómo prevenir tales interrupciones.
VER: Ataques de inyección SQL: una hoja de trucos para profesionales de negocios (PDF gratuito) (TechRepublic)
Seguridad de código abierto: siempre se trata de procesos
Históricamente, el código abierto ha generado menos defectos (o «errores») que el software propietario. Esto tiene un sentido intuitivo: los desarrolladores que mostrarán su código tienen más probabilidades de invertir el tiempo necesario para prepararlo para el consumo público. Para tomar menos atajos. Pulir.
Sin embargo, el verdadero secreto de la seguridad de código abierto no es un código libre de errores, lo cual es imposible. No, la seguridad de código abierto se obtiene mediante la divulgación. Como cualquiera puede ver el código, todos también pueden ver cualquier problema. O, incluso si no se detecta antes de que se infrinja una vulnerabilidad, la naturaleza abierta del código facilita la solución del problema. No es de extrañar, entonces, que la firma de investigación WhiteSource descubrió que el 85% de las vulnerabilidades de código abierto se divulgan y ya tienen una solución disponible cuando se divulgan.
Entonces, al determinar qué componentes de código abierto usar, dijo Jacob, concéntrese en el proceso para solucionar los problemas que inevitablemente surgen con su «cadena de suministro»:
La pregunta es, ¿qué tan rápido puede reaccionar ante la interrupción en su cadena de suministro? Porque de eso se trata realmente la gestión de las cadenas de suministro. Sí, hay una parte proactiva que (incluye) la investigación de si asumir una dependencia o no. Pero cuando algo sale mal en la cadena de suministro, se convierte en una cuestión de «¿Con qué rapidez podemos dar la vuelta a la solución? ¿Con qué rapidez podemos reparar lo que está roto y sacarlo al mundo?» Y ahí es donde realmente debes concentrarte. No es que no te concentres en la prevención. Por supuesto que sí. Pero no puede evitarlo porque la cadena de suministro es muy grande y usted no. Y esa es la naturaleza del universo.
Preste atención a las contribuciones anteriores a los proyectos de código abierto
Si usted es un proveedor que vende servicios o asistencia en torno a estos componentes de código abierto, continuó Jacob, en última instancia, lo que está prometiendo es «que soy yo quien reaccionará y reaccionaré más rápido que usted (el cliente ) para conseguir una solución en sus manos «.
Por eso (en la misma entrevista) Scott McCarty, gerente de producto de Red Hat, destacó la importancia de las contribuciones iniciales a los proyectos de código abierto. (Un «contribución aguas arriba«simplemente significa las contribuciones de regreso a la fuente principal del código). Las contribuciones upstream no son algo de lo que presumir, dijo McCarty. No, son simplemente una forma» de expresarle al cliente que usted tiene suficiente participación en el suministro cadena «para poder cuidarlos cuando invariablemente surgen problemas.
VER: Por qué las mejores empresas de código abierto dan la bienvenida a la competencia upstream (TechRepublic)
Esto no es «apoyo» en sí mismo, aunque a veces puede sentirse así. Más bien, el producto es la capacidad de influir en un proyecto de código abierto de manera que se entreguen las correcciones rápidamente, lo que es más fácil si el proveedor tiene contribuyentes iniciales. Estas contribuciones son intrínsecamente egoístas, señaló McCarty, pero no de alguna manera «mala». No, es ese interés propio lo que motiva más contribuciones, lo que ayuda al proveedor a cuidar mejor a los clientes, quienes pagan el favor con ingresos, lo que genera más contribuciones. Es un ciclo virtuoso de seguridad de código abierto.
Divulgación: trabajo para AWS, pero las opiniones expresadas en este documento son mías.
