Desplazamiento a la izquierda: del concepto a la práctica



Al trasladar la seguridad al desarrollo, su equipo puede encontrar y corregir vulnerabilidades antes de que se conviertan en problemas costosos, difíciles y vergonzosos para el público.

Con la expansión de los modelos DevOps y DevSecOps, el concepto de «cambiar a la izquierda» en el ciclo de vida del desarrollo de computer software (SDLC) se ha vuelto well-known. Cambiar las acciones operativas y de seguridad clave al principio del ciclo permite detectar vulnerabilidades lo antes posible. Esto tiene un valor significativo, ya que cuanto más tarde se descubre una vulnerabilidad, más difícil y costoso resulta remediar.

Para adoptar esto, las organizaciones deben integrar controles de seguridad y detección de vulnerabilidades en cada paso del SDLC, en lugar de pensar en ellos como puertas. Desplazarse a la izquierda se trata de hacer que la seguridad esté más centrada en el desarrollador y proporcionar comentarios de seguridad mientras codifican.

¿Por qué trasladar la seguridad al desarrollo?
La seguridad de Change-still left es clave para entregar software package de calidad a gran velocidad. En lugar de ejecutar auditorías de seguridad al last del SDLC, shift-remaining hace que la seguridad sea una parte integral del trabajo de todos: desarrolladores, operaciones y seguridad de aplicaciones o equipos de respuesta a amenazas.

Las tareas de seguridad deben automatizarse e integrarse dentro del proceso de desarrollo e implementación. Los escaneos automatizados deben ocurrir en cada cambio incremental en el momento exacto en que se escriben para que:

  • Las vulnerabilidades no se descubren al last del ciclo de desarrollo.
  • Los desarrolladores y las operaciones reciben una notificación rápida cada vez que se cometen vulnerabilidades potenciales, lo que les permite detectar y corregir rápidamente los problemas de seguridad en su trabajo diario.
  • Los desarrolladores pueden aprender rápidamente de sus errores y aplicar las mejores prácticas relacionadas con la higiene del código.

Al integrar mejor los objetivos de seguridad de las aplicaciones en el trabajo diario, los equipos pueden lograr niveles más altos de rendimiento en la entrega de computer software y crear aplicaciones más seguras. Esto ayuda a generar responsabilidad entre los miembros del equipo que no son de seguridad.

A los desarrolladores les puede preocupar que los análisis de seguridad agreguen trabajo adicional y lentifiquen las implementaciones. Esto es razonable, conociendo la presión sobre los equipos de desarrollo para producir código rápidamente. Pero los desarrolladores también están ansiosos por mejorar la calidad y la seguridad de su trabajo.

Pero la detección de desplazamiento a la izquierda puede aliviar esas preocupaciones al integrar y automatizar los análisis de seguridad dentro de las herramientas y procesos existentes. Además, no hay estrés el día del lanzamiento cuando el equipo de seguridad bloquea el lanzamiento debido a una vulnerabilidad que el desarrollador no conocía.

Un enfoque centrado en el desarrollador permite a los desarrolladores responder a las alertas mientras codifican. El tiempo real es mucho mejor que días después de la implementación, o meses después en un informe de prueba de penetración. Esto es elementary en términos de exposición a la vulnerabilidad y costo de reparación. Es basic prevenir las infracciones antes de que puedan afectar la seguridad de la empresa y abordar y corregir rápidamente las vulnerabilidades descubiertas recientemente.

Poniendo Shift Remaining en práctica con la detección de secretos
La seguridad de las aplicaciones se basa en la detección de diferentes tipos de vulnerabilidades en el Modelo de madurez de OWASP DevSecOps, incluidos los secretos almacenados. De hecho, la detección automática de secretos pone en práctica el cambio a la izquierda.

Debido a que los desarrolladores trabajan con código y en Git, es lógico aplicar controles de seguridad en Git. Al observar las filtraciones de secretos, desplazarse a la izquierda significa detectar automáticamente los secretos en el código y permitir que los diferentes miembros del SDLC colaboren.

La reparación de los secretos filtrados en los repositorios de Git es una responsabilidad compartida entre los desarrolladores, las operaciones y la seguridad de la aplicación (si el secreto se expone en los repositorios de código interno) o la respuesta a amenazas (si el secreto se expone de forma externa). Los procesos dependen del tamaño, la cultura y la forma en que divide las responsabilidades entre los equipos de la organización.

Todos se necesitan unos a otros, pero los desarrolladores están en primera línea. A menudo saben a qué da acceso el secreto filtrado. Sin embargo, no siempre pueden revocar el secreto por sí solos porque podría afectar a los sistemas de producción o a otros desarrolladores que utilizan las mismas credenciales. Además, no se trata solo de revocar también se trata de redistribuir (rotar), que es responsabilidad de las operaciones.

Mientras se soluciona, también es importante mantener la atención de los profesionales de seguridad en el problema. Pueden garantizar que se sigan los pasos de corrección adecuados y guiar y educar a los desarrolladores sobre los riesgos. Los desarrolladores no siempre comprenden el impacto genuine de sus acciones. Para los profesionales de la seguridad, las alertas deben ser procesables con la menor cantidad posible de falsos positivos para evitar la fatiga de las alertas.

La remediación es una responsabilidad compartida que requiere múltiples entradas y comunicación multidireccional. Las herramientas de colaboración adecuadas ayudan a garantizar que se pueda recopilar información de diferentes partes interesadas.

Dónde implementar la detección automática de secretos
Cuanto antes se descubra una vulnerabilidad de seguridad, menos costoso será corregirla. Los secretos codificados de forma rígida no son una excepción. Si el secreto se descubre después de que alcanza el management de versiones centralizado en el lado del servidor, se considera comprometido. Esto requiere rotar (revocar y redistribuir) la credencial expuesta, que puede ser compleja e involucrar a múltiples partes interesadas.

La detección temprana de secretos del lado del cliente en el SDLC es buena para evitar que los secretos ingresen al sistema de management de versiones (VCS). La detección de secretos del lado del servidor es imprescindible porque ahí es donde se encuentra la amenaza closing. Desde el servidor, el código puede extenderse incontrolablemente en muchos lugares diferentes con los secretos codificados en él.

El problema con las herramientas del lado del cliente es la complejidad de la implementación: cuanto más grande es el equipo de desarrollo, más complejo es. Implementar enlaces del lado del cliente a nivel organizacional es difícil. Muchos profesionales de la seguridad de aplicaciones afirman que no están seguros de hacerlo debido a la dificultad de implementar y actualizar la estación de trabajo de cada desarrollador. También es una solución no coercitiva: los ganchos del lado del cliente pueden y deben ser fáciles de eludir. Los ganchos del lado del cliente son en gran medida responsabilidad del desarrollador personal, de ahí la necesidad de tener visibilidad en las etapas posteriores.

Empoderar a los desarrolladores Mejorar la seguridad
El desplazamiento a la izquierda permite a los equipos probar continuamente incluso los cambios de código incrementales y pequeños y evita una gran cantidad de trabajo al closing del SDLC. La integración de análisis y pruebas de seguridad en cada paso del proceso de desarrollo reduce la superficie de vulnerabilidad de la organización.

Cambiar a la izquierda implica automatizar la seguridad tanto como sea posible y capacitar a los desarrolladores con un ciclo de retroalimentación de seguridad rápido y continuo. Los resultados del escaneo deben ser sencillos y prácticos, y el proceso debe estar completamente automatizado. Las alertas deben ser relevantes y limitar los falsos positivos. Incluso la remediación debería facilitarse y automatizarse siempre que sea posible.

Ayuda a construir una cultura donde la seguridad es gratificante y respeta el tiempo de los desarrolladores. Los desarrolladores quieren crear código seguro sin convertirse en expertos en seguridad Los expertos en seguridad quieren un código seguro que aproveche el conocimiento de los desarrolladores durante la corrección.

Mackenzie Jackson es la defensora de los desarrolladores de GitGuardian. Le apasiona la tecnología y la construcción de una comunidad de desarrolladores comprometidos para dar forma a las herramientas y los sistemas del futuro. Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia primary