Cambio a la izquierda
Si un desarrollador escribe un error de cross-site scripting mientras está codificando en JavaScript, y es capaz de detectarlo a los pocos minutos de crear ese fallo, es probable que sólo requiera minutos o segundos para solucionarlo.
Mientras que si ese fallo es descubierto dos semanas más tarde por un probador manual, será introducido en un sistema de seguimiento de defectos. Va a ser clasificado. Va a ser puesto en la cola de errores de alguien.
Con el retraso en la identificación, tendrá que ser investigado en su contexto original y ralentizará el desarrollo. Ahora, estás hablando potencialmente de horas de tiempo para arreglar el mismo defecto. Tal vez una escala de 10 o 100 veces más tiempo se toma
No podría estar más de acuerdo con Chris Wysopal (CTO, Veracode) en su reciente podcast con O'Reilly Security Podcast donde explica por qué desplazar la seguridad a la izquierda (a los desarrolladores al inicio del ciclo de vida del desarrollo) es clave en un entorno ágil para mantener el ritmo y la velocidad.
La seguridad debe facilitarse a los desarrolladores mediante el uso de plug-ins de IDE, escáneres y educándolos para que tengan los conocimientos básicos de seguridad (higiene). Las organizaciones no deberían depender únicamente de expertos en seguridad o de un equipo de seguridad centralizado que valide todos los cambios.
Nuestro típico modus operandi en materia de seguridad se ha roto (¡llamar al experto!) y necesitamos integrar la seguridad en los equipos de desarrollo para garantizar el mantenimiento de la calidad sin dejar de ser ágiles.
Pieter Danhieux
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Artículos relacionados que recomendamos
Artículos relacionados que recomendamos
Sumérjase en nuestras últimas ideas sobre codificación segura en el blog.
Nuestra amplia biblioteca de recursos tiene como objetivo potenciar el enfoque humano de la mejora de la codificación segura.
Obtenga las últimas investigaciones sobre la seguridad impulsada por los desarrolladores
Nuestra amplia biblioteca de recursos está repleta de recursos útiles, desde libros blancos hasta seminarios web, que le ayudarán a iniciarse en la codificación segura orientada a los desarrolladores. Explórela ahora.
Cambio a la izquierda
Si un desarrollador escribe un error de cross-site scripting mientras está codificando en JavaScript, y es capaz de detectarlo a los pocos minutos de crear ese fallo, es probable que sólo requiera minutos o segundos para solucionarlo.
Mientras que si ese fallo es descubierto dos semanas más tarde por un probador manual, será introducido en un sistema de seguimiento de defectos. Va a ser clasificado. Va a ser puesto en la cola de errores de alguien.
Con el retraso en la identificación, tendrá que ser investigado en su contexto original y ralentizará el desarrollo. Ahora, estás hablando potencialmente de horas de tiempo para arreglar el mismo defecto. Tal vez una escala de 10 o 100 veces más tiempo se toma
No podría estar más de acuerdo con Chris Wysopal (CTO, Veracode) en su reciente podcast con O'Reilly Security Podcast donde explica por qué desplazar la seguridad a la izquierda (a los desarrolladores al inicio del ciclo de vida del desarrollo) es clave en un entorno ágil para mantener el ritmo y la velocidad.
La seguridad debe facilitarse a los desarrolladores mediante el uso de plug-ins de IDE, escáneres y educándolos para que tengan los conocimientos básicos de seguridad (higiene). Las organizaciones no deberían depender únicamente de expertos en seguridad o de un equipo de seguridad centralizado que valide todos los cambios.
Nuestro típico modus operandi en materia de seguridad se ha roto (¡llamar al experto!) y necesitamos integrar la seguridad en los equipos de desarrollo para garantizar el mantenimiento de la calidad sin dejar de ser ágiles.
