La creciente complejidad de las infraestructuras informáticas en el sector financiero exige una evaluación exhaustiva de las dependencias de software. Con la Ley de Resiliencia Operativa Digital (DORA), la gestión de bibliotecas de terceros y el análisis de código abierto (open source) se convierten en elementos centrales para garantizar la resiliencia operativa y la seguridad de los activos digitales, tal como lo establece el Artículo 25 del reglamento.

Análisis de código abierto previsto por DORA

DORA establece que los análisis de software de código abierto deben incluirse en el programa de pruebas de resiliencia operativa digital. El objetivo es gestionar los riesgos relacionados con la cadena de suministro de software: una vulnerabilidad en una biblioteca compartida puede comprometer toda la infraestructura de una entidad financiera. Según los requisitos normativos, el análisis de código abierto permite identificar preventivamente las fallas de seguridad en los componentes de terceros para mantener el control sobre los riesgos operativos.

Dependencias de software y Reglamento Delegado (UE) 2024/1773

El Reglamento Delegado (UE) 2024/1773 exige que las entidades financieras analicen el código fuente y el software propietario proveniente de terceros o de proyectos de código abierto antes de su puesta en producción, buscando vulnerabilidades y código malicioso. Se requieren pruebas estáticas y dinámicas, la detección de anomalías y la adopción de planes de remediación.

Inventario de dependencias y monitoreo de vulnerabilidades CVE

Una gestión eficaz de las dependencias requiere el seguimiento sistemático de las bibliotecas de terceros, el monitoreo de versiones, actualizaciones oportunas y el registro puntual de cada vulnerabilidad que afecte a los sistemas TIC. Los procedimientos deben contemplar:

• Monitoreo y seguimiento constante de las bibliotecas, incluidas las de código abierto, con su correspondiente gestión de actualizaciones.
• Registro de cada vulnerabilidad detectada.
• Priorización de la distribución de parches según la criticidad de la vulnerabilidad y el perfil de riesgo de los activos afectados.
• Para activos críticos o relevantes, el monitoreo debe ser estricto; para activos off-the-shelf no críticos, el seguimiento debe garantizarse siempre que sea posible.

SBOM: estado del arte para el cumplimiento

Aunque DORA y las RTS no mencionan explícitamente la SBOM (Software Bill of Materials), la necesidad de rastrear bibliotecas y versiones convierte a la SBOM en el estándar técnico más eficaz y utilizado para asegurar el cumplimiento. Una SBOM funciona como un inventario completo de los componentes de software, facilitando el monitoreo proactivo y la respuesta oportuna ante nuevas vulnerabilidades públicas (CVE) que involucren bibliotecas específicas empleadas por la entidad.

Integración en el SDLC y en la gestión de parches

El análisis de código abierto requerido por DORA debe integrarse en el ciclo de vida de desarrollo de software (SDLC). Las entidades están obligadas a proteger la integridad del código fuente —tanto interno como de terceros— y a vincular estas actividades con la gestión de parches. Las actualizaciones de software deben probarse e implementarse en entornos de staging representativos antes de su distribución en producción, para evitar interrupciones operativas. Si una vulnerabilidad de código abierto no cuenta con un parche, es obligatorio identificar y activar otras medidas de mitigación.

Preguntas frecuentes

• ¿DORA obliga a utilizar una SBOM?
• La normativa exige rastrear el uso de bibliotecas de terceros y de código abierto, monitoreando sus versiones y actualizaciones. Aunque no utiliza el término “SBOM”, la creación de una lista de materiales de software representa la solución técnica más eficaz para cumplir con este requisito.
• ¿Cómo gestionar bibliotecas en aplicaciones heredadas (legacy)?
• Las entidades deben monitorear si los activos TIC siguen siendo soportados por los proveedores o desarrolladores. Para activos heredados o que ya no cuentan con soporte, es indispensable un plan de gestión de riesgos que mitigue su obsolescencia.
• ¿El análisis de código abierto sustituye al pentest?
• No. El análisis de código abierto se centra en las dependencias y en el código, y forma parte de las pruebas ordinarias de resiliencia previstas por el Artículo 25. Dichas actividades deben integrarse con evaluaciones de vulnerabilidad (vulnerability assessment) y pruebas de penetración (penetration test) para evaluar la seguridad integral de los sistemas.

Gobierna tu cadena de suministro de software: solicita una revisión del riesgo de software y de las dependencias críticas para alinear tu desarrollo con los requisitos de seguridad de DORA.