Los equipos de seguridad han tenido el desafío de seguir el ritmo del desarrollo de software. Y siguen enfrentando obstáculos, como líderes que erróneamente pasaron por alto la importancia de la seguridad en el proceso de desarrollo y la desproporción entre desarrolladores y personal de seguridad. Ahora llegó la IA, que acelera aún más ese ritmo. La velocidad de desarrollo solo aumentará a medida que las empresas se expandan a niveles empresariales. Por lo tanto, las herramientas de seguridad que se utilizan para gobernar los procesos de desarrollo deben coincidir con ese crecimiento.
Los equipos de seguridad de las aplicaciones deben gestionar y priorizar las vulnerabilidades de manera efectiva. Gracias a las políticas de seguridad de GitLab, junto con nuestro conjunto de herramientas de seguridad, las organizaciones pueden fomentar la colaboración entre los equipos de AppSec y desarrollo, lo que permite detectar, clasificar y corregir vulnerabilidades de forma eficiente. Las políticas de seguridad también proporcionan un mecanismo para automatizar el cumplimiento de la seguridad y gestionarlo a escala empresarial.
Si bien el análisis de más fuentes potenciales de vulnerabilidades ofrece mayores oportunidades para la detección temprana y la resolución de problemas, el gran volumen de hallazgos puede abrumar a los equipos de AppSec. La identificación de lo que es útil se está convirtiendo en un desafío cada vez mayor a medida que obtenemos información colectiva sobre las vulnerabilidades a partir de análisis adicionales.
Procesos para la clasificación de gestión de vulnerabilidades
Hoy en día, existen algunos enfoques comunes para manejar la clasificación de vulnerabilidades:
-
Sistema de puntuación de vulnerabilidades comunes: el CVSS proporciona un método estandarizado para evaluar la gravedad de las vulnerabilidades. Mediante las puntuaciones de CVSS, las organizaciones pueden priorizar las vulnerabilidades en función de su impacto potencial y asignar los recursos según sea necesario.
-
Puntuación basada en riesgos: la puntuación basada en el riesgo permite a las organizaciones evaluar las vulnerabilidades en función de su probabilidad de explotación y posible impacto comercial. Al considerar los factores contextuales, como el valor de los activos, las capacidades de los actores de amenazas y la prevalencia de exploits, las organizaciones pueden priorizar las vulnerabilidades de manera efectiva.
-
Modelado de amenazas: el modelado de amenazas es un enfoque con el que se identifican y evalúan las amenazas potenciales de una aplicación o un sistema. Mediante un análisis exhaustivo de la arquitectura del sistema, el flujo de datos y los posibles vectores de ataque, las organizaciones pueden priorizar las vulnerabilidades en función de su relevancia para las posibles amenazas. Este enfoque ayuda a asignar los recursos de manera efectiva al centrarse en las vulnerabilidades que tienen más probabilidades de ser explotadas.
-
Análisis de impacto comercial (BIA): el BIA es una técnica utilizada para evaluar el impacto potencial de las vulnerabilidades en las operaciones y los objetivos comerciales. Implica identificar los activos críticos, evaluar su importancia para la organización y cuantificar las posibles consecuencias de un ataque exitoso. Al tener en cuenta el posible impacto financiero, de reputación y operativo, las organizaciones pueden priorizar las vulnerabilidades que representan el riesgo más significativo para sus funciones comerciales principales.
A medida que aumenta la proliferación de código generado por IA, también lo hace la cantidad de vulnerabilidades no intencionales que se introducen. Este tipo de técnicas se vuelven fundamentales a la hora de ayudar a las empresas a clasificar y comprender cómo priorizar. Pero ¿cómo podemos aplicar estas estructuras conceptuales en el mundo real? Analicemos cómo podemos poner en práctica estas técnicas.
Gestión de políticas de seguridad
Las políticas de seguridad son la solución para transformar las políticas y los requisitos de cumplimiento a nivel empresarial en instrucciones operativas tangibles que se incorporan a sus prácticas de DevSecOps y al ciclo de vida de desarrollo del software. Mediante la creación de reglas en las políticas de seguridad de GitLab, las organizaciones pueden definir criterios detallados para la evaluación de vulnerabilidades, lo que garantiza que solo los hallazgos procesables se marquen para su revisión.
Las políticas de seguridad le permiten aplicar sus requisitos de seguridad y cumplimiento, así como sus mejores prácticas, integrándolos directamente en el código. Las políticas de ejecución de análisis garantizan que los análisis se ejecuten en proyectos específicos en función de sus necesidades y requisitos. De este modo, las vulnerabilidades y exposiciones se detectan antes de que el código se fusione en producción.
También puede aprovechar las políticas de aprobación de solicitudes de fusión para crear flujos de trabajo personalizados para abordar las vulnerabilidades. Las políticas evalúan los resultados de los análisis de seguridad y cumplimiento para evitar o bloquear las solicitudes de fusión a menos que se hayan revisado y aprobado exhaustivamente en función de las reglas que usted haya definido.
Al adoptar políticas de aprobación de solicitudes de fusión y políticas de ejecución de análisis, agrega una capa de control al proceso de desarrollo. Esto puede garantizar que el código, escrito por humanos o no, se analice automáticamente y que las violaciones de las políticas fomenten la colaboración entre los equipos de ingeniería y AppSec cuando sea más factible.
Definición de reglas granulares en las políticas de aprobación de solicitudes de fusión
Para ir un paso más allá, puede definir reglas granulares dentro de las políticas de aprobación de solicitudes de fusión en función de los filtros y atributos que se comparten a continuación. Estas reglas pueden ayudarle a identificar las vulnerabilidades más procesables y a encontrar información útil en medio del caos:
-
Estado de la vulnerabilidad: se pueden aplicar políticas de seguridad en función del estado de una vulnerabilidad, por lo general centrándose en las vulnerabilidades recién detectadas que necesitan clasificación. También es posible crear reglas en función de vulnerabilidades detectadas previamente con una gravedad determinada, o incluir/excluir vulnerabilidades si se han descartado.
-
Rama: aplique la normativa solo en ramas específicas, por ejemplo, enfocándose en hacer cumplir las normas en la rama predeterminada de proyectos críticos o en cualquier rama protegida.
-
Corrección disponible: filtre los hallazgos de los resultados de análisis de dependencias y contenedores cuando no se dispone de una solución. A menudo dependen de cambios introducidos por terceros y, por lo tanto, no pueden corregirse de inmediato. Puede crear y supervisar tickets de vulnerabilidades con fecha de vencimiento para resolverlos en cuanto haya una solución disponible.
-
Falso positivo: cuando los escáneres de GitLab identifiquen un hallazgo como falso positivo (en los análisis de contenedores y dependencias), marcaremos el estado dentro de la vulnerabilidad. De este modo, las políticas de seguridad podrán filtrar los falsos positivos de la supervisión, lo que permitirá a los desarrolladores e ingenieros de AppSec ignorar estos hallazgos y fusionar el código sin preocupaciones. Las vulnerabilidades seguirán estando disponibles en el informe de vulnerabilidades en caso de que se requiera un análisis más detallado.
-
Antigüedad o acuerdo de nivel de servicio (SLA): a veces, las organizaciones pueden tolerar vulnerabilidades de menor gravedad durante un tiempo, pero estas deben planificarse y abordarse dentro de un SLA razonable. Por ejemplo, su estrategia de seguridad podría definir un SLA en función de la gravedad de una vulnerabilidad y autorizar la fusión de código que contenga vulnerabilidades de gravedad media sin necesidad de aprobación durante 60 días, siempre que se resuelvan mediante un ticket de seguimiento con fecha de vencimiento. Sin embargo, si la vulnerabilidad supera el SLA de 60 días, las solicitudes de fusión se bloquearán y habrá que resolver la vulnerabilidad.
Priorización de los hallazgos críticos en toda la organización
Un enfoque común para hacer frente a grandes volúmenes de vulnerabilidades es empezar poco a poco mediante la priorización de los hallazgos más críticos de su organización. Un SLA de clasificación de vulnerabilidades puede facilitar este proceso definiendo reglas para abordar las vulnerabilidades dentro de un SLA específico, en función de la gravedad de la vulnerabilidad. A continuación, se muestra una demostración rápida de cómo utilizar una política de aprobación de solicitudes de fusión de GitLab para aplicar diferentes SLA en función del nivel de gravedad de las vulnerabilidades. En este caso, si se detecta un hallazgo de alta gravedad, las solicitudes de fusión no se bloquearán durante 30 días, lo que permitirá a los desarrolladores resolver el problema dentro de la ventana del SLA.
Garantizar la separación de funciones
Las políticas de seguridad pueden gestionarse de varias maneras, pero lo mejor es crear un proyecto aislado en GitLab, que garantice la separación de funciones entre los profesionales de la seguridad y los equipos de desarrollo. Las políticas se almacenan en YAML. Este enfoque de política como código empodera a su equipo de seguridad y ofrece una serie de ventajas, como un historial en Git de los cambios en las políticas para una mayor visibilidad, control de versiones que facilita la reversión de cambios perjudiciales, supervisión y aprobaciones obligatorias de los cambios de política (si es necesario), auditabilidad mediante eventos de auditoría de GitLab y controles concretos que pueden presentarse como pruebas a los auditores.
Combinar todos estos elementos
La gestión de la afluencia cada vez mayor de vulnerabilidades requiere un enfoque preciso que combine análisis exhaustivos con una clasificación y corrección eficientes. Las políticas de seguridad de GitLab ofrecen una potente solución al permitir la colaboración, posibilitar la definición de reglas de política flexibles y personalizadas y proporcionar un medio para aplicar con precisión los requisitos y marcos de cumplimiento. Al aprovechar las herramientas de seguridad de GitLab y aplicar filtros y atributos personalizados, las organizaciones pueden optimizar la gestión de vulnerabilidades y centrar sus esfuerzos en abordar los riesgos más críticos. En última instancia, pueden reforzar su enfoque general de seguridad y cumplir con los requisitos de organismos externos. Aunque el código generado por la IA pueda suscitar preocupación, los tres pilares de la seguridad (personas, procesos y tecnología) permanecen inalterados. Al incorporar políticas de seguridad en sus procesos comerciales, puede proteger a su empresa contra este tipo de riesgos.
Además de utilizar políticas de seguridad para aplicar políticas como código a escala, la plataforma de DevSecOps de GitLab ofrece un sólido conjunto de herramientas de seguridad. En nuestro reciente Informe global de DevSecOps de 2023, el 57 % de los profesionales de la seguridad afirmaron que utilizan seis o más herramientas para el desarrollo de software y el 69 % de los profesionales de la seguridad afirmaron que desean consolidar su cadena de herramientas. Muchos CISO (responsables de seguridad de la información) aspiran a consolidar las herramientas, y GitLab ayuda a limitar la expansión de la cadena de herramientas. Ofrecemos las principales soluciones de análisis de seguridad: pruebas estáticas de seguridad de las aplicaciones (incluida la infraestructura como código), detección de secretos, pruebas dinámicas de seguridad de las aplicaciones (incluidas las API), análisis de dependencias y seguridad de las API. También simplificamos la gestión de vulnerabilidades para los equipos de AppSec mediante los informes dinámicos sobre vulnerabilidades. Por último, controlamos el cumplimiento a través de marcos de cumplimiento, informes de adhesión a los marcos de cumplimiento y eventos de auditoría.
Más información sobre cómo gestionar la seguridad de la aplicación con GitLab.
A continuación: Josh Lemos, CISO de GitLab, explica cómo resolver las frustraciones más comunes en materia de seguridad.