El cumplimiento de FinServ depende de la seguridad del software
Las instituciones de servicios financieros tienen razones de peso para asegurarse de que el código de software que utilizan es seguro. Una motivación obvia, por supuesto, es la necesidad de proteger sus datos de una violación, que puede ser costosa en términos de información personal filtrada, gastos de limpieza, multas y restitución, y daños a la reputación de una organización. Otro motivo constante es la necesidad de cumplir toda una serie de normativas industriales y gubernamentales.
Como manejan tanta información sensible, personal y financiera, así como el dinero de la gente, los servicios financieros son un sector muy regulado. Dependiendo de los servicios que presten, las empresas deben cumplir una mezcla de normas y requisitos.
La Payment Card Industry Data Security Standard (PCI DSS) es bien conocida por sus normas de protección de datos de titulares de tarjetas, por ejemplo. Los requisitos de la Ley Sarbanes-Oxely regulan la gestión de los registros financieros. Las empresas que operan a escala internacional están familiarizadas con la Digital Operational Resilience Act (DORA), que es un marco vinculante de gestión de riesgos, y las normas mundiales para transferencias de fondos establecidas por la Society for Worldwide Interbank Financial Telecommunication, conocida como Swift.
Y leyes como la Ley de Privacidad del Consumidor de California (CCPA) y el Reglamento General de Protección de Datos (GDPR) de la UE establecen requisitos para proteger la privacidad y la información personal de los clientes. Hay otras, como las normativas establecidas por la Oficina del Interventor de la Moneda (OCC) de Estados Unidos y el Banco Central Europeo (BCE).
Por si fuera poco, la Estrategia Nacional de Ciberseguridad establece, entre otras cosas, que los fabricantes de software deben ser considerados responsables de la seguridad ineficaz de los programas informáticos. Y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), junto con 17 socios estadounidenses e internacionales, ha publicado orientaciones sobre los principios de Secure-By-Design para el desarrollo de software.
Un hilo común para las empresas de servicios financieros es que el código seguro es un elemento crítico para ayudar a cumplir los objetivos de esas normativas que pueden facilitar la demostración de su cumplimiento. Y subraya por qué los desarrolladores necesitan formación y actualización para garantizar que la seguridad se aplica al código desde el principio del proceso de desarrollo.
Como ejemplo de cómo funciona, veamos la versión más reciente de PCI DSS.
La codificación segura (y la formación de los desarrolladores) es el núcleo de PCI DSS 4.0
La norma PCI DSS 4.0, que será obligatoria a partir del 1 de abril de 2024, incluye varias actualizaciones sustanciales con respecto a la norma PCI DSS 3.2.1, entre las que destaca el énfasis en el papel que desempeñan los desarrolladores a la hora de garantizar la seguridad del código de software.
La PCI reconoció hace tiempo la importancia del software seguro. La versión 2.0, que se publicó en 2017, incluía orientaciones para desarrolladores sobre cómo garantizar transacciones seguras en dispositivos móviles. Las directrices de la versión 4.0 hacen ahora hincapié en la aplicación de las mejores prácticas de seguridad al desarrollo de software e incluyen algunas orientaciones específicas sobre la formación de los desarrolladores.
Los requisitos suelen establecerse a grandes rasgos, aunque las empresas pueden querer aplicar un enfoque más exhaustivo.
Por ejemplo, un requisito de la versión 4.0 afirma que "se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros". Una buena forma de asegurarse de que esto es así es que los desarrolladores reciban una formación precisa en los lenguajes de programación y marcos de trabajo que utilizan, con el fin de colmar cualquier laguna de conocimientos.
Otro requisito establece que los desarrolladores que trabajen con software a medida y personalizado deben recibir formación al menos una vez cada 12 meses, que cubra:
- Seguridad del software pertinente para su función laboral y lenguajes de desarrollo.
- Diseño de software seguro y técnicas de codificación.
- Cómo utilizar las herramientas de pruebas de seguridad -si se utilizan- para detectar vulnerabilidades en el software.
Pero, en realidad, una vez al año no es suficiente para abordar los principales problemas de seguridad y acabar con los malos hábitos de codificación. La formación debe ser continua y mesurada, con un proceso de verificación de las competencias para garantizar que se hace un buen uso de ella.
PCI DSS 4.0 incluye más de media docena de otros requisitos que abordan áreas como la prevención y mitigación de diversos tipos de ataques, la documentación de componentes de software de terceros, la identificación y gestión de vulnerabilidades y otras medidas de seguridad. En todos los casos, las organizaciones harían bien en aplicar a fondo esas medidas. La formación sobre vectores de ataque debe ser frecuente, no anual. Los componentes de terceros, que suelen ser una fuente de vulnerabilidades, deben inventariarse cuidadosamente mediante un programa de lista de materiales de software (SBOM). Y las organizaciones deben asegurarse de tener funciones claramente definidas para gestionar las vulnerabilidades.
La nueva versión también ofrece a las organizaciones cierta flexibilidad a la hora de cumplir sus requisitos, centrándose en los resultados más que en marcar casillas, al tiempo que añade nuevos requisitos para los controles de autenticación, la longitud de las contraseñas, las cuentas compartidas y otros factores.
La conformidad comienza al principio del SDLC
Lo que estas normativas tienen en común es que intentan establecer normas estrictas para proteger los datos y las transacciones en el sector de los servicios financieros. Y, como en el caso de la última versión de la PCI DSS, hacen cada vez más hincapié en la importancia de un código seguro al principio del ciclo de vida de desarrollo del software (SDLC). La Estrategia Nacional de Ciberseguridad y los principios Secure by Design de CISA también responsabilizan de la seguridad a los creadores de software -antes de que se distribuya-, de modo que incluso las empresas que no se rigen directamente por la normativa de servicios financieros deben cumplirla.
Las organizaciones necesitan salvar la brecha que existe entre los equipos DevOps (que se centran en la velocidad de desarrollo) y los equipos AppSec (que se apresuran a introducir la seguridad en el proceso) formando a los desarrolladores para que la seguridad sea inherente a su enfoque. Sin embargo, esto requiere un complejo conjunto de habilidades que implican más de lo que pueden ofrecer las sesiones de formación anuales o los programas educativos estándar y estancados. La formación debe ser continua y ágil, diseñada para involucrar a los alumnos con escenarios activos del mundo real e impartida en pequeñas sesiones que se adapten a sus horarios de trabajo.
Las empresas de servicios financieros necesitan garantizar la seguridad tanto para protegerse contra las infracciones como para cumplir la normativa, cada vez más estricta. Los costes del incumplimiento pueden ser tan perjudiciales como una violación en términos de impacto en la reputación de una empresa y costes monetarios. El Informe de IBM sobre el coste de una violación de datos en 2023, por ejemplo, descubrió que las organizaciones con un alto nivel de incumplimiento se enfrentaban, de media, a multas y otros costes por un total de 5,05 millones de dólares, medio millón más que el coste medio de una violación de datos real.
El continuo crecimiento de los entornos basados en la nube y las transacciones digitales ha hecho que la seguridad del software en el sector de los servicios financieros sea de vital importancia, algo que reconocen normativas como PCI DSS. La mejor manera de garantizar un software seguro es mediante una codificación segura al inicio del SDLC. Y la forma de conseguirlo es formando eficazmente a los desarrolladores en prácticas de codificación segura.
Para obtener una visión completa de cómo la codificación segura puede ayudar a garantizar el éxito, la seguridad y los beneficios de las empresas de servicios financieros, puede leer el libro electrónico recién publicado Secure Code Warrior : La guía definitiva de las tendencias de seguridad en los servicios financieros.
Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas y saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.


Las normativas que regulan el sector de los servicios financieros, como la PCI DSS, insisten en la importancia de un código seguro y en la necesidad de formar a los desarrolladores en las mejores prácticas de seguridad.
Secure Code Warrior hace que la codificación segura sea una experiencia positiva y atractiva para los desarrolladores a medida que aumentan sus habilidades. Guiamos a cada programador a lo largo de su propio camino de aprendizaje, para que los desarrolladores con conocimientos de seguridad se conviertan en los superhéroes cotidianos de nuestro mundo conectado.

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ónSecure Code Warrior hace que la codificación segura sea una experiencia positiva y atractiva para los desarrolladores a medida que aumentan sus habilidades. Guiamos a cada programador a lo largo de su propio camino de aprendizaje, para que los desarrolladores con conocimientos de seguridad se conviertan en los superhéroes cotidianos de nuestro mundo conectado.
Este artículo fue escrito por Secure Code Warrior El equipo de expertos de la industria de está comprometido a brindar a los desarrolladores los conocimientos y las habilidades para crear software seguro desde el principio. Aprovechamos nuestra profunda experiencia en prácticas de codificación segura, tendencias de la industria y conocimientos del mundo real.


Las instituciones de servicios financieros tienen razones de peso para asegurarse de que el código de software que utilizan es seguro. Una motivación obvia, por supuesto, es la necesidad de proteger sus datos de una violación, que puede ser costosa en términos de información personal filtrada, gastos de limpieza, multas y restitución, y daños a la reputación de una organización. Otro motivo constante es la necesidad de cumplir toda una serie de normativas industriales y gubernamentales.
Como manejan tanta información sensible, personal y financiera, así como el dinero de la gente, los servicios financieros son un sector muy regulado. Dependiendo de los servicios que presten, las empresas deben cumplir una mezcla de normas y requisitos.
La Payment Card Industry Data Security Standard (PCI DSS) es bien conocida por sus normas de protección de datos de titulares de tarjetas, por ejemplo. Los requisitos de la Ley Sarbanes-Oxely regulan la gestión de los registros financieros. Las empresas que operan a escala internacional están familiarizadas con la Digital Operational Resilience Act (DORA), que es un marco vinculante de gestión de riesgos, y las normas mundiales para transferencias de fondos establecidas por la Society for Worldwide Interbank Financial Telecommunication, conocida como Swift.
Y leyes como la Ley de Privacidad del Consumidor de California (CCPA) y el Reglamento General de Protección de Datos (GDPR) de la UE establecen requisitos para proteger la privacidad y la información personal de los clientes. Hay otras, como las normativas establecidas por la Oficina del Interventor de la Moneda (OCC) de Estados Unidos y el Banco Central Europeo (BCE).
Por si fuera poco, la Estrategia Nacional de Ciberseguridad establece, entre otras cosas, que los fabricantes de software deben ser considerados responsables de la seguridad ineficaz de los programas informáticos. Y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), junto con 17 socios estadounidenses e internacionales, ha publicado orientaciones sobre los principios de Secure-By-Design para el desarrollo de software.
Un hilo común para las empresas de servicios financieros es que el código seguro es un elemento crítico para ayudar a cumplir los objetivos de esas normativas que pueden facilitar la demostración de su cumplimiento. Y subraya por qué los desarrolladores necesitan formación y actualización para garantizar que la seguridad se aplica al código desde el principio del proceso de desarrollo.
Como ejemplo de cómo funciona, veamos la versión más reciente de PCI DSS.
La codificación segura (y la formación de los desarrolladores) es el núcleo de PCI DSS 4.0
La norma PCI DSS 4.0, que será obligatoria a partir del 1 de abril de 2024, incluye varias actualizaciones sustanciales con respecto a la norma PCI DSS 3.2.1, entre las que destaca el énfasis en el papel que desempeñan los desarrolladores a la hora de garantizar la seguridad del código de software.
La PCI reconoció hace tiempo la importancia del software seguro. La versión 2.0, que se publicó en 2017, incluía orientaciones para desarrolladores sobre cómo garantizar transacciones seguras en dispositivos móviles. Las directrices de la versión 4.0 hacen ahora hincapié en la aplicación de las mejores prácticas de seguridad al desarrollo de software e incluyen algunas orientaciones específicas sobre la formación de los desarrolladores.
Los requisitos suelen establecerse a grandes rasgos, aunque las empresas pueden querer aplicar un enfoque más exhaustivo.
Por ejemplo, un requisito de la versión 4.0 afirma que "se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros". Una buena forma de asegurarse de que esto es así es que los desarrolladores reciban una formación precisa en los lenguajes de programación y marcos de trabajo que utilizan, con el fin de colmar cualquier laguna de conocimientos.
Otro requisito establece que los desarrolladores que trabajen con software a medida y personalizado deben recibir formación al menos una vez cada 12 meses, que cubra:
- Seguridad del software pertinente para su función laboral y lenguajes de desarrollo.
- Diseño de software seguro y técnicas de codificación.
- Cómo utilizar las herramientas de pruebas de seguridad -si se utilizan- para detectar vulnerabilidades en el software.
Pero, en realidad, una vez al año no es suficiente para abordar los principales problemas de seguridad y acabar con los malos hábitos de codificación. La formación debe ser continua y mesurada, con un proceso de verificación de las competencias para garantizar que se hace un buen uso de ella.
PCI DSS 4.0 incluye más de media docena de otros requisitos que abordan áreas como la prevención y mitigación de diversos tipos de ataques, la documentación de componentes de software de terceros, la identificación y gestión de vulnerabilidades y otras medidas de seguridad. En todos los casos, las organizaciones harían bien en aplicar a fondo esas medidas. La formación sobre vectores de ataque debe ser frecuente, no anual. Los componentes de terceros, que suelen ser una fuente de vulnerabilidades, deben inventariarse cuidadosamente mediante un programa de lista de materiales de software (SBOM). Y las organizaciones deben asegurarse de tener funciones claramente definidas para gestionar las vulnerabilidades.
La nueva versión también ofrece a las organizaciones cierta flexibilidad a la hora de cumplir sus requisitos, centrándose en los resultados más que en marcar casillas, al tiempo que añade nuevos requisitos para los controles de autenticación, la longitud de las contraseñas, las cuentas compartidas y otros factores.
La conformidad comienza al principio del SDLC
Lo que estas normativas tienen en común es que intentan establecer normas estrictas para proteger los datos y las transacciones en el sector de los servicios financieros. Y, como en el caso de la última versión de la PCI DSS, hacen cada vez más hincapié en la importancia de un código seguro al principio del ciclo de vida de desarrollo del software (SDLC). La Estrategia Nacional de Ciberseguridad y los principios Secure by Design de CISA también responsabilizan de la seguridad a los creadores de software -antes de que se distribuya-, de modo que incluso las empresas que no se rigen directamente por la normativa de servicios financieros deben cumplirla.
Las organizaciones necesitan salvar la brecha que existe entre los equipos DevOps (que se centran en la velocidad de desarrollo) y los equipos AppSec (que se apresuran a introducir la seguridad en el proceso) formando a los desarrolladores para que la seguridad sea inherente a su enfoque. Sin embargo, esto requiere un complejo conjunto de habilidades que implican más de lo que pueden ofrecer las sesiones de formación anuales o los programas educativos estándar y estancados. La formación debe ser continua y ágil, diseñada para involucrar a los alumnos con escenarios activos del mundo real e impartida en pequeñas sesiones que se adapten a sus horarios de trabajo.
Las empresas de servicios financieros necesitan garantizar la seguridad tanto para protegerse contra las infracciones como para cumplir la normativa, cada vez más estricta. Los costes del incumplimiento pueden ser tan perjudiciales como una violación en términos de impacto en la reputación de una empresa y costes monetarios. El Informe de IBM sobre el coste de una violación de datos en 2023, por ejemplo, descubrió que las organizaciones con un alto nivel de incumplimiento se enfrentaban, de media, a multas y otros costes por un total de 5,05 millones de dólares, medio millón más que el coste medio de una violación de datos real.
El continuo crecimiento de los entornos basados en la nube y las transacciones digitales ha hecho que la seguridad del software en el sector de los servicios financieros sea de vital importancia, algo que reconocen normativas como PCI DSS. La mejor manera de garantizar un software seguro es mediante una codificación segura al inicio del SDLC. Y la forma de conseguirlo es formando eficazmente a los desarrolladores en prácticas de codificación segura.
Para obtener una visión completa de cómo la codificación segura puede ayudar a garantizar el éxito, la seguridad y los beneficios de las empresas de servicios financieros, puede leer el libro electrónico recién publicado Secure Code Warrior : La guía definitiva de las tendencias de seguridad en los servicios financieros.
Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas y saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.

Las instituciones de servicios financieros tienen razones de peso para asegurarse de que el código de software que utilizan es seguro. Una motivación obvia, por supuesto, es la necesidad de proteger sus datos de una violación, que puede ser costosa en términos de información personal filtrada, gastos de limpieza, multas y restitución, y daños a la reputación de una organización. Otro motivo constante es la necesidad de cumplir toda una serie de normativas industriales y gubernamentales.
Como manejan tanta información sensible, personal y financiera, así como el dinero de la gente, los servicios financieros son un sector muy regulado. Dependiendo de los servicios que presten, las empresas deben cumplir una mezcla de normas y requisitos.
La Payment Card Industry Data Security Standard (PCI DSS) es bien conocida por sus normas de protección de datos de titulares de tarjetas, por ejemplo. Los requisitos de la Ley Sarbanes-Oxely regulan la gestión de los registros financieros. Las empresas que operan a escala internacional están familiarizadas con la Digital Operational Resilience Act (DORA), que es un marco vinculante de gestión de riesgos, y las normas mundiales para transferencias de fondos establecidas por la Society for Worldwide Interbank Financial Telecommunication, conocida como Swift.
Y leyes como la Ley de Privacidad del Consumidor de California (CCPA) y el Reglamento General de Protección de Datos (GDPR) de la UE establecen requisitos para proteger la privacidad y la información personal de los clientes. Hay otras, como las normativas establecidas por la Oficina del Interventor de la Moneda (OCC) de Estados Unidos y el Banco Central Europeo (BCE).
Por si fuera poco, la Estrategia Nacional de Ciberseguridad establece, entre otras cosas, que los fabricantes de software deben ser considerados responsables de la seguridad ineficaz de los programas informáticos. Y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), junto con 17 socios estadounidenses e internacionales, ha publicado orientaciones sobre los principios de Secure-By-Design para el desarrollo de software.
Un hilo común para las empresas de servicios financieros es que el código seguro es un elemento crítico para ayudar a cumplir los objetivos de esas normativas que pueden facilitar la demostración de su cumplimiento. Y subraya por qué los desarrolladores necesitan formación y actualización para garantizar que la seguridad se aplica al código desde el principio del proceso de desarrollo.
Como ejemplo de cómo funciona, veamos la versión más reciente de PCI DSS.
La codificación segura (y la formación de los desarrolladores) es el núcleo de PCI DSS 4.0
La norma PCI DSS 4.0, que será obligatoria a partir del 1 de abril de 2024, incluye varias actualizaciones sustanciales con respecto a la norma PCI DSS 3.2.1, entre las que destaca el énfasis en el papel que desempeñan los desarrolladores a la hora de garantizar la seguridad del código de software.
La PCI reconoció hace tiempo la importancia del software seguro. La versión 2.0, que se publicó en 2017, incluía orientaciones para desarrolladores sobre cómo garantizar transacciones seguras en dispositivos móviles. Las directrices de la versión 4.0 hacen ahora hincapié en la aplicación de las mejores prácticas de seguridad al desarrollo de software e incluyen algunas orientaciones específicas sobre la formación de los desarrolladores.
Los requisitos suelen establecerse a grandes rasgos, aunque las empresas pueden querer aplicar un enfoque más exhaustivo.
Por ejemplo, un requisito de la versión 4.0 afirma que "se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros". Una buena forma de asegurarse de que esto es así es que los desarrolladores reciban una formación precisa en los lenguajes de programación y marcos de trabajo que utilizan, con el fin de colmar cualquier laguna de conocimientos.
Otro requisito establece que los desarrolladores que trabajen con software a medida y personalizado deben recibir formación al menos una vez cada 12 meses, que cubra:
- Seguridad del software pertinente para su función laboral y lenguajes de desarrollo.
- Diseño de software seguro y técnicas de codificación.
- Cómo utilizar las herramientas de pruebas de seguridad -si se utilizan- para detectar vulnerabilidades en el software.
Pero, en realidad, una vez al año no es suficiente para abordar los principales problemas de seguridad y acabar con los malos hábitos de codificación. La formación debe ser continua y mesurada, con un proceso de verificación de las competencias para garantizar que se hace un buen uso de ella.
PCI DSS 4.0 incluye más de media docena de otros requisitos que abordan áreas como la prevención y mitigación de diversos tipos de ataques, la documentación de componentes de software de terceros, la identificación y gestión de vulnerabilidades y otras medidas de seguridad. En todos los casos, las organizaciones harían bien en aplicar a fondo esas medidas. La formación sobre vectores de ataque debe ser frecuente, no anual. Los componentes de terceros, que suelen ser una fuente de vulnerabilidades, deben inventariarse cuidadosamente mediante un programa de lista de materiales de software (SBOM). Y las organizaciones deben asegurarse de tener funciones claramente definidas para gestionar las vulnerabilidades.
La nueva versión también ofrece a las organizaciones cierta flexibilidad a la hora de cumplir sus requisitos, centrándose en los resultados más que en marcar casillas, al tiempo que añade nuevos requisitos para los controles de autenticación, la longitud de las contraseñas, las cuentas compartidas y otros factores.
La conformidad comienza al principio del SDLC
Lo que estas normativas tienen en común es que intentan establecer normas estrictas para proteger los datos y las transacciones en el sector de los servicios financieros. Y, como en el caso de la última versión de la PCI DSS, hacen cada vez más hincapié en la importancia de un código seguro al principio del ciclo de vida de desarrollo del software (SDLC). La Estrategia Nacional de Ciberseguridad y los principios Secure by Design de CISA también responsabilizan de la seguridad a los creadores de software -antes de que se distribuya-, de modo que incluso las empresas que no se rigen directamente por la normativa de servicios financieros deben cumplirla.
Las organizaciones necesitan salvar la brecha que existe entre los equipos DevOps (que se centran en la velocidad de desarrollo) y los equipos AppSec (que se apresuran a introducir la seguridad en el proceso) formando a los desarrolladores para que la seguridad sea inherente a su enfoque. Sin embargo, esto requiere un complejo conjunto de habilidades que implican más de lo que pueden ofrecer las sesiones de formación anuales o los programas educativos estándar y estancados. La formación debe ser continua y ágil, diseñada para involucrar a los alumnos con escenarios activos del mundo real e impartida en pequeñas sesiones que se adapten a sus horarios de trabajo.
Las empresas de servicios financieros necesitan garantizar la seguridad tanto para protegerse contra las infracciones como para cumplir la normativa, cada vez más estricta. Los costes del incumplimiento pueden ser tan perjudiciales como una violación en términos de impacto en la reputación de una empresa y costes monetarios. El Informe de IBM sobre el coste de una violación de datos en 2023, por ejemplo, descubrió que las organizaciones con un alto nivel de incumplimiento se enfrentaban, de media, a multas y otros costes por un total de 5,05 millones de dólares, medio millón más que el coste medio de una violación de datos real.
El continuo crecimiento de los entornos basados en la nube y las transacciones digitales ha hecho que la seguridad del software en el sector de los servicios financieros sea de vital importancia, algo que reconocen normativas como PCI DSS. La mejor manera de garantizar un software seguro es mediante una codificación segura al inicio del SDLC. Y la forma de conseguirlo es formando eficazmente a los desarrolladores en prácticas de codificación segura.
Para obtener una visión completa de cómo la codificación segura puede ayudar a garantizar el éxito, la seguridad y los beneficios de las empresas de servicios financieros, puede leer el libro electrónico recién publicado Secure Code Warrior : La guía definitiva de las tendencias de seguridad en los servicios financieros.
Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas y saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.

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ónSecure Code Warrior hace que la codificación segura sea una experiencia positiva y atractiva para los desarrolladores a medida que aumentan sus habilidades. Guiamos a cada programador a lo largo de su propio camino de aprendizaje, para que los desarrolladores con conocimientos de seguridad se conviertan en los superhéroes cotidianos de nuestro mundo conectado.
Este artículo fue escrito por Secure Code Warrior El equipo de expertos de la industria de está comprometido a brindar a los desarrolladores los conocimientos y las habilidades para crear software seguro desde el principio. Aprovechamos nuestra profunda experiencia en prácticas de codificación segura, tendencias de la industria y conocimientos del mundo real.
Las instituciones de servicios financieros tienen razones de peso para asegurarse de que el código de software que utilizan es seguro. Una motivación obvia, por supuesto, es la necesidad de proteger sus datos de una violación, que puede ser costosa en términos de información personal filtrada, gastos de limpieza, multas y restitución, y daños a la reputación de una organización. Otro motivo constante es la necesidad de cumplir toda una serie de normativas industriales y gubernamentales.
Como manejan tanta información sensible, personal y financiera, así como el dinero de la gente, los servicios financieros son un sector muy regulado. Dependiendo de los servicios que presten, las empresas deben cumplir una mezcla de normas y requisitos.
La Payment Card Industry Data Security Standard (PCI DSS) es bien conocida por sus normas de protección de datos de titulares de tarjetas, por ejemplo. Los requisitos de la Ley Sarbanes-Oxely regulan la gestión de los registros financieros. Las empresas que operan a escala internacional están familiarizadas con la Digital Operational Resilience Act (DORA), que es un marco vinculante de gestión de riesgos, y las normas mundiales para transferencias de fondos establecidas por la Society for Worldwide Interbank Financial Telecommunication, conocida como Swift.
Y leyes como la Ley de Privacidad del Consumidor de California (CCPA) y el Reglamento General de Protección de Datos (GDPR) de la UE establecen requisitos para proteger la privacidad y la información personal de los clientes. Hay otras, como las normativas establecidas por la Oficina del Interventor de la Moneda (OCC) de Estados Unidos y el Banco Central Europeo (BCE).
Por si fuera poco, la Estrategia Nacional de Ciberseguridad establece, entre otras cosas, que los fabricantes de software deben ser considerados responsables de la seguridad ineficaz de los programas informáticos. Y la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), junto con 17 socios estadounidenses e internacionales, ha publicado orientaciones sobre los principios de Secure-By-Design para el desarrollo de software.
Un hilo común para las empresas de servicios financieros es que el código seguro es un elemento crítico para ayudar a cumplir los objetivos de esas normativas que pueden facilitar la demostración de su cumplimiento. Y subraya por qué los desarrolladores necesitan formación y actualización para garantizar que la seguridad se aplica al código desde el principio del proceso de desarrollo.
Como ejemplo de cómo funciona, veamos la versión más reciente de PCI DSS.
La codificación segura (y la formación de los desarrolladores) es el núcleo de PCI DSS 4.0
La norma PCI DSS 4.0, que será obligatoria a partir del 1 de abril de 2024, incluye varias actualizaciones sustanciales con respecto a la norma PCI DSS 3.2.1, entre las que destaca el énfasis en el papel que desempeñan los desarrolladores a la hora de garantizar la seguridad del código de software.
La PCI reconoció hace tiempo la importancia del software seguro. La versión 2.0, que se publicó en 2017, incluía orientaciones para desarrolladores sobre cómo garantizar transacciones seguras en dispositivos móviles. Las directrices de la versión 4.0 hacen ahora hincapié en la aplicación de las mejores prácticas de seguridad al desarrollo de software e incluyen algunas orientaciones específicas sobre la formación de los desarrolladores.
Los requisitos suelen establecerse a grandes rasgos, aunque las empresas pueden querer aplicar un enfoque más exhaustivo.
Por ejemplo, un requisito de la versión 4.0 afirma que "se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros". Una buena forma de asegurarse de que esto es así es que los desarrolladores reciban una formación precisa en los lenguajes de programación y marcos de trabajo que utilizan, con el fin de colmar cualquier laguna de conocimientos.
Otro requisito establece que los desarrolladores que trabajen con software a medida y personalizado deben recibir formación al menos una vez cada 12 meses, que cubra:
- Seguridad del software pertinente para su función laboral y lenguajes de desarrollo.
- Diseño de software seguro y técnicas de codificación.
- Cómo utilizar las herramientas de pruebas de seguridad -si se utilizan- para detectar vulnerabilidades en el software.
Pero, en realidad, una vez al año no es suficiente para abordar los principales problemas de seguridad y acabar con los malos hábitos de codificación. La formación debe ser continua y mesurada, con un proceso de verificación de las competencias para garantizar que se hace un buen uso de ella.
PCI DSS 4.0 incluye más de media docena de otros requisitos que abordan áreas como la prevención y mitigación de diversos tipos de ataques, la documentación de componentes de software de terceros, la identificación y gestión de vulnerabilidades y otras medidas de seguridad. En todos los casos, las organizaciones harían bien en aplicar a fondo esas medidas. La formación sobre vectores de ataque debe ser frecuente, no anual. Los componentes de terceros, que suelen ser una fuente de vulnerabilidades, deben inventariarse cuidadosamente mediante un programa de lista de materiales de software (SBOM). Y las organizaciones deben asegurarse de tener funciones claramente definidas para gestionar las vulnerabilidades.
La nueva versión también ofrece a las organizaciones cierta flexibilidad a la hora de cumplir sus requisitos, centrándose en los resultados más que en marcar casillas, al tiempo que añade nuevos requisitos para los controles de autenticación, la longitud de las contraseñas, las cuentas compartidas y otros factores.
La conformidad comienza al principio del SDLC
Lo que estas normativas tienen en común es que intentan establecer normas estrictas para proteger los datos y las transacciones en el sector de los servicios financieros. Y, como en el caso de la última versión de la PCI DSS, hacen cada vez más hincapié en la importancia de un código seguro al principio del ciclo de vida de desarrollo del software (SDLC). La Estrategia Nacional de Ciberseguridad y los principios Secure by Design de CISA también responsabilizan de la seguridad a los creadores de software -antes de que se distribuya-, de modo que incluso las empresas que no se rigen directamente por la normativa de servicios financieros deben cumplirla.
Las organizaciones necesitan salvar la brecha que existe entre los equipos DevOps (que se centran en la velocidad de desarrollo) y los equipos AppSec (que se apresuran a introducir la seguridad en el proceso) formando a los desarrolladores para que la seguridad sea inherente a su enfoque. Sin embargo, esto requiere un complejo conjunto de habilidades que implican más de lo que pueden ofrecer las sesiones de formación anuales o los programas educativos estándar y estancados. La formación debe ser continua y ágil, diseñada para involucrar a los alumnos con escenarios activos del mundo real e impartida en pequeñas sesiones que se adapten a sus horarios de trabajo.
Las empresas de servicios financieros necesitan garantizar la seguridad tanto para protegerse contra las infracciones como para cumplir la normativa, cada vez más estricta. Los costes del incumplimiento pueden ser tan perjudiciales como una violación en términos de impacto en la reputación de una empresa y costes monetarios. El Informe de IBM sobre el coste de una violación de datos en 2023, por ejemplo, descubrió que las organizaciones con un alto nivel de incumplimiento se enfrentaban, de media, a multas y otros costes por un total de 5,05 millones de dólares, medio millón más que el coste medio de una violación de datos real.
El continuo crecimiento de los entornos basados en la nube y las transacciones digitales ha hecho que la seguridad del software en el sector de los servicios financieros sea de vital importancia, algo que reconocen normativas como PCI DSS. La mejor manera de garantizar un software seguro es mediante una codificación segura al inicio del SDLC. Y la forma de conseguirlo es formando eficazmente a los desarrolladores en prácticas de codificación segura.
Para obtener una visión completa de cómo la codificación segura puede ayudar a garantizar el éxito, la seguridad y los beneficios de las empresas de servicios financieros, puede leer el libro electrónico recién publicado Secure Code Warrior : La guía definitiva de las tendencias de seguridad en los servicios financieros.
Consulte las páginas del Secure Code Warrior para obtener más información sobre la ciberseguridad, el panorama cada vez más peligroso de las amenazas y saber cómo puede emplear tecnología innovadora y formación para proteger mejor a su organización y a sus clientes.
Índice
Secure Code Warrior hace que la codificación segura sea una experiencia positiva y atractiva para los desarrolladores a medida que aumentan sus habilidades. Guiamos a cada programador a lo largo de su propio camino de aprendizaje, para que los desarrolladores con conocimientos de seguridad se conviertan en los superhéroes cotidianos de nuestro mundo conectado.

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.