¿Cómo definen los desarrolladores la "codificación segura"?
Una versión de este artículo apareció en TechRepublic. Se ha actualizado y sindicado aquí.
La creación de un entorno en el que los objetivos del equipo de seguridad y sus homólogos de desarrollo estén alineados ha sido una batalla ardua, aunque esencial. Nos queda un largo camino por recorrer, pero los obstáculos que se interponen en el camino de la sinergia necesaria para abrir la puerta a la responsabilidad compartida de la seguridad del software son cada vez más claros. Las empresas inteligentes quieren evolucionar su estrategia para evitar esos escollos, encontrar un camino productivo hacia adelante y utilizar DevSecOps en todo su potencial.
Lo que no había previsto es que la percepción de lo que constituye el acto de codificación segura es objeto de debate. Según una nueva investigación realizada en colaboración con Evans Data, este sentimiento se puso en blanco y negro. La encuesta State of Developer-Driven Security 2022 profundiza en las ideas y experiencias clave de 1.200 desarrolladores activos, iluminando sus actitudes y desafíos en el ámbito de la seguridad.
Una de las conclusiones más destacadas fue que sólo el 14% de los desarrolladores consideran la seguridad una prioridad a la hora de codificar. Si bien esto demuestra que hay un enorme margen de mejora, confirma lo que ya sabíamos: la creación de características es el rey en el mundo de los desarrolladores, y siguen estando mal equipados para hacer de la seguridad parte de su ADN. Sin embargo, cuando se combina con los datos sobre las definiciones de los desarrolladores de lo que significa para ellos la codificación segura, es motivo de preocupación.
Estas percepciones son impulsadas por la experiencia de los desarrolladores en su día a día, y habla del entorno de muchas organizaciones, que es que los desarrolladores simplemente no son un punto focal en la lucha contra las vulnerabilidades comunes. Su habilitación es fundamental, pero mientras tanto, debemos ponernos rápidamente de acuerdo con el alcance de la "codificación segura", y lo que debemos esperar de un desarrollador con conocimientos de seguridad.
Tenemos que desmitificar la seguridad en el mundo de los desarrolladores.
La ciberseguridad es una bestia multifacética y difícil de manejar en el mejor de los casos, y aunque la codificación segura representa sólo una parte del panorama general, es un engranaje complejo del sistema que requiere atención especializada.
La encuesta reveló que el concepto de trabajar con código seguro estaba bastante aislado para el desarrollador medio, y que su alcance se limitaba a menudo a una sola categoría, en contraposición a una visión holística de los fundamentos y más allá. Los desarrolladores indicaron una dependencia en el uso de código existente (o pre-aprobado), en lugar de la práctica de escribir nuevo código que esté libre de vulnerabilidades. Mientras que la concienciación sobre la seguridad en relación con los componentes de terceros (especialmente la aplicación de parches, y la debacle de Log4Shell es un gran ejemplo: El 30% de las instancias siguen sin parchear desde diciembre) es muy importante, al igual que probar el código existente, éstos por sí solos no cumplen con un nivel funcional de capacidad de codificación segura.
Las vulnerabilidades a nivel de código son introducidas por desarrolladores que han aprendido malos patrones de codificación, y la falta de énfasis en la escritura de código seguro en sus KPI (junto con una cultura de seguridad mediocre) sólo refuerza esto como un estándar aceptable.
Los responsables de la seguridad pueden contribuir en gran medida a mejorar la concienciación inicial y a identificar las áreas con mayores lagunas de conocimiento, asegurándose en primer lugar de que se muestra a la cohorte de desarrollo la imagen completa de lo que implica la codificación segura. Probar y escanear el código preaprobado es una función, pero la reducción de las vulnerabilidades requiere una formación práctica en patrones de codificación buenos y seguros, en los lenguajes y marcos que se utilizan activamente.
El contexto es vital en la capacitación de los desarrolladores, y es necesario que se les haga partícipes del viaje cuando se trata de los objetivos de seguridad de la empresa.
Muchas organizaciones necesitan actualizar sus programas de seguridad.
Con la explosión de la tecnología impulsada por el software, que ha dado paso al rápido crecimiento de los incidentes de ciberseguridad en la última década, todos nos esforzamos por seguir el ritmo de los actores de las amenazas que trabajan sin descanso para descubrir explotaciones en sistemas valiosos.
La metodología DevSecOps se basa en la idea de que todo el mundo comparte la responsabilidad de la seguridad, incluidos los desarrolladores, y es una consideración principal desde el principio del SDLC. El problema es que, especialmente en las grandes empresas, pueden estar muy lejos de implementar DevSecOps como un estándar. En 2017, un estudio del Project Management Institute mostraba que el 51% de las organizaciones seguían utilizando Waterfall para su desarrollo de software. Ese estudio tiene ahora cinco años, pero conociendo lo graduales que pueden ser los cambios en las grandes empresas, es poco probable que haya habido una transición brusca a las últimas metodologías orientadas a la seguridad. Estos procesos heredados pueden suponer una ardua batalla para los profesionales de la seguridad que intentan cubrir todas las bases con una estrategia integral de protección contra las ciberamenazas, y adaptar a los desarrolladores y sus necesidades a este panorama es todo un reto.
Sin embargo, no podemos utilizar esto como excusa. Los profesionales de la seguridad en la empresa pueden utilizar a los desarrolladores en una estrategia mejorada; sólo tienen que familiarizarse con sus necesidades y considerarlos como parte de su juego defensivo. Necesitan una formación exhaustiva, y cualquier responsabilidad en materia de seguridad debe aplicarse con respecto a su pila tecnológica y su flujo de trabajo.
Codificación segura = la cesta "demasiado difícil"?
La investigación de Evans Data sacó a la luz que un asombroso 86% de los desarrolladores encuentran difícil practicar la codificación segura, y el 92% de los directores de desarrollo también admitieron que sus equipos necesitaban más formación en marcos de seguridad. Lo más preocupante es que el 48% de los encuestados admite que deja a sabiendas vulnerabilidades en su código.
Esto dibuja un panorama muy preocupante. Parece que, en general, los desarrolladores no reciben una formación frecuente y adecuada, ni están suficientemente expuestos a las buenas prácticas de seguridad e higiene. Al leer entre líneas, se refuerza el quid de la cuestión: simplemente no es una prioridad para los desarrolladores tener en cuenta la seguridad en su trabajo. Eso, y que la formación que reciben no fomenta su confianza ni sus habilidades prácticas, ni les ayuda a entender el impacto de su decisión de enviar código vulnerable.
El ataque al ransomware de Colonial Pipeline fue uno de los incidentes de seguridad de la cadena de suministro más perturbadores del año pasado, y desató el temor de que la mitad del suministro de gas en la costa este de Estados Unidos quedara cortado durante un periodo indeterminado. Afortunadamente, volvieron a funcionar rápidamente, pero no sin una gran aprensión en la comunidad. Fue uno de esos momentos cruciales en los que el público en general se enfrentó a la posibilidad de que un incidente cibernético afectara gravemente a un elemento del mundo físico que no se considera necesariamente como impulsado por el software, o un riesgo para un ciberataque. Y todo ese caos fue posible gracias a dos antiguas vulnerabilidades sin parchear, una de las cuales era la insidiosa, aunque ampliamente conocida, inyección SQL. Si los desarrolladores supieran lo que realmente está en juego cuando deciden enviar código vulnerable, verían rápidamente que no hay ningún escenario en el que eso sea un riesgo comercial aceptable.
El "P-P-T" funcional no depende del promotor.
El famoso "triángulo de oro" formado por las personas, los procesos y las herramientas no es posible sin una estrategia cuidadosamente estudiada, y los desarrolladores no están en condiciones de asimilarse a un proceso de seguridad que funcione sin tener en cuenta sus necesidades y desafíos.
Se necesitará un cambio de cultura considerable para mejorar la seguridad impulsada por los desarrolladores, y esto comienza con vías educativas que lleven tanto a los ingenieros como al equipo de seguridad a una mayor claridad.


La percepción de lo que constituye el acto de codificar de forma segura es objeto de debate. Según una reciente investigación realizada en colaboración con Evans Data, este sentimiento se ha puesto negro sobre blanco. La encuesta State of Developer-Driven Security 2022 ahonda en las principales percepciones y experiencias de 1200 desarrolladores activos, iluminando sus actitudes y desafíos en el ámbito de la seguridad.
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 apareció en TechRepublic. Se ha actualizado y sindicado aquí.
La creación de un entorno en el que los objetivos del equipo de seguridad y sus homólogos de desarrollo estén alineados ha sido una batalla ardua, aunque esencial. Nos queda un largo camino por recorrer, pero los obstáculos que se interponen en el camino de la sinergia necesaria para abrir la puerta a la responsabilidad compartida de la seguridad del software son cada vez más claros. Las empresas inteligentes quieren evolucionar su estrategia para evitar esos escollos, encontrar un camino productivo hacia adelante y utilizar DevSecOps en todo su potencial.
Lo que no había previsto es que la percepción de lo que constituye el acto de codificación segura es objeto de debate. Según una nueva investigación realizada en colaboración con Evans Data, este sentimiento se puso en blanco y negro. La encuesta State of Developer-Driven Security 2022 profundiza en las ideas y experiencias clave de 1.200 desarrolladores activos, iluminando sus actitudes y desafíos en el ámbito de la seguridad.
Una de las conclusiones más destacadas fue que sólo el 14% de los desarrolladores consideran la seguridad una prioridad a la hora de codificar. Si bien esto demuestra que hay un enorme margen de mejora, confirma lo que ya sabíamos: la creación de características es el rey en el mundo de los desarrolladores, y siguen estando mal equipados para hacer de la seguridad parte de su ADN. Sin embargo, cuando se combina con los datos sobre las definiciones de los desarrolladores de lo que significa para ellos la codificación segura, es motivo de preocupación.
Estas percepciones son impulsadas por la experiencia de los desarrolladores en su día a día, y habla del entorno de muchas organizaciones, que es que los desarrolladores simplemente no son un punto focal en la lucha contra las vulnerabilidades comunes. Su habilitación es fundamental, pero mientras tanto, debemos ponernos rápidamente de acuerdo con el alcance de la "codificación segura", y lo que debemos esperar de un desarrollador con conocimientos de seguridad.
Tenemos que desmitificar la seguridad en el mundo de los desarrolladores.
La ciberseguridad es una bestia multifacética y difícil de manejar en el mejor de los casos, y aunque la codificación segura representa sólo una parte del panorama general, es un engranaje complejo del sistema que requiere atención especializada.
La encuesta reveló que el concepto de trabajar con código seguro estaba bastante aislado para el desarrollador medio, y que su alcance se limitaba a menudo a una sola categoría, en contraposición a una visión holística de los fundamentos y más allá. Los desarrolladores indicaron una dependencia en el uso de código existente (o pre-aprobado), en lugar de la práctica de escribir nuevo código que esté libre de vulnerabilidades. Mientras que la concienciación sobre la seguridad en relación con los componentes de terceros (especialmente la aplicación de parches, y la debacle de Log4Shell es un gran ejemplo: El 30% de las instancias siguen sin parchear desde diciembre) es muy importante, al igual que probar el código existente, éstos por sí solos no cumplen con un nivel funcional de capacidad de codificación segura.
Las vulnerabilidades a nivel de código son introducidas por desarrolladores que han aprendido malos patrones de codificación, y la falta de énfasis en la escritura de código seguro en sus KPI (junto con una cultura de seguridad mediocre) sólo refuerza esto como un estándar aceptable.
Los responsables de la seguridad pueden contribuir en gran medida a mejorar la concienciación inicial y a identificar las áreas con mayores lagunas de conocimiento, asegurándose en primer lugar de que se muestra a la cohorte de desarrollo la imagen completa de lo que implica la codificación segura. Probar y escanear el código preaprobado es una función, pero la reducción de las vulnerabilidades requiere una formación práctica en patrones de codificación buenos y seguros, en los lenguajes y marcos que se utilizan activamente.
El contexto es vital en la capacitación de los desarrolladores, y es necesario que se les haga partícipes del viaje cuando se trata de los objetivos de seguridad de la empresa.
Muchas organizaciones necesitan actualizar sus programas de seguridad.
Con la explosión de la tecnología impulsada por el software, que ha dado paso al rápido crecimiento de los incidentes de ciberseguridad en la última década, todos nos esforzamos por seguir el ritmo de los actores de las amenazas que trabajan sin descanso para descubrir explotaciones en sistemas valiosos.
La metodología DevSecOps se basa en la idea de que todo el mundo comparte la responsabilidad de la seguridad, incluidos los desarrolladores, y es una consideración principal desde el principio del SDLC. El problema es que, especialmente en las grandes empresas, pueden estar muy lejos de implementar DevSecOps como un estándar. En 2017, un estudio del Project Management Institute mostraba que el 51% de las organizaciones seguían utilizando Waterfall para su desarrollo de software. Ese estudio tiene ahora cinco años, pero conociendo lo graduales que pueden ser los cambios en las grandes empresas, es poco probable que haya habido una transición brusca a las últimas metodologías orientadas a la seguridad. Estos procesos heredados pueden suponer una ardua batalla para los profesionales de la seguridad que intentan cubrir todas las bases con una estrategia integral de protección contra las ciberamenazas, y adaptar a los desarrolladores y sus necesidades a este panorama es todo un reto.
Sin embargo, no podemos utilizar esto como excusa. Los profesionales de la seguridad en la empresa pueden utilizar a los desarrolladores en una estrategia mejorada; sólo tienen que familiarizarse con sus necesidades y considerarlos como parte de su juego defensivo. Necesitan una formación exhaustiva, y cualquier responsabilidad en materia de seguridad debe aplicarse con respecto a su pila tecnológica y su flujo de trabajo.
Codificación segura = la cesta "demasiado difícil"?
La investigación de Evans Data sacó a la luz que un asombroso 86% de los desarrolladores encuentran difícil practicar la codificación segura, y el 92% de los directores de desarrollo también admitieron que sus equipos necesitaban más formación en marcos de seguridad. Lo más preocupante es que el 48% de los encuestados admite que deja a sabiendas vulnerabilidades en su código.
Esto dibuja un panorama muy preocupante. Parece que, en general, los desarrolladores no reciben una formación frecuente y adecuada, ni están suficientemente expuestos a las buenas prácticas de seguridad e higiene. Al leer entre líneas, se refuerza el quid de la cuestión: simplemente no es una prioridad para los desarrolladores tener en cuenta la seguridad en su trabajo. Eso, y que la formación que reciben no fomenta su confianza ni sus habilidades prácticas, ni les ayuda a entender el impacto de su decisión de enviar código vulnerable.
El ataque al ransomware de Colonial Pipeline fue uno de los incidentes de seguridad de la cadena de suministro más perturbadores del año pasado, y desató el temor de que la mitad del suministro de gas en la costa este de Estados Unidos quedara cortado durante un periodo indeterminado. Afortunadamente, volvieron a funcionar rápidamente, pero no sin una gran aprensión en la comunidad. Fue uno de esos momentos cruciales en los que el público en general se enfrentó a la posibilidad de que un incidente cibernético afectara gravemente a un elemento del mundo físico que no se considera necesariamente como impulsado por el software, o un riesgo para un ciberataque. Y todo ese caos fue posible gracias a dos antiguas vulnerabilidades sin parchear, una de las cuales era la insidiosa, aunque ampliamente conocida, inyección SQL. Si los desarrolladores supieran lo que realmente está en juego cuando deciden enviar código vulnerable, verían rápidamente que no hay ningún escenario en el que eso sea un riesgo comercial aceptable.
El "P-P-T" funcional no depende del promotor.
El famoso "triángulo de oro" formado por las personas, los procesos y las herramientas no es posible sin una estrategia cuidadosamente estudiada, y los desarrolladores no están en condiciones de asimilarse a un proceso de seguridad que funcione sin tener en cuenta sus necesidades y desafíos.
Se necesitará un cambio de cultura considerable para mejorar la seguridad impulsada por los desarrolladores, y esto comienza con vías educativas que lleven tanto a los ingenieros como al equipo de seguridad a una mayor claridad.

Una versión de este artículo apareció en TechRepublic. Se ha actualizado y sindicado aquí.
La creación de un entorno en el que los objetivos del equipo de seguridad y sus homólogos de desarrollo estén alineados ha sido una batalla ardua, aunque esencial. Nos queda un largo camino por recorrer, pero los obstáculos que se interponen en el camino de la sinergia necesaria para abrir la puerta a la responsabilidad compartida de la seguridad del software son cada vez más claros. Las empresas inteligentes quieren evolucionar su estrategia para evitar esos escollos, encontrar un camino productivo hacia adelante y utilizar DevSecOps en todo su potencial.
Lo que no había previsto es que la percepción de lo que constituye el acto de codificación segura es objeto de debate. Según una nueva investigación realizada en colaboración con Evans Data, este sentimiento se puso en blanco y negro. La encuesta State of Developer-Driven Security 2022 profundiza en las ideas y experiencias clave de 1.200 desarrolladores activos, iluminando sus actitudes y desafíos en el ámbito de la seguridad.
Una de las conclusiones más destacadas fue que sólo el 14% de los desarrolladores consideran la seguridad una prioridad a la hora de codificar. Si bien esto demuestra que hay un enorme margen de mejora, confirma lo que ya sabíamos: la creación de características es el rey en el mundo de los desarrolladores, y siguen estando mal equipados para hacer de la seguridad parte de su ADN. Sin embargo, cuando se combina con los datos sobre las definiciones de los desarrolladores de lo que significa para ellos la codificación segura, es motivo de preocupación.
Estas percepciones son impulsadas por la experiencia de los desarrolladores en su día a día, y habla del entorno de muchas organizaciones, que es que los desarrolladores simplemente no son un punto focal en la lucha contra las vulnerabilidades comunes. Su habilitación es fundamental, pero mientras tanto, debemos ponernos rápidamente de acuerdo con el alcance de la "codificación segura", y lo que debemos esperar de un desarrollador con conocimientos de seguridad.
Tenemos que desmitificar la seguridad en el mundo de los desarrolladores.
La ciberseguridad es una bestia multifacética y difícil de manejar en el mejor de los casos, y aunque la codificación segura representa sólo una parte del panorama general, es un engranaje complejo del sistema que requiere atención especializada.
La encuesta reveló que el concepto de trabajar con código seguro estaba bastante aislado para el desarrollador medio, y que su alcance se limitaba a menudo a una sola categoría, en contraposición a una visión holística de los fundamentos y más allá. Los desarrolladores indicaron una dependencia en el uso de código existente (o pre-aprobado), en lugar de la práctica de escribir nuevo código que esté libre de vulnerabilidades. Mientras que la concienciación sobre la seguridad en relación con los componentes de terceros (especialmente la aplicación de parches, y la debacle de Log4Shell es un gran ejemplo: El 30% de las instancias siguen sin parchear desde diciembre) es muy importante, al igual que probar el código existente, éstos por sí solos no cumplen con un nivel funcional de capacidad de codificación segura.
Las vulnerabilidades a nivel de código son introducidas por desarrolladores que han aprendido malos patrones de codificación, y la falta de énfasis en la escritura de código seguro en sus KPI (junto con una cultura de seguridad mediocre) sólo refuerza esto como un estándar aceptable.
Los responsables de la seguridad pueden contribuir en gran medida a mejorar la concienciación inicial y a identificar las áreas con mayores lagunas de conocimiento, asegurándose en primer lugar de que se muestra a la cohorte de desarrollo la imagen completa de lo que implica la codificación segura. Probar y escanear el código preaprobado es una función, pero la reducción de las vulnerabilidades requiere una formación práctica en patrones de codificación buenos y seguros, en los lenguajes y marcos que se utilizan activamente.
El contexto es vital en la capacitación de los desarrolladores, y es necesario que se les haga partícipes del viaje cuando se trata de los objetivos de seguridad de la empresa.
Muchas organizaciones necesitan actualizar sus programas de seguridad.
Con la explosión de la tecnología impulsada por el software, que ha dado paso al rápido crecimiento de los incidentes de ciberseguridad en la última década, todos nos esforzamos por seguir el ritmo de los actores de las amenazas que trabajan sin descanso para descubrir explotaciones en sistemas valiosos.
La metodología DevSecOps se basa en la idea de que todo el mundo comparte la responsabilidad de la seguridad, incluidos los desarrolladores, y es una consideración principal desde el principio del SDLC. El problema es que, especialmente en las grandes empresas, pueden estar muy lejos de implementar DevSecOps como un estándar. En 2017, un estudio del Project Management Institute mostraba que el 51% de las organizaciones seguían utilizando Waterfall para su desarrollo de software. Ese estudio tiene ahora cinco años, pero conociendo lo graduales que pueden ser los cambios en las grandes empresas, es poco probable que haya habido una transición brusca a las últimas metodologías orientadas a la seguridad. Estos procesos heredados pueden suponer una ardua batalla para los profesionales de la seguridad que intentan cubrir todas las bases con una estrategia integral de protección contra las ciberamenazas, y adaptar a los desarrolladores y sus necesidades a este panorama es todo un reto.
Sin embargo, no podemos utilizar esto como excusa. Los profesionales de la seguridad en la empresa pueden utilizar a los desarrolladores en una estrategia mejorada; sólo tienen que familiarizarse con sus necesidades y considerarlos como parte de su juego defensivo. Necesitan una formación exhaustiva, y cualquier responsabilidad en materia de seguridad debe aplicarse con respecto a su pila tecnológica y su flujo de trabajo.
Codificación segura = la cesta "demasiado difícil"?
La investigación de Evans Data sacó a la luz que un asombroso 86% de los desarrolladores encuentran difícil practicar la codificación segura, y el 92% de los directores de desarrollo también admitieron que sus equipos necesitaban más formación en marcos de seguridad. Lo más preocupante es que el 48% de los encuestados admite que deja a sabiendas vulnerabilidades en su código.
Esto dibuja un panorama muy preocupante. Parece que, en general, los desarrolladores no reciben una formación frecuente y adecuada, ni están suficientemente expuestos a las buenas prácticas de seguridad e higiene. Al leer entre líneas, se refuerza el quid de la cuestión: simplemente no es una prioridad para los desarrolladores tener en cuenta la seguridad en su trabajo. Eso, y que la formación que reciben no fomenta su confianza ni sus habilidades prácticas, ni les ayuda a entender el impacto de su decisión de enviar código vulnerable.
El ataque al ransomware de Colonial Pipeline fue uno de los incidentes de seguridad de la cadena de suministro más perturbadores del año pasado, y desató el temor de que la mitad del suministro de gas en la costa este de Estados Unidos quedara cortado durante un periodo indeterminado. Afortunadamente, volvieron a funcionar rápidamente, pero no sin una gran aprensión en la comunidad. Fue uno de esos momentos cruciales en los que el público en general se enfrentó a la posibilidad de que un incidente cibernético afectara gravemente a un elemento del mundo físico que no se considera necesariamente como impulsado por el software, o un riesgo para un ciberataque. Y todo ese caos fue posible gracias a dos antiguas vulnerabilidades sin parchear, una de las cuales era la insidiosa, aunque ampliamente conocida, inyección SQL. Si los desarrolladores supieran lo que realmente está en juego cuando deciden enviar código vulnerable, verían rápidamente que no hay ningún escenario en el que eso sea un riesgo comercial aceptable.
El "P-P-T" funcional no depende del promotor.
El famoso "triángulo de oro" formado por las personas, los procesos y las herramientas no es posible sin una estrategia cuidadosamente estudiada, y los desarrolladores no están en condiciones de asimilarse a un proceso de seguridad que funcione sin tener en cuenta sus necesidades y desafíos.
Se necesitará un cambio de cultura considerable para mejorar la seguridad impulsada por los desarrolladores, y esto comienza con vías educativas que lleven tanto a los ingenieros como al equipo de seguridad a una mayor claridad.

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 apareció en TechRepublic. Se ha actualizado y sindicado aquí.
La creación de un entorno en el que los objetivos del equipo de seguridad y sus homólogos de desarrollo estén alineados ha sido una batalla ardua, aunque esencial. Nos queda un largo camino por recorrer, pero los obstáculos que se interponen en el camino de la sinergia necesaria para abrir la puerta a la responsabilidad compartida de la seguridad del software son cada vez más claros. Las empresas inteligentes quieren evolucionar su estrategia para evitar esos escollos, encontrar un camino productivo hacia adelante y utilizar DevSecOps en todo su potencial.
Lo que no había previsto es que la percepción de lo que constituye el acto de codificación segura es objeto de debate. Según una nueva investigación realizada en colaboración con Evans Data, este sentimiento se puso en blanco y negro. La encuesta State of Developer-Driven Security 2022 profundiza en las ideas y experiencias clave de 1.200 desarrolladores activos, iluminando sus actitudes y desafíos en el ámbito de la seguridad.
Una de las conclusiones más destacadas fue que sólo el 14% de los desarrolladores consideran la seguridad una prioridad a la hora de codificar. Si bien esto demuestra que hay un enorme margen de mejora, confirma lo que ya sabíamos: la creación de características es el rey en el mundo de los desarrolladores, y siguen estando mal equipados para hacer de la seguridad parte de su ADN. Sin embargo, cuando se combina con los datos sobre las definiciones de los desarrolladores de lo que significa para ellos la codificación segura, es motivo de preocupación.
Estas percepciones son impulsadas por la experiencia de los desarrolladores en su día a día, y habla del entorno de muchas organizaciones, que es que los desarrolladores simplemente no son un punto focal en la lucha contra las vulnerabilidades comunes. Su habilitación es fundamental, pero mientras tanto, debemos ponernos rápidamente de acuerdo con el alcance de la "codificación segura", y lo que debemos esperar de un desarrollador con conocimientos de seguridad.
Tenemos que desmitificar la seguridad en el mundo de los desarrolladores.
La ciberseguridad es una bestia multifacética y difícil de manejar en el mejor de los casos, y aunque la codificación segura representa sólo una parte del panorama general, es un engranaje complejo del sistema que requiere atención especializada.
La encuesta reveló que el concepto de trabajar con código seguro estaba bastante aislado para el desarrollador medio, y que su alcance se limitaba a menudo a una sola categoría, en contraposición a una visión holística de los fundamentos y más allá. Los desarrolladores indicaron una dependencia en el uso de código existente (o pre-aprobado), en lugar de la práctica de escribir nuevo código que esté libre de vulnerabilidades. Mientras que la concienciación sobre la seguridad en relación con los componentes de terceros (especialmente la aplicación de parches, y la debacle de Log4Shell es un gran ejemplo: El 30% de las instancias siguen sin parchear desde diciembre) es muy importante, al igual que probar el código existente, éstos por sí solos no cumplen con un nivel funcional de capacidad de codificación segura.
Las vulnerabilidades a nivel de código son introducidas por desarrolladores que han aprendido malos patrones de codificación, y la falta de énfasis en la escritura de código seguro en sus KPI (junto con una cultura de seguridad mediocre) sólo refuerza esto como un estándar aceptable.
Los responsables de la seguridad pueden contribuir en gran medida a mejorar la concienciación inicial y a identificar las áreas con mayores lagunas de conocimiento, asegurándose en primer lugar de que se muestra a la cohorte de desarrollo la imagen completa de lo que implica la codificación segura. Probar y escanear el código preaprobado es una función, pero la reducción de las vulnerabilidades requiere una formación práctica en patrones de codificación buenos y seguros, en los lenguajes y marcos que se utilizan activamente.
El contexto es vital en la capacitación de los desarrolladores, y es necesario que se les haga partícipes del viaje cuando se trata de los objetivos de seguridad de la empresa.
Muchas organizaciones necesitan actualizar sus programas de seguridad.
Con la explosión de la tecnología impulsada por el software, que ha dado paso al rápido crecimiento de los incidentes de ciberseguridad en la última década, todos nos esforzamos por seguir el ritmo de los actores de las amenazas que trabajan sin descanso para descubrir explotaciones en sistemas valiosos.
La metodología DevSecOps se basa en la idea de que todo el mundo comparte la responsabilidad de la seguridad, incluidos los desarrolladores, y es una consideración principal desde el principio del SDLC. El problema es que, especialmente en las grandes empresas, pueden estar muy lejos de implementar DevSecOps como un estándar. En 2017, un estudio del Project Management Institute mostraba que el 51% de las organizaciones seguían utilizando Waterfall para su desarrollo de software. Ese estudio tiene ahora cinco años, pero conociendo lo graduales que pueden ser los cambios en las grandes empresas, es poco probable que haya habido una transición brusca a las últimas metodologías orientadas a la seguridad. Estos procesos heredados pueden suponer una ardua batalla para los profesionales de la seguridad que intentan cubrir todas las bases con una estrategia integral de protección contra las ciberamenazas, y adaptar a los desarrolladores y sus necesidades a este panorama es todo un reto.
Sin embargo, no podemos utilizar esto como excusa. Los profesionales de la seguridad en la empresa pueden utilizar a los desarrolladores en una estrategia mejorada; sólo tienen que familiarizarse con sus necesidades y considerarlos como parte de su juego defensivo. Necesitan una formación exhaustiva, y cualquier responsabilidad en materia de seguridad debe aplicarse con respecto a su pila tecnológica y su flujo de trabajo.
Codificación segura = la cesta "demasiado difícil"?
La investigación de Evans Data sacó a la luz que un asombroso 86% de los desarrolladores encuentran difícil practicar la codificación segura, y el 92% de los directores de desarrollo también admitieron que sus equipos necesitaban más formación en marcos de seguridad. Lo más preocupante es que el 48% de los encuestados admite que deja a sabiendas vulnerabilidades en su código.
Esto dibuja un panorama muy preocupante. Parece que, en general, los desarrolladores no reciben una formación frecuente y adecuada, ni están suficientemente expuestos a las buenas prácticas de seguridad e higiene. Al leer entre líneas, se refuerza el quid de la cuestión: simplemente no es una prioridad para los desarrolladores tener en cuenta la seguridad en su trabajo. Eso, y que la formación que reciben no fomenta su confianza ni sus habilidades prácticas, ni les ayuda a entender el impacto de su decisión de enviar código vulnerable.
El ataque al ransomware de Colonial Pipeline fue uno de los incidentes de seguridad de la cadena de suministro más perturbadores del año pasado, y desató el temor de que la mitad del suministro de gas en la costa este de Estados Unidos quedara cortado durante un periodo indeterminado. Afortunadamente, volvieron a funcionar rápidamente, pero no sin una gran aprensión en la comunidad. Fue uno de esos momentos cruciales en los que el público en general se enfrentó a la posibilidad de que un incidente cibernético afectara gravemente a un elemento del mundo físico que no se considera necesariamente como impulsado por el software, o un riesgo para un ciberataque. Y todo ese caos fue posible gracias a dos antiguas vulnerabilidades sin parchear, una de las cuales era la insidiosa, aunque ampliamente conocida, inyección SQL. Si los desarrolladores supieran lo que realmente está en juego cuando deciden enviar código vulnerable, verían rápidamente que no hay ningún escenario en el que eso sea un riesgo comercial aceptable.
El "P-P-T" funcional no depende del promotor.
El famoso "triángulo de oro" formado por las personas, los procesos y las herramientas no es posible sin una estrategia cuidadosamente estudiada, y los desarrolladores no están en condiciones de asimilarse a un proceso de seguridad que funcione sin tener en cuenta sus necesidades y desafíos.
Se necesitará un cambio de cultura considerable para mejorar la seguridad impulsada por los desarrolladores, y esto comienza con vías educativas que lleven tanto a los ingenieros como al equipo de seguridad a una mayor claridad.
Í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
Temas y contenidos de la formación sobre código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Temas que cubren todo, desde IA a XQuery Injection, ofrecidos para una variedad de roles desde Arquitectos e Ingenieros a Product Managers y QA. Eche un vistazo a lo que ofrece nuestro catálogo de contenidos por tema y función.
Búsqueda: Aprendizaje líder en la industria para mantener a los desarrolladores por delante mitigando el riesgo.
Quests es una learning platform que ayuda a los desarrolladores a mitigar los riesgos de seguridad del software mediante la mejora de sus habilidades de codificación segura. Con rutas de aprendizaje curadas, desafíos prácticos y actividades interactivas, capacita a los desarrolladores para identificar y prevenir vulnerabilidades.
La potencia de OpenText Fortify + Secure Code Warrior
OpenText Fortify y Secure Code Warrior unen sus fuerzas para ayudar a las empresas a reducir riesgos, transformar a los desarrolladores en campeones de la seguridad y fomentar la confianza de los clientes. Más información aquí.
Recursos para empezar
Inyección indirecta y riesgos de seguridad de las herramientas de codificación agéntica
Cómo se engañó a un agente de codificación para que escribiera código propenso a inyecciones SQL, instalara herramientas de shell y tal vez incluso acechara a su usuario.
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.
10 predicciones clave: Secure Code Warrior sobre la influencia de la IA y el diseño seguro en 2025
Las organizaciones se enfrentan a decisiones difíciles sobre el uso de la IA para apoyar la productividad a largo plazo, la sostenibilidad y el retorno de la inversión en seguridad. En los últimos años nos ha quedado claro que la IA nunca sustituirá por completo el papel del desarrollador. Desde las asociaciones entre IA y desarrolladores hasta las crecientes presiones (y confusión) en torno a las expectativas de seguridad por diseño, echemos un vistazo más de cerca a lo que podemos esperar durante el próximo año.