Las renovadas directrices del Consejo de Normas de Seguridad de la ICP: ¿Se desplazan lo suficientemente a la izquierda?
Una versión de este artículo se publicó originalmente en Revista Digital Transactions.
Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo este proceso ha cambiado con el tiempo, lo que requiere un replanteamiento de las normas de seguridad que se establecieron mucho antes de que la mayoría de nuestras vidas se digitalizaran rápidamente.
Esto es una prueba clara de que nuestro sector se compromete más con la idea de unas directrices adaptables -que evolucionan con nuestras necesidades cambiantes-, así como con las exigencias de un panorama de ciberseguridad que podría salirse rápidamente de control si seguimos siendo poco estrictos en nuestros procesos de desarrollo seguros. Naturalmente, el Consejo de Normas de Seguridad de la Industria de la Tarjeta de Pago (PCI), que actúa como organismo rector del sector bancario y financiero (es decir, establece las normas de seguridad del software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y en los puntos de venta), conlleva un gran riesgo y tiene una enorme motivación para reducirlo.
Aunque estas normas mejoran sin duda la versión anterior y contribuyen en cierta medida a tapar el agujero que tenemos en el desarrollo de funciones rápidas e innovadoras que también dan prioridad a la seguridad como parte de su calidad general assessment, es una realidad algo decepcionante comprobar que aún nos queda mucho camino por recorrer.
No, no soy yo quien da un "¡bah, humbug!" a esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos hacen avanzar lo suficiente hacia la izquierda.
Seguían obsesionados con las pruebas (y las hacían demasiado tarde).
Un problema evidente que encontré en el Marco de Normas de Seguridad de la PCI es su aparente dependencia de las pruebas. Por supuesto, el software debe seguir siendo probado (y el proceso SAST/DAST/IAST sigue teniendo su lugar), pero seguimos cayendo en la misma trampa y esperando un resultado diferente.
¿Quién escribe línea tras línea de código para crear el software que conocemos, amamos y en el que confiamos? Los desarrolladores de software.
¿Quién tiene la poco envidiable posición de probar este código, ya sea con herramientas de escaneo o con la revisión manual del código? Los especialistas en seguridad de las aplicaciones.
¿Qué siguen descubriendo estos especialistas? Los mismos fallos que nos han perseguido durante décadas. Cosas sencillas que hemos sabido arreglar durante años: Inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el día de la marmota para estos tipos. Pasaron su tiempo encontrando y arreglando violaciones de código que los propios desarrolladores han tenido el poder de arreglar durante años, excepto que la seguridad no se ha convertido en una prioridad en su proceso " especialmente ahora, en la era del desarrollo ágil donde la entrega de características es el rey, y la seguridad es el Grinch que roba el proceso creativo y el triunfo de la finalización del proyecto.
No se trata de un comentario negativo en assessment sobre ninguno de los dos equipos; tanto los desarrolladores como los profesionales de la seguridad de las aplicaciones tienen un trabajo extremadamente importante que hacer, pero siguen entorpeciendo el camino del otro. Esta situación sólo perpetúa un SDLC defectuoso, en el que los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro, que luego tiene que ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. El departamento de seguridad de las aplicaciones apenas tiene tiempo para arreglar los problemas verdaderamente complejos, porque está muy ocupado con los pequeños problemas recurrentes que podrían suponer un desastre para la empresa si no se controlan.
Estamos perdiendo tiempo, dinero y recursos al permitir que las pruebas sean el cajón de sastre para las debilidades de seguridad en el código. Y con las violaciones masivas de datos cada dos días, es evidente que este método no funciona de forma óptima, si es que lo hace. Estas nuevas normas siguen evaluando el estado de un producto final (quizás suponiendo que todos los desarrolladores son conscientes de la seguridad, lo que no es el caso): es decir, uno que ya está construido. Esta es la etapa más cara y difícil de corregir los defectos; es como construir una casa nueva y lujosa, sólo para traer un equipo de seguridad para comprobar cualquier peligro el mismo día que te mudas. Si algo va mal en los cimientos, imagínese el tiempo, el coste y el enorme dolor de cabeza que supone llegar a esa zona para empezar a solucionar los problemas. A menudo es más fácil y más barato simplemente empezar de nuevo (y qué proceso más insatisfactorio es ese para todos los que construyeron la primera versión).
Debemos trabajar absolutamente desde la base: haciendo que el equipo de desarrollo se comprometa con las mejores prácticas de seguridad, dándoles los conocimientos necesarios para codificar eficazmente de forma segura, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.
¿Es una curva de aprendizaje? Claro que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser un trabajo aburrido. Los métodos de formación que apelan directamente a los rasgos creativos y de resolución de problemas de los desarrolladores ya han tenido un inmenso éxito en el sector bancario y financiero, si la experiencia de Russ Wolfes en Capital One sirve de indicación.
Todavía estamos buscando el "estado final" perfecto.
Si se consideran las normas de seguridad de la PCI actualizadas en el contexto para el que fueron concebidas, es decir, si su producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para lograr una seguridad óptima, entonces están absolutamente bien. Sin embargo, en mi opinión, todas las empresas -financieras o de otro tipo- tendrían la mejor oportunidad de alcanzar un estado final del software que sea representativo tanto de la calidad de las características como de un alto nivel de seguridad, si dieran un paso atrás y se dieran cuenta de que es mucho más eficiente hacerlo desde el principio del ciclo.
¿Ese estado final perfecto? Ya sabe, ¿el que se produce cuando un producto se escanea, se revisa manualmente y sale perfecto y sin errores? Todavía lo estamos buscando. En este momento, es un unicornio.
¿Por qué es tan difícil de alcanzar? Hay varios factores:
- Se confía en las herramientas de escaneo, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y que hace perder tiempo, al igual que el hecho de que incluso juntos, los escaneos DAST/SAST/PCI simplemente no pueden identificar y revelar todas las posibles vulnerabilidades en la base de código. Claro que pueden dar el visto bueno, pero ¿realmente buscan todo? Un atacante sólo necesita explotar una vulnerabilidad para acceder a algo que crees que está protegido.
- Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos entre los desarrolladores en torno a la seguridad y no hay "recetas de código seguro" (patrones de código buenos y seguros) que sean conocidos y estén documentados.
- No se hace hincapié en la creación de una cultura de seguridad positiva y de colaboración.
- Los desarrolladores necesitan contar con las herramientas adecuadas para incorporar la seguridad a los productos que escriben, sin interrumpir sus procesos creativos y metodologías de desarrollo ágiles.
Estas directrices son una poderosa lista de verificación de las normas de seguridad que debe cumplir el software, pero el mejor proceso para conseguir que el software llegue a ese estado es objeto de debate.
No tenemos software inseguro porque nos falten escáneres, tenemos software inseguro porque los desarrolladores no disponen de herramientas de seguridad fáciles de usar y de entender que les sirvan de guía.
Ahora mismo estamos en una época de evolución. La seguridad del software en general, durante muchos años, era opcional. Hoy en día, es esencialmente obligatoria, sobre todo para los guardianes de la información sensible (financiera, médica, de la seguridad social... ya te haces una idea).
El PCI Security Standards Council está ayudando a establecer el punto de referencia, pero me encantaría verles -con toda su estima e influencia en la industria- trabajar para incluir directrices prácticas para los desarrolladores, haciendo hincapié en una formación y unas herramientas adecuadas y positivas. Por el momento, no hay presión para que las organizaciones se aseguren de que sus equipos de desarrollo sean conscientes de la seguridad y la cumplan, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de arreglar, cuando son explotados por quienes buscan hacer daño.
Como es de esperar con cualquier cosa que valga la pena en la vida, realmente se necesita una aldea para promulgar un verdadero cambio. Y el cambio en el aire va a arrastrarnos (esperemos) a todos hacia la izquierda.


Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno.
Director General, Presidente y Cofundador

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDirector General, Presidente y Cofundador
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.


Una versión de este artículo se publicó originalmente en Revista Digital Transactions.
Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo este proceso ha cambiado con el tiempo, lo que requiere un replanteamiento de las normas de seguridad que se establecieron mucho antes de que la mayoría de nuestras vidas se digitalizaran rápidamente.
Esto es una prueba clara de que nuestro sector se compromete más con la idea de unas directrices adaptables -que evolucionan con nuestras necesidades cambiantes-, así como con las exigencias de un panorama de ciberseguridad que podría salirse rápidamente de control si seguimos siendo poco estrictos en nuestros procesos de desarrollo seguros. Naturalmente, el Consejo de Normas de Seguridad de la Industria de la Tarjeta de Pago (PCI), que actúa como organismo rector del sector bancario y financiero (es decir, establece las normas de seguridad del software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y en los puntos de venta), conlleva un gran riesgo y tiene una enorme motivación para reducirlo.
Aunque estas normas mejoran sin duda la versión anterior y contribuyen en cierta medida a tapar el agujero que tenemos en el desarrollo de funciones rápidas e innovadoras que también dan prioridad a la seguridad como parte de su calidad general assessment, es una realidad algo decepcionante comprobar que aún nos queda mucho camino por recorrer.
No, no soy yo quien da un "¡bah, humbug!" a esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos hacen avanzar lo suficiente hacia la izquierda.
Seguían obsesionados con las pruebas (y las hacían demasiado tarde).
Un problema evidente que encontré en el Marco de Normas de Seguridad de la PCI es su aparente dependencia de las pruebas. Por supuesto, el software debe seguir siendo probado (y el proceso SAST/DAST/IAST sigue teniendo su lugar), pero seguimos cayendo en la misma trampa y esperando un resultado diferente.
¿Quién escribe línea tras línea de código para crear el software que conocemos, amamos y en el que confiamos? Los desarrolladores de software.
¿Quién tiene la poco envidiable posición de probar este código, ya sea con herramientas de escaneo o con la revisión manual del código? Los especialistas en seguridad de las aplicaciones.
¿Qué siguen descubriendo estos especialistas? Los mismos fallos que nos han perseguido durante décadas. Cosas sencillas que hemos sabido arreglar durante años: Inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el día de la marmota para estos tipos. Pasaron su tiempo encontrando y arreglando violaciones de código que los propios desarrolladores han tenido el poder de arreglar durante años, excepto que la seguridad no se ha convertido en una prioridad en su proceso " especialmente ahora, en la era del desarrollo ágil donde la entrega de características es el rey, y la seguridad es el Grinch que roba el proceso creativo y el triunfo de la finalización del proyecto.
No se trata de un comentario negativo en assessment sobre ninguno de los dos equipos; tanto los desarrolladores como los profesionales de la seguridad de las aplicaciones tienen un trabajo extremadamente importante que hacer, pero siguen entorpeciendo el camino del otro. Esta situación sólo perpetúa un SDLC defectuoso, en el que los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro, que luego tiene que ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. El departamento de seguridad de las aplicaciones apenas tiene tiempo para arreglar los problemas verdaderamente complejos, porque está muy ocupado con los pequeños problemas recurrentes que podrían suponer un desastre para la empresa si no se controlan.
Estamos perdiendo tiempo, dinero y recursos al permitir que las pruebas sean el cajón de sastre para las debilidades de seguridad en el código. Y con las violaciones masivas de datos cada dos días, es evidente que este método no funciona de forma óptima, si es que lo hace. Estas nuevas normas siguen evaluando el estado de un producto final (quizás suponiendo que todos los desarrolladores son conscientes de la seguridad, lo que no es el caso): es decir, uno que ya está construido. Esta es la etapa más cara y difícil de corregir los defectos; es como construir una casa nueva y lujosa, sólo para traer un equipo de seguridad para comprobar cualquier peligro el mismo día que te mudas. Si algo va mal en los cimientos, imagínese el tiempo, el coste y el enorme dolor de cabeza que supone llegar a esa zona para empezar a solucionar los problemas. A menudo es más fácil y más barato simplemente empezar de nuevo (y qué proceso más insatisfactorio es ese para todos los que construyeron la primera versión).
Debemos trabajar absolutamente desde la base: haciendo que el equipo de desarrollo se comprometa con las mejores prácticas de seguridad, dándoles los conocimientos necesarios para codificar eficazmente de forma segura, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.
¿Es una curva de aprendizaje? Claro que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser un trabajo aburrido. Los métodos de formación que apelan directamente a los rasgos creativos y de resolución de problemas de los desarrolladores ya han tenido un inmenso éxito en el sector bancario y financiero, si la experiencia de Russ Wolfes en Capital One sirve de indicación.
Todavía estamos buscando el "estado final" perfecto.
Si se consideran las normas de seguridad de la PCI actualizadas en el contexto para el que fueron concebidas, es decir, si su producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para lograr una seguridad óptima, entonces están absolutamente bien. Sin embargo, en mi opinión, todas las empresas -financieras o de otro tipo- tendrían la mejor oportunidad de alcanzar un estado final del software que sea representativo tanto de la calidad de las características como de un alto nivel de seguridad, si dieran un paso atrás y se dieran cuenta de que es mucho más eficiente hacerlo desde el principio del ciclo.
¿Ese estado final perfecto? Ya sabe, ¿el que se produce cuando un producto se escanea, se revisa manualmente y sale perfecto y sin errores? Todavía lo estamos buscando. En este momento, es un unicornio.
¿Por qué es tan difícil de alcanzar? Hay varios factores:
- Se confía en las herramientas de escaneo, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y que hace perder tiempo, al igual que el hecho de que incluso juntos, los escaneos DAST/SAST/PCI simplemente no pueden identificar y revelar todas las posibles vulnerabilidades en la base de código. Claro que pueden dar el visto bueno, pero ¿realmente buscan todo? Un atacante sólo necesita explotar una vulnerabilidad para acceder a algo que crees que está protegido.
- Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos entre los desarrolladores en torno a la seguridad y no hay "recetas de código seguro" (patrones de código buenos y seguros) que sean conocidos y estén documentados.
- No se hace hincapié en la creación de una cultura de seguridad positiva y de colaboración.
- Los desarrolladores necesitan contar con las herramientas adecuadas para incorporar la seguridad a los productos que escriben, sin interrumpir sus procesos creativos y metodologías de desarrollo ágiles.
Estas directrices son una poderosa lista de verificación de las normas de seguridad que debe cumplir el software, pero el mejor proceso para conseguir que el software llegue a ese estado es objeto de debate.
No tenemos software inseguro porque nos falten escáneres, tenemos software inseguro porque los desarrolladores no disponen de herramientas de seguridad fáciles de usar y de entender que les sirvan de guía.
Ahora mismo estamos en una época de evolución. La seguridad del software en general, durante muchos años, era opcional. Hoy en día, es esencialmente obligatoria, sobre todo para los guardianes de la información sensible (financiera, médica, de la seguridad social... ya te haces una idea).
El PCI Security Standards Council está ayudando a establecer el punto de referencia, pero me encantaría verles -con toda su estima e influencia en la industria- trabajar para incluir directrices prácticas para los desarrolladores, haciendo hincapié en una formación y unas herramientas adecuadas y positivas. Por el momento, no hay presión para que las organizaciones se aseguren de que sus equipos de desarrollo sean conscientes de la seguridad y la cumplan, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de arreglar, cuando son explotados por quienes buscan hacer daño.
Como es de esperar con cualquier cosa que valga la pena en la vida, realmente se necesita una aldea para promulgar un verdadero cambio. Y el cambio en el aire va a arrastrarnos (esperemos) a todos hacia la izquierda.

Una versión de este artículo se publicó originalmente en Revista Digital Transactions.
Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo este proceso ha cambiado con el tiempo, lo que requiere un replanteamiento de las normas de seguridad que se establecieron mucho antes de que la mayoría de nuestras vidas se digitalizaran rápidamente.
Esto es una prueba clara de que nuestro sector se compromete más con la idea de unas directrices adaptables -que evolucionan con nuestras necesidades cambiantes-, así como con las exigencias de un panorama de ciberseguridad que podría salirse rápidamente de control si seguimos siendo poco estrictos en nuestros procesos de desarrollo seguros. Naturalmente, el Consejo de Normas de Seguridad de la Industria de la Tarjeta de Pago (PCI), que actúa como organismo rector del sector bancario y financiero (es decir, establece las normas de seguridad del software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y en los puntos de venta), conlleva un gran riesgo y tiene una enorme motivación para reducirlo.
Aunque estas normas mejoran sin duda la versión anterior y contribuyen en cierta medida a tapar el agujero que tenemos en el desarrollo de funciones rápidas e innovadoras que también dan prioridad a la seguridad como parte de su calidad general assessment, es una realidad algo decepcionante comprobar que aún nos queda mucho camino por recorrer.
No, no soy yo quien da un "¡bah, humbug!" a esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos hacen avanzar lo suficiente hacia la izquierda.
Seguían obsesionados con las pruebas (y las hacían demasiado tarde).
Un problema evidente que encontré en el Marco de Normas de Seguridad de la PCI es su aparente dependencia de las pruebas. Por supuesto, el software debe seguir siendo probado (y el proceso SAST/DAST/IAST sigue teniendo su lugar), pero seguimos cayendo en la misma trampa y esperando un resultado diferente.
¿Quién escribe línea tras línea de código para crear el software que conocemos, amamos y en el que confiamos? Los desarrolladores de software.
¿Quién tiene la poco envidiable posición de probar este código, ya sea con herramientas de escaneo o con la revisión manual del código? Los especialistas en seguridad de las aplicaciones.
¿Qué siguen descubriendo estos especialistas? Los mismos fallos que nos han perseguido durante décadas. Cosas sencillas que hemos sabido arreglar durante años: Inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el día de la marmota para estos tipos. Pasaron su tiempo encontrando y arreglando violaciones de código que los propios desarrolladores han tenido el poder de arreglar durante años, excepto que la seguridad no se ha convertido en una prioridad en su proceso " especialmente ahora, en la era del desarrollo ágil donde la entrega de características es el rey, y la seguridad es el Grinch que roba el proceso creativo y el triunfo de la finalización del proyecto.
No se trata de un comentario negativo en assessment sobre ninguno de los dos equipos; tanto los desarrolladores como los profesionales de la seguridad de las aplicaciones tienen un trabajo extremadamente importante que hacer, pero siguen entorpeciendo el camino del otro. Esta situación sólo perpetúa un SDLC defectuoso, en el que los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro, que luego tiene que ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. El departamento de seguridad de las aplicaciones apenas tiene tiempo para arreglar los problemas verdaderamente complejos, porque está muy ocupado con los pequeños problemas recurrentes que podrían suponer un desastre para la empresa si no se controlan.
Estamos perdiendo tiempo, dinero y recursos al permitir que las pruebas sean el cajón de sastre para las debilidades de seguridad en el código. Y con las violaciones masivas de datos cada dos días, es evidente que este método no funciona de forma óptima, si es que lo hace. Estas nuevas normas siguen evaluando el estado de un producto final (quizás suponiendo que todos los desarrolladores son conscientes de la seguridad, lo que no es el caso): es decir, uno que ya está construido. Esta es la etapa más cara y difícil de corregir los defectos; es como construir una casa nueva y lujosa, sólo para traer un equipo de seguridad para comprobar cualquier peligro el mismo día que te mudas. Si algo va mal en los cimientos, imagínese el tiempo, el coste y el enorme dolor de cabeza que supone llegar a esa zona para empezar a solucionar los problemas. A menudo es más fácil y más barato simplemente empezar de nuevo (y qué proceso más insatisfactorio es ese para todos los que construyeron la primera versión).
Debemos trabajar absolutamente desde la base: haciendo que el equipo de desarrollo se comprometa con las mejores prácticas de seguridad, dándoles los conocimientos necesarios para codificar eficazmente de forma segura, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.
¿Es una curva de aprendizaje? Claro que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser un trabajo aburrido. Los métodos de formación que apelan directamente a los rasgos creativos y de resolución de problemas de los desarrolladores ya han tenido un inmenso éxito en el sector bancario y financiero, si la experiencia de Russ Wolfes en Capital One sirve de indicación.
Todavía estamos buscando el "estado final" perfecto.
Si se consideran las normas de seguridad de la PCI actualizadas en el contexto para el que fueron concebidas, es decir, si su producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para lograr una seguridad óptima, entonces están absolutamente bien. Sin embargo, en mi opinión, todas las empresas -financieras o de otro tipo- tendrían la mejor oportunidad de alcanzar un estado final del software que sea representativo tanto de la calidad de las características como de un alto nivel de seguridad, si dieran un paso atrás y se dieran cuenta de que es mucho más eficiente hacerlo desde el principio del ciclo.
¿Ese estado final perfecto? Ya sabe, ¿el que se produce cuando un producto se escanea, se revisa manualmente y sale perfecto y sin errores? Todavía lo estamos buscando. En este momento, es un unicornio.
¿Por qué es tan difícil de alcanzar? Hay varios factores:
- Se confía en las herramientas de escaneo, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y que hace perder tiempo, al igual que el hecho de que incluso juntos, los escaneos DAST/SAST/PCI simplemente no pueden identificar y revelar todas las posibles vulnerabilidades en la base de código. Claro que pueden dar el visto bueno, pero ¿realmente buscan todo? Un atacante sólo necesita explotar una vulnerabilidad para acceder a algo que crees que está protegido.
- Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos entre los desarrolladores en torno a la seguridad y no hay "recetas de código seguro" (patrones de código buenos y seguros) que sean conocidos y estén documentados.
- No se hace hincapié en la creación de una cultura de seguridad positiva y de colaboración.
- Los desarrolladores necesitan contar con las herramientas adecuadas para incorporar la seguridad a los productos que escriben, sin interrumpir sus procesos creativos y metodologías de desarrollo ágiles.
Estas directrices son una poderosa lista de verificación de las normas de seguridad que debe cumplir el software, pero el mejor proceso para conseguir que el software llegue a ese estado es objeto de debate.
No tenemos software inseguro porque nos falten escáneres, tenemos software inseguro porque los desarrolladores no disponen de herramientas de seguridad fáciles de usar y de entender que les sirvan de guía.
Ahora mismo estamos en una época de evolución. La seguridad del software en general, durante muchos años, era opcional. Hoy en día, es esencialmente obligatoria, sobre todo para los guardianes de la información sensible (financiera, médica, de la seguridad social... ya te haces una idea).
El PCI Security Standards Council está ayudando a establecer el punto de referencia, pero me encantaría verles -con toda su estima e influencia en la industria- trabajar para incluir directrices prácticas para los desarrolladores, haciendo hincapié en una formación y unas herramientas adecuadas y positivas. Por el momento, no hay presión para que las organizaciones se aseguren de que sus equipos de desarrollo sean conscientes de la seguridad y la cumplan, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de arreglar, cuando son explotados por quienes buscan hacer daño.
Como es de esperar con cualquier cosa que valga la pena en la vida, realmente se necesita una aldea para promulgar un verdadero cambio. Y el cambio en el aire va a arrastrarnos (esperemos) a todos hacia la izquierda.

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónDirector General, Presidente y Cofundador
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.
Una versión de este artículo se publicó originalmente en Revista Digital Transactions.
Este año, el PCI Security Standards Council ha publicado un nuevo conjunto de directrices de seguridad del software como parte de su PCI Software Security Framework. Esta actualización pretende adaptar las mejores prácticas de seguridad del software al desarrollo de software moderno. Es una iniciativa fantástica que reconoce cómo este proceso ha cambiado con el tiempo, lo que requiere un replanteamiento de las normas de seguridad que se establecieron mucho antes de que la mayoría de nuestras vidas se digitalizaran rápidamente.
Esto es una prueba clara de que nuestro sector se compromete más con la idea de unas directrices adaptables -que evolucionan con nuestras necesidades cambiantes-, así como con las exigencias de un panorama de ciberseguridad que podría salirse rápidamente de control si seguimos siendo poco estrictos en nuestros procesos de desarrollo seguros. Naturalmente, el Consejo de Normas de Seguridad de la Industria de la Tarjeta de Pago (PCI), que actúa como organismo rector del sector bancario y financiero (es decir, establece las normas de seguridad del software en el que confiamos para proteger todo nuestro dinero, tarjetas de crédito, transacciones en línea y en los puntos de venta), conlleva un gran riesgo y tiene una enorme motivación para reducirlo.
Aunque estas normas mejoran sin duda la versión anterior y contribuyen en cierta medida a tapar el agujero que tenemos en el desarrollo de funciones rápidas e innovadoras que también dan prioridad a la seguridad como parte de su calidad general assessment, es una realidad algo decepcionante comprobar que aún nos queda mucho camino por recorrer.
No, no soy yo quien da un "¡bah, humbug!" a esta iniciativa. El hecho es que estas nuevas directrices de seguridad simplemente no nos hacen avanzar lo suficiente hacia la izquierda.
Seguían obsesionados con las pruebas (y las hacían demasiado tarde).
Un problema evidente que encontré en el Marco de Normas de Seguridad de la PCI es su aparente dependencia de las pruebas. Por supuesto, el software debe seguir siendo probado (y el proceso SAST/DAST/IAST sigue teniendo su lugar), pero seguimos cayendo en la misma trampa y esperando un resultado diferente.
¿Quién escribe línea tras línea de código para crear el software que conocemos, amamos y en el que confiamos? Los desarrolladores de software.
¿Quién tiene la poco envidiable posición de probar este código, ya sea con herramientas de escaneo o con la revisión manual del código? Los especialistas en seguridad de las aplicaciones.
¿Qué siguen descubriendo estos especialistas? Los mismos fallos que nos han perseguido durante décadas. Cosas sencillas que hemos sabido arreglar durante años: Inyección SQL, cross-site scripting, debilidades en la gestión de sesiones... es como el día de la marmota para estos tipos. Pasaron su tiempo encontrando y arreglando violaciones de código que los propios desarrolladores han tenido el poder de arreglar durante años, excepto que la seguridad no se ha convertido en una prioridad en su proceso " especialmente ahora, en la era del desarrollo ágil donde la entrega de características es el rey, y la seguridad es el Grinch que roba el proceso creativo y el triunfo de la finalización del proyecto.
No se trata de un comentario negativo en assessment sobre ninguno de los dos equipos; tanto los desarrolladores como los profesionales de la seguridad de las aplicaciones tienen un trabajo extremadamente importante que hacer, pero siguen entorpeciendo el camino del otro. Esta situación sólo perpetúa un SDLC defectuoso, en el que los desarrolladores con poca conciencia de seguridad operan en una cultura de seguridad negativa, produciendo código inseguro, que luego tiene que ser escaneado, evaluado y corregido mucho después de haber sido escrito inicialmente. El departamento de seguridad de las aplicaciones apenas tiene tiempo para arreglar los problemas verdaderamente complejos, porque está muy ocupado con los pequeños problemas recurrentes que podrían suponer un desastre para la empresa si no se controlan.
Estamos perdiendo tiempo, dinero y recursos al permitir que las pruebas sean el cajón de sastre para las debilidades de seguridad en el código. Y con las violaciones masivas de datos cada dos días, es evidente que este método no funciona de forma óptima, si es que lo hace. Estas nuevas normas siguen evaluando el estado de un producto final (quizás suponiendo que todos los desarrolladores son conscientes de la seguridad, lo que no es el caso): es decir, uno que ya está construido. Esta es la etapa más cara y difícil de corregir los defectos; es como construir una casa nueva y lujosa, sólo para traer un equipo de seguridad para comprobar cualquier peligro el mismo día que te mudas. Si algo va mal en los cimientos, imagínese el tiempo, el coste y el enorme dolor de cabeza que supone llegar a esa zona para empezar a solucionar los problemas. A menudo es más fácil y más barato simplemente empezar de nuevo (y qué proceso más insatisfactorio es ese para todos los que construyeron la primera versión).
Debemos trabajar absolutamente desde la base: haciendo que el equipo de desarrollo se comprometa con las mejores prácticas de seguridad, dándoles los conocimientos necesarios para codificar eficazmente de forma segura, además de crear y mantener una cultura de seguridad positiva en cada lugar de trabajo.
¿Es una curva de aprendizaje? Claro que sí. ¿Es imposible? Definitivamente no. Y no tiene por qué ser un trabajo aburrido. Los métodos de formación que apelan directamente a los rasgos creativos y de resolución de problemas de los desarrolladores ya han tenido un inmenso éxito en el sector bancario y financiero, si la experiencia de Russ Wolfes en Capital One sirve de indicación.
Todavía estamos buscando el "estado final" perfecto.
Si se consideran las normas de seguridad de la PCI actualizadas en el contexto para el que fueron concebidas, es decir, si su producto financiero terminado y listo para el usuario debe seguir estas mejores prácticas para lograr una seguridad óptima, entonces están absolutamente bien. Sin embargo, en mi opinión, todas las empresas -financieras o de otro tipo- tendrían la mejor oportunidad de alcanzar un estado final del software que sea representativo tanto de la calidad de las características como de un alto nivel de seguridad, si dieran un paso atrás y se dieran cuenta de que es mucho más eficiente hacerlo desde el principio del ciclo.
¿Ese estado final perfecto? Ya sabe, ¿el que se produce cuando un producto se escanea, se revisa manualmente y sale perfecto y sin errores? Todavía lo estamos buscando. En este momento, es un unicornio.
¿Por qué es tan difícil de alcanzar? Hay varios factores:
- Se confía en las herramientas de escaneo, pero no siempre son eficaces. Los falsos positivos son un subproducto frustrante y que hace perder tiempo, al igual que el hecho de que incluso juntos, los escaneos DAST/SAST/PCI simplemente no pueden identificar y revelar todas las posibles vulnerabilidades en la base de código. Claro que pueden dar el visto bueno, pero ¿realmente buscan todo? Un atacante sólo necesita explotar una vulnerabilidad para acceder a algo que crees que está protegido.
- Los desarrolladores siguen cometiendo los mismos errores. No hay una distribución de conocimientos entre los desarrolladores en torno a la seguridad y no hay "recetas de código seguro" (patrones de código buenos y seguros) que sean conocidos y estén documentados.
- No se hace hincapié en la creación de una cultura de seguridad positiva y de colaboración.
- Los desarrolladores necesitan contar con las herramientas adecuadas para incorporar la seguridad a los productos que escriben, sin interrumpir sus procesos creativos y metodologías de desarrollo ágiles.
Estas directrices son una poderosa lista de verificación de las normas de seguridad que debe cumplir el software, pero el mejor proceso para conseguir que el software llegue a ese estado es objeto de debate.
No tenemos software inseguro porque nos falten escáneres, tenemos software inseguro porque los desarrolladores no disponen de herramientas de seguridad fáciles de usar y de entender que les sirvan de guía.
Ahora mismo estamos en una época de evolución. La seguridad del software en general, durante muchos años, era opcional. Hoy en día, es esencialmente obligatoria, sobre todo para los guardianes de la información sensible (financiera, médica, de la seguridad social... ya te haces una idea).
El PCI Security Standards Council está ayudando a establecer el punto de referencia, pero me encantaría verles -con toda su estima e influencia en la industria- trabajar para incluir directrices prácticas para los desarrolladores, haciendo hincapié en una formación y unas herramientas adecuadas y positivas. Por el momento, no hay presión para que las organizaciones se aseguren de que sus equipos de desarrollo sean conscientes de la seguridad y la cumplan, ni muchos desarrolladores comprenden la magnitud de esos pequeños errores, fáciles de arreglar, cuando son explotados por quienes buscan hacer daño.
Como es de esperar con cualquier cosa que valga la pena en la vida, realmente se necesita una aldea para promulgar un verdadero cambio. Y el cambio en el aire va a arrastrarnos (esperemos) a todos hacia la izquierda.
Índice
Director General, Presidente y Cofundador

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Recursos para empezar
Estableciendo el estándar: SCW publica reglas de seguridad de codificación de IA gratuitas en GitHub
El desarrollo asistido por IA ya no es una posibilidad: ya está aquí y está transformando rápidamente la forma de escribir software. Herramientas como GitHub Copilot, Cline, Roo, Cursor, Aider y Windsurf están transformando a los desarrolladores en sus propios copilotos, permitiendo iteraciones más rápidas y acelerando todo, desde la creación de prototipos hasta grandes proyectos de refactorización.
Cierre el círculo de las vulnerabilidades con Secure Code Warrior + HackerOne
Secure Code Warrior se complace en anunciar nuestra nueva integración con HackerOne, líder en soluciones de seguridad ofensiva. Juntos, estamos construyendo un ecosistema potente e integrado. HackerOne señala dónde se producen realmente las vulnerabilidades en entornos reales, exponiendo el "qué" y el "dónde" de los problemas de seguridad.
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.