Históricamente, la seguridad se ha tratado como algo secundario en la industria de TI. En años más recientes, sin embargo, ha habido presión para introducir’seguridad por diseño’para garantizar que los productos se desarrollen teniendo en cuenta las mejores prácticas.
Hablamos con David Melamed, CTO de Jit para obtener información sobre cómo integrar la seguridad y cómo los desarrolladores, no solo los profesionales de la seguridad, pueden utilizar las herramientas de seguridad.
BN: ¿Cómo se involucró en el espacio de seguridad de desarrollo?
DM: Como ingeniero de software (desde hace mucho tiempo), entendí que la seguridad es una pieza fundamental para entregar software de alta calidad. A lo largo de los años, invertí más tiempo y esfuerzo en estudiar el dominio y tuve la oportunidad específica de ponerme manos a la obra con la seguridad en la nube en CloudLock (posteriormente adquirida por Cisco). En la oficina de CTO, realicé una investigación profunda sobre las amenazas de seguridad en la nube del mundo real, e incluso fui uno de los investigadores que contribuyó a las 10 principales amenazas de seguridad sin servidor (antes de que Serverless despegara como lo ha hecho ahora). Hoy, en Jit, he aportado esa experiencia en el dominio de muchos años como desarrollador práctico, arquitecto e investigador de seguridad para cubrir todo el alcance de la seguridad de extremo a extremo a través de un marco abierto y accesible para todos.
BN: ¿Cuáles son los principales desafíos con la implementación de herramientas de seguridad?
DM: En pocas palabras, hay muchos.
La pura la diversidad y la cantidad de herramientas de seguridad hacen que este sea un panorama realmente difícil de navegar. No solo hay diferentes categorías, desde detección hasta prevención, escaneo de código, detección de vulnerabilidades en tiempo de ejecución, sino que también pueden venir en muchas formas, desde ejecutables y scripts, hasta herramientas basadas en API, SaaS y paquetes de código abierto. Sin embargo, el desafío más grande y más comúnmente mencionado es que cada una de estas herramientas es un mundo de experiencia en el dominio en sí mismo, y viene con su propio”lenguaje”, método de implementación, interfaz y salida. Todo esto en conjunto crea una curva de aprendizaje empinada para lograr una cobertura de seguridad de extremo a extremo para las muchas capas de las pilas nativas de la nube de hoy en día, así como un largo’tiempo para la cobertura de seguridad total’.
Aunque la pieza de seguridad más crítica en tal panorama es tener un plan predefinido, esencialmente una estrella polar para la seguridad de su producto. Esto se debe a que incluso si integra todas las herramientas adecuadas, pero su objetivo de seguridad no está bien definido, nunca sabrá si está administrando correctamente su postura de seguridad y si existen brechas significativas en la seguridad de su producto.
BN: ¿Cómo deben los equipos integrar la seguridad en el proceso de desarrollo?
DM: La integración de la seguridad en el desarrollo debe comenzar desde la primera línea de código y tan pronto como una práctica y una cultura, incluso antes en las fases de diseño y modelado de amenazas. Hay tantas capas de las que se componen nuestros productos hoy en día, desde el código hasta las integraciones y los terceros (a menudo llamados la cadena de suministro), la infraestructura, con una diversidad de tiempos de ejecución y mucho más. Todo esto en conjunto ha creado muchos puntos de entrada para posibles atacantes, y ninguno de estos puede pasarse por alto.
Dicho esto, creemos que los equipos pueden comenzar poco a poco e iterar con un enfoque de seguridad mínimo viable: Al igual que un MVP, no necesita construir una fortaleza desde el primer día, solo un plan de referencia que le proporcionará el conjunto mínimo de controles para cubrir las principales vulnerabilidades en todas estas categorías. Hay muchas herramientas de código abierto realmente geniales para comenzar, tenemos un resumen bastante bueno en nuestro blog del Las 5 mejores herramientas de seguridad de código abierto que todos los desarrolladores deberían conocer (y un gran charla!)
BN: ¿Puede explicar el papel de los proyectos de código abierto en el espacio de la ciberseguridad?
DM: La seguridad de código abierto ha evolucionado increíblemente a lo largo de los años, y hoy en día hay una cantidad sustancial de herramientas de seguridad de código abierto bastante impresionantes, que han cambiado las reglas del juego para la industria. De OWASP ZAP (el escáner de aplicaciones web más adoptado, mantenido por nuestro distinguido ingeniero, Simon Bennetts), a Gitleaks que Jit ha elegido para apoyar y patrocinar, entre muchos otros de KICS, a Prowler, Semgrep y más.
Estos proyectos han reducido la barrera de entrada para la seguridad, donde hasta la fecha gran parte del panorama de la seguridad se ha cerrado y las suites premium de software no siempre son accesibles para las empresas más pequeñas y en crecimiento. Muchas herramientas de seguridad de OSS son las mejores de su clase hoy en día y brindan una muy buena cobertura para las necesidades comunes, y han servido para proporcionar una innovación muy necesaria, así como también para comprender cómo debería ser la experiencia de seguridad (similar a la experiencia del desarrollador o del usuario) para habilitar verdaderamente la implementación generalizada. adopción.
BN: ¿Cuál es su opinión sobre el futuro de la seguridad para las empresas con equipos de desarrollo acelerados?
DM: Empresas que no Los conocimientos sobre cómo integrar la seguridad en los flujos de trabajo de los desarrolladores nativos en las organizaciones de ingeniería de alta velocidad quedarán atrás. No hay tiempo para fricciones o curvas de aprendizaje, las herramientas de seguridad deben optimizarse para los desarrolladores. Deben proporcionar resultados claros, y no solo ser informativos, con un enfoque en ser procesable con remediación integrada. Creemos que las herramientas de seguridad que cambiarán las reglas del juego son aquellas que vienen con una mentalidad de arreglar primero y no solo están impulsadas por problemas (los desarrolladores están hartos de largas listas de vulnerabilidades y saben cómo solucionarlas).
Lo que es más, la otra mitad es que eventualmente, con el panorama de amenazas en constante crecimiento y evolución, veremos que las herramientas de seguridad (de desarrollo) que hacen esto bien, eventualmente serán el habilitador (sí, escuchaste correctamente, el habilitador) de ingeniería de alta velocidad con seguridad. Hay mucho en juego hoy en día, y las empresas están a una solicitud de extracción e incumplimiento de un gran desastre. Las organizaciones de ingeniería que podrán entregar rápido, mientras mantienen la seguridad continua, serán las que tomen la iniciativa.
Crédito de la imagen: mikkolem/depositphotos.com