El desarrollo seguro toma una aldea (remota)



El cambio para trabajar desde casa no se trata solo de brindarle a su equipo de desarrollo las herramientas físicas que necesitan.

El desarrollo es un proceso colaborativo. Sí, requiere períodos de tiempo concentrado para crear, pero todos los desarrolladores dependen en gran medida de sus compañeros de equipo para ayudar a planificar la solución correcta, construir los diferentes componentes en ella y revisar los cambios realizados. Además, el equipo de desarrollo debe colaborar con el resto del negocio para asegurarse de que su creación logre los resultados que todos buscan.

Esta colaboración se ha visto sacudida por el trabajo remoto a tiempo completo impuesto a prácticamente todos los desarrolladores como resultado de COVID-19. Algunos equipos están mejor equipados para manejarlo que otros, pero pocos son realmente inmunes al cambio. La ausencia complete de sesiones de pizarra en persona, conversaciones en el pasillo y charlas amistosas junto a la máquina de café significa que ahora tenemos que adaptar la forma en que trabajamos juntos para crear y entregar un excelente application.

La seguridad tiene un riesgo aún mayor de ser ignorada. Para empezar, el riesgo es naturalmente invisible, por lo que es muy fácil pasarlo por alto. En segundo lugar, las prácticas de desarrollo seguro todavía se están formando y ahora requieren un agarre más cuidadoso. Por último, la colaboración entre los equipos de desarrollo y seguridad a menudo no es excelente en tiempos normales. Hoy, la colaboración puede empeorar fácilmente ahora.

¿Qué se necesita? Debemos hacer un esfuerzo concentrado para asegurar el desarrollo mientras trabajamos desde casa. A continuación, se muestran cinco prácticas recomendadas que deben adoptar los equipos de desarrollo y seguridad:

Práctica 1: Capacite a los desarrolladores para que construyan teniendo en cuenta la seguridad.
Para alentar a los desarrolladores a construir con una mentalidad de seguridad primero, primero deben comprender cómo se ve bien y qué se espera de ellos cuando se trata de ciberseguridad. La mejor manera de hacerlo es proporcionar a los desarrolladores pautas completas para los procesos de seguridad. Esto les permitirá hacer avanzar los elementos sin tener que detenerse y esperar la aprobación. Empoderar a los desarrolladores con tal responsabilidad les ayudará a sentirse más seguros de que, en última instancia, están creando aplicaciones completamente seguras porque hicieron las preguntas correctas en el camino.

Práctica 2: Invierta en visibilidad de la seguridad
No se puede capacitar a los desarrolladores para que adopten la seguridad sin darles visibilidad de las vulnerabilidades críticas. A continuación, se muestran algunas formas de hacerlo:

  • Cree una lista de materiales de software program detallada (SBOM) para cada aplicación para que su equipo de desarrollo sepa si alguna vulnerabilidad recientemente revelada afectará a sus proyectos en curso.
  • Genere conciencia sobre las vulnerabilidades descubiertas en las compilaciones que no fueron lo suficientemente graves como para comunicarlas a todo el equipo, ya sea en Slack o en un canal de comunicaciones internas equivalente, para que pueda evitar la repetición de errores entre equipos.
  • Cree tablas de clasificación que muestren qué tan bien los diferentes equipos están manejando los problemas de seguridad. Esta es una forma divertida de avivar la competencia mientras aprenden unos de otros.

Práctica 3: en lugar de romper la compilación, falla las solicitudes de extracción.
Romper la compilación debido a una violación de seguridad es una medida de seguridad de CI / CD preferred, pero también es perjudicial. Esto es especialmente cierto cuando se trabaja de forma remota, ya que se tarda mucho más en descubrir el problema y resolverlo. En su lugar, fallar las solicitudes de extracción esto tiene varias ventajas, que incluyen:

  • Le permiten probar solo los nuevos cambios de código, que deben estar dentro del manage del desarrollador para corregirlos.
  • Son más locales en la rama donde se modifica el código, lo que empodera a los desarrolladores y mantiene la autonomía specific.
  • Puede elegir si una solicitud de extracción fallida bloquea una fusión o es solo informativa, lo que nuevamente permite a los desarrolladores tomar sus propias decisiones.

Práctica 4: ¡Únete!
Para ayudar a los desarrolladores remotos a saber a quién acudir cuando tengan una pregunta de seguridad, haga coincidir a las personas de los equipos de seguridad con una persona de desarrollo y viceversa. La construcción de estas relaciones de uno a uno creará una relación typical más sólida entre las dos funciones.

Práctica 5: Céntrese primero en los conceptos básicos de seguridad.
Puede parecer contradictorio, pero cuando se trata de seguridad, prioriza lo básico antes que los ataques esotéricos. Debe tener prioridad escalar qué tan bien maneja los componentes vulnerables, los errores de configuración y los tokens filtrados. Una vez que sus equipos de desarrollo remoto hayan marcado estas casillas, estarán mejor equipados para abordar desafíos de seguridad más complejos y multifacéticos a medida que surjan.

Práctica 6: Mejora la seguridad SSH.
A medida que más máquinas se vuelven remotas, el riesgo de que una máquina de desarrollo se vea comprometida es mayor. Estas máquinas de desarrollo a menudo tienen acceso a sistemas sensibles, como repositorios de código fuente o sistemas de producción en los que pueden SSH. Estos tres pasos pueden ayudar a asegurar de manera más efectiva esos canales para mitigar el daño potencial:

  • Habilite la autenticación mutua basada en claves.
  • Habilite o reduzca los tiempos de espera de la sesión.
  • Habilite una autenticación basada en identidad más sólida.

Práctica 7: Recompensas por errores
Las recompensas de errores son una buena manera de agregar una capa adicional de capacidad de evaluación de seguridad. Revisa Bugcrowd o HackerOne —Pueden guiarlo a través de gran parte del proceso de configuración de su propio programa si lo desea.

El cambio al trabajo remoto no se trata solo de asegurarse de que los miembros de su equipo tengan las herramientas físicas que necesitan para trabajar fuera de la oficina. Se trata de recrear los aspectos positivos de un entorno de oficina para que los desarrolladores puedan lograr grandes resultados al colaborar con su «aldea» elegida.

Contenido relacionado:

Guy Podjarny (@guypod) es cofundador de Snyk.io y se centra en proteger el código fuente abierto. Male fue anteriormente CTO en Akamai luego de la adquisición de su startup, Blaze.io. Antes de eso, Person trabajó en el primer analizador de código de seguridad y firewall de aplicaciones net, y se ocupó de … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia authentic