Está justo ahí en el nombre: DevSecOps , un acrónimo de Desarrollo, Seguridad y Operaciones , implica introducir la seguridad desde el principio , como parte de un ciclo de vida de desarrollo de software (SDLC) completo y ágil utilizado por su organización, en lugar de hacerlo de forma iterativa o esperando hasta después de un lanzamiento.
Dado que las brechas de seguridad y las vulnerabilidades se han convertido en noticias cotidianas, tiene poco sentido que los desarrolladores sigan ignorando la seriedad de la codificación segura. Sin embargo, aquí hay un pequeño secreto: los desarrolladores a menudo no son las personas más orientadas a la seguridad por razones obvias. No es su deber principal.
La prioridad para un desarrollador de software es crear una aplicación, hacer que lleve a cabo las tareas previstas correctamente y, tal vez, dar cuenta de la experiencia general del usuario (UX) y la satisfacción. Si son diligentes, pueden incorporar ‘verificaciones de seguridad’ básicas como parte de sus procesos de codificación, como no confiar ciegamente en la entrada del usuario y desinfectarla, pero más allá de eso, es posible que un desarrollador no solo tenga el ancho de banda adecuado o la experiencia para incorporar el controles de seguridad más superiores en una aplicación.
Un momento de honestidad: a pesar de trabajar en DevSecOps para Sonatype, no entendí por adelantado qué significaba la palabra de moda durante bastante tiempo. A menudo me preguntaba, “¿dónde radica el beneficio para las organizaciones en esto? ¿Es todo esto una moda de marketing?
Con el tiempo, he observado una tendencia y un impulso ascendente en la industria para implementar algún tipo de “seguridad” inherente como parte de su flujo de trabajo de desarrollo y aquí están los 5 beneficios que me vienen a la mente de inmediato.
1. Detecte vulnerabilidades y errores desde el principio
Si bien un desarrollador puede hacer su debida diligencia con respecto a la implementación de controles de seguridad de nivel básico, nadie puede saber en este vasto ecosistema de código abierto con millones de repositorios, como lo afirma GitHub , cuántos paquetes de software contienen una vulnerabilidad de seguridad y en cuál de ellos. sus versiones. Dado el gran volumen, es simplemente imposible estar al tanto sin tener algún tipo de automatización de seguridad en su lugar.
La base de datos nacional de vulnerabilidades (NVD), una iniciativa del NIST de EE. UU., que de ninguna manera es una lista exhaustiva o precisa, acaba de cruzar su vulnerabilidad número 100,000 , y cada día se agregan más vulnerabilidades. Esto no siempre incluye las “vulneraciones de seguridad” y los problemas que se publican en GitHub o ExploitDB.
Una solución o flujo de trabajo DevSecOps integrado que admita cierta automatización puede ayudar a los desarrolladores a detectar si están usando involuntariamente bibliotecas de código abierto con vulnerabilidades conocidas, incluso antes de que comiencen a codificar el resto de los módulos de un proyecto de software, solo para darse cuenta de que necesitan comenzar. encima.
2. Aproveche el código abierto con mayor confianza
Dado que la comunidad de código abierto tradicionalmente ha recibido contribuciones de ‘cualquiera’, esto también abre una puerta para el abuso por parte de actores malintencionados. Han salido a la luz múltiples informes de malware disfrazado de paquetes legítimos de código abierto. Si bien los representantes de npm pudieron detectar y “eliminar” estos componentes de sus servidores, el proceso no siempre ha sido rápido. Un desarrollador desprevenido que ya esté usando uno de los componentes comprometidos no tendría forma de saberlo, a menos que hubiera una herramienta automatizada para poder escanear constantemente su proyecto y señalar cualquier componente malicioso de código abierto. Aquí es donde las soluciones integradas en IDE pueden salvar a los desarrolladores y a toda una organización de los errores y la vergüenza que pueden surgir después de realizar un lanzamiento.
3. Ahorre costes en la gestión de recursos
Como ex desarrollador de software, puedo reflexionar con autoridad sobre cómo las “dependencias” plantean un problema durante el desarrollo de software y dan forma crítica al resto del flujo de trabajo. En términos sencillos, si su aplicación requiere una cierta biblioteca A que depende de otra biblioteca B, que además depende de otra biblioteca C, la versión 2, que es vulnerable, naturalmente significaría que no puede usar ninguna de esas tres bibliotecas. a menos que la biblioteca A y B admitieran una versión 3 no vulnerable de la biblioteca C… siempre que tal versión existiera.
Puedes ver cómo esto puede volverse tedioso. Imagínese tener que tomar esta decisión de aceptar un riesgo de seguridad potencial para 20 o más componentes para un proyecto de software de mediana a gran escala o explorar bibliotecas alternativas de código abierto.
Para los administradores y desarrolladores de proyectos, tener este conocimiento por adelantado y poder evaluar el riesgo desde el principio puede significar poder buscar mejores alternativas y diseñar software seguro desde el principio, en lugar de esperar hasta después de un lanzamiento, cuando una evaluación de vulnerabilidad puede ser necesaria. futuro, revelan una vulnerabilidad crítica. En la práctica, esto significa un enorme ahorro en horas de mano de obra y costos de administración de recursos.
4. Hacer que los desarrolladores sean conscientes de la seguridad
Sus desarrolladores están ocupados y tienen la tarea de implementar una determinada funcionalidad fuera del código para sus usuarios. Es posible que la seguridad no siempre sea su prioridad número uno debido a las limitaciones impuestas por el cumplimiento de los plazos e incluso la falta de experiencia en seguridad del propio desarrollador. Sin embargo, con las soluciones de software DevSecOps, los ‘recordatorios’ constantes sobre la exclusión de ciertos componentes de las compilaciones de software, junto con un razonamiento creíble que lo garantiza, hace que sus desarrolladores estén un poco más interesados y conscientes de la seguridad cada vez que ven una alerta de este tipo, por ejemplo. .
A la larga, esto puede reforzar habitualmente la mentalidad del desarrollador de evitar por completo un componente de código abierto que tiene la reputación de contener fallas de seguridad en múltiples versiones.
5. Reducir el riesgo y la responsabilidad legal
Las organizaciones a menudo afirman: “nos tomamos en serio su seguridad y privacidad”, pero no muchas viven de acuerdo con eso. Si lo hubieran hecho, el clima actual de frecuentes violaciones de la seguridad cibernética no existiría. De cualquier manera, cualquier noticia tan dañina afecta gravemente la reputación de la marca de una organización y puede dar lugar a posibles demandas y multas . Seguir las prácticas de seguridad en todos los aspectos de su proyecto de software, incluso cuando se trata de un sitio web simple, es más probable que reduzca el riesgo y el impacto que puede surgir de tener una actitud complaciente hacia la seguridad.
En conclusión, nunca hay forma de saber si su aplicación o proyecto es totalmente seguro desde todas las direcciones: después de todo, no podemos pretender predecir o descartar los riesgos desconocidos . Pero seguir las mejores prácticas y la automatización como se describe en el término elegante DevSecOps puede reducir enormemente el riesgo que surge del uso de componentes de software con vulnerabilidades conocidas , desde el principio.
Comentarios