¿Es seguro utilizar código abierto para desarrollar aplicaciones fintech?

13 de abril de 2023 - Equipo de RRPP de TuxCare

Las aplicaciones fintech requieren una postura de seguridad especialmente sólida. Al fin y al cabo, estás protegiendo los datos financieros (o, lo que es aún más desconcertante, el dinero) de tus clientes.

Los proveedores de servicios financieros son un objetivo lucrativo para los piratas informáticos y el éxito de los ataques entraña grandes riesgos para los usuarios y las organizaciones que poseen y gestionan aplicaciones de tecnología financiera. Por tanto, ¿deberían los desarrolladores de tecnología financiera utilizar código abierto no comercial?

Es una cuestión "abierta" y, en este artículo, analizaremos los riesgos, incluido lo que pueden hacer los desarrolladores de tecnología financiera para proteger el código fuente abierto.

Duros retos de seguridad para el desarrollo de software fintech

Las aplicaciones de tecnología financiera tienen requisitos de ciberseguridad especialmente estrictos debido a lo mucho que está en juego. Entre los riesgos y retos de ciberseguridad más comunes en el sector de las finanzas y la tecnología se encuentran los problemas de computación en la nube, los ataques de malware, el acceso de terceros, la complejidad y compatibilidad de los sistemas, los riesgos de blanqueo de capitales, el robo de identidad y la autenticación y, sobre todo, el cumplimiento normativo.

Por ejemplo, para garantizar la seguridad en torno a los pagos electrónicos, muchas jurisdicciones aplican la Directiva de Servicios de Pago (PSD2), con normas específicas sobre el mantenimiento de la seguridad de los datos. En Estados Unidos, la Norma de Seguridad de Datos del Sector de las Tarjetas de Pago (PCI DSS) se encarga de regular la recopilación, el tratamiento y el uso de los datos de las tarjetas de pago, pero es una norma que se aplica en todo el mundo.

Así pues, las aplicaciones de tecnología financiera no sólo corren el riesgo de sufrir un ciberataque, sino también de incumplir la normativa. Un fallo de seguridad puede tener rápidamente grandes consecuencias. Por tanto, ¿es una buena idea confiar en código "libre"?

¿Qué mantiene la seguridad de los datos: el código abierto o el comercial?

Es un debate candente y la respuesta correcta no es que el código comercial de pago sea más seguro simplemente porque se intercambie dinero a cambio del código de la aplicación.

El código abierto está más abierto al escrutinio porque todo el mundo puede verlo. Así que, en teoría, es más probable que se descubra un fallo en el código fuente abierto. Por otro lado, no hay garantía de que las personas adecuadas estén examinando críticamente el código fuente abierto o de que los desarrolladores estén motivados para encontrar fallos. De hecho, pueden ser actores de amenazas los que busquen fallos.

Sin embargo, el software comercial de código cerrado, impulsado por el afán de lucro, no tiene por qué ser necesariamente más seguro, ya que los proveedores pueden no desplegar investigadores de seguridad para examinar el código en busca de fallos y apresurarse a codificarlo para cumplir los plazos.

En definitiva, los desarrolladores cometen errores independientemente de si se les paga o noy es importante que tanto el software de código abierto como el de código cerrado sean revisados y sometidos a pruebas de seguridad. Para los desarrolladores, eso significa que ambas bases de código deben tratarse con la misma cautela.

La seguridad del código abierto preocupa a todos

Pero aquí viene lo interesante: el código comercial suele basarse en componentes de código abierto, por lo que es probable que las organizaciones utilicen código abierto en sus aplicaciones aunque dependan principalmente de socios comerciales.

En esencia, hay una proliferación de bibliotecas y paquetes de código abierto. En las aplicaciones basadas en la nube, suelen integrarse múltiples bibliotecas y servicios de código abierto en la pila tecnológica, lo que permite a los desarrolladores beneficiarse del trabajo existente.

Sin embargo, en algunos casos, también proporciona a los atacantes una puerta de entrada para penetrar en las redes. Estos componentes de código abierto pueden albergar vulnerabilidades que pueden filtrarse a la producción, provocando retrasos en el proyecto si se identifican en una fase tardía del proceso de compilación o después del despliegue.

Es una situación intrincada con dependencias de dependencias que plantea una amenaza clara, porque puede ser fácil pasar por alto cuando una aplicación invoca un paquete que contiene vulnerabilidades. En cualquier caso, las vulnerabilidades de código abierto forman parte del proceso de desarrollo de la tecnología financiera, tanto si los desarrolladores se basan principalmente en código comercial como en código abierto.

Centrarse en DevSecOps para lograr la seguridad

El desarrollo de software moderno requiere un proceso de seguridad continuo, no una solución puntual, y da igual que el código base sea comercial o de código abierto. Este enfoque, conocido como DevSecOps, implica una responsabilidad compartida en materia de seguridad entre los equipos de desarrollo, seguridad y operaciones.

El modelado de amenazas, las herramientas de pruebas de seguridad, las pruebas de penetración y las auditorías se incorporan a la canalización CI/CD. Los desarrolladores también pueden utilizar el análisis de composición de software para supervisar los componentes de código abierto a lo largo del proceso de desarrollo y detectar los principales fallos conocidos que dificultan la protección de los datos. Este enfoque colaborativo conduce a una entrega de software más rápida y segura para las aplicaciones de tecnología financiera.

Todos los demás buenos consejos son, por supuesto, también válidos: aplicar sistemáticamente buenas prácticas como MFA, contraseñas seguras, gestión de credenciales y permisos estrictos. La supervisión y las pruebas también pueden identificar intrusos y fallos. Conozca las herramientas y los componentes básicos en los que confía, incluidas las bibliotecas y las dependencias.

Podría decirse que el elemento más crucial de la seguridad del software es la aplicación de parches. La aplicación exhaustiva de parches protege contra las vulnerabilidades conocidas, tanto si se utiliza software libre como comercial. Pero aplicar parches de forma sistemática es difícil y lleva mucho tiempo, lo que a menudo hace que solo se aborden las vulnerabilidades más prioritarias.

Es más, la aplicación de parches puede requerir un reinicio o reinicio, y los equipos de desarrollo pueden retrasar o evitar la aplicación de parches para mantener la disponibilidad. Merece la pena considerar la aplicación de parches en vivo como una solución.

Conclusión

La cuestión no es tanto si es seguro o no utilizar código abierto en las aplicaciones de tecnología financiera. El código fuente abierto está en todas partes y probablemente se introducirá en su aplicación de tecnología financiera de todos modos. ¿Debería utilizar más o menos código abierto? Esa es otra cuestión, pero no se puede argumentar que el código fuente abierto sea intrínsecamente menos seguro.

En su lugar, céntrate en proteger todo el código, incluido el código fuente abierto que decidas utilizar y el código fuente abierto que esté dentro de tu pila tecnológica de todos modos.