Observaciones técnicas enviadas a la consulta pública del Estándar de Software v2.0 del MITIC (Paraguay) – marzo 2026. Cubre gestión de vulnerabilidades post-entrega, autenticación estándar (OAuth2/OIDC), documentación de APIs, gestión de dependencias (SBOM), uso de IA en desarrollo y protección de datos en ambientes no productivos
En base a https://drive.mitic.gov.py/s/QixScZTePRCQRAK
Página: 22
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Submodalidad A – Especificaciones Técnicas – Seguridad
Texto vigente:
El documento no contempla ninguna disposición sobre el proceso a seguir ante el descubrimiento de vulnerabilidades en software ya entregado y en operación.
Texto propuesto:
Incorporar como párrafo adicional en la sección de Seguridad:
"El oferente adjudicado deberá establecer y documentar un proceso formal de gestión y divulgación de vulnerabilidades aplicable durante el periodo de garantía y, cuando corresponda, durante la vigencia del contrato de soporte u operación y mantenimiento. Dicho proceso deberá contemplar como mínimo: canales de notificación de vulnerabilidades al OEE, clasificación por severidad conforme a estándares reconocidos, tiempos máximos de respuesta y remediación según nivel de severidad, y procedimiento de comunicación al OEE previo a cualquier divulgación pública. Las vulnerabilidades críticas o altas deberán ser notificadas al OEE dentro de las 24 horas de su detección o conocimiento, y remediadas en un plazo que no podrá exceder los plazos establecidos en el acuerdo de nivel de servicio correspondiente o, en su defecto, dentro de los 30 días corridos desde su notificación."
Justificación:
El estándar vigente establece requisitos de seguridad para el desarrollo del software, pero no contempla qué sucede cuando se descubre una vulnerabilidad una vez que el sistema ya está en producción. Esta omisión deja al OEE sin herramientas contractuales para exigir una respuesta oportuna ante incidentes de seguridad post-entrega. La ausencia de un proceso formal de divulgación también genera riesgos para la ciudadanía, ya que una vulnerabilidad conocida por el proveedor pero no comunicada al OEE puede permanecer sin remediar indefinidamente.
Esta observación es coherente con la Estrategia Nacional de Ciberseguridad 2025-2028 citada en el propio documento y con estándares internacionales de gestión de vulnerabilidades como ISO/IEC 30111 y las guías de Coordinated Vulnerability Disclosure del CERT.
Página: 22
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Submodalidad A – Especificaciones Técnicas – Seguridad
Texto vigente:
"En cuanto a los mecanismos de autenticación, se requerirá el uso obligatorio de autenticación multifactor (MFA) para accesos administrativos y funcionalidades críticas, así como la integración con la Identidad Electrónica del MITIC, con el fin de fortalecer la verificación de identidad y la trazabilidad de los accesos."
Texto propuesto:
"En cuanto a los mecanismos de autenticación, se requerirá el uso obligatorio de autenticación multifactor (MFA) para accesos administrativos y funcionalidades críticas, así como la integración con la Identidad Electrónica del MITIC. A tal efecto, todo software desarrollado deberá implementar soporte para protocolos estándar y abiertos de autenticación y autorización, específicamente OAuth 2.0 y OpenID Connect (OIDC), a fin de garantizar la interoperabilidad con cualquier Proveedor de Identidad (IdP) que implemente dichos estándares, evitando dependencias a mecanismos propietarios de autenticación y promoviendo la neutralidad tecnológica del Estado."
Justificación:
El texto vigente establece la obligatoriedad de integración con la Identidad Electrónica del MITIC, pero no especifica los mecanismos técnicos mediante los cuales dicha integración debe realizarse. Esta omisión genera un riesgo concreto: que cada sistema implemente la autenticación de forma propietaria o incompatible, contradiciendo los principios de interoperabilidad y neutralidad tecnológica que el propio estándar promueve.
OAuth 2.0 y OpenID Connect (OIDC) son los protocolos internacionalmente adoptados para autenticación y autorización federada en sistemas de información. Su uso está alineado con los lineamientos de Gobierno Electrónico vigentes y con la naturaleza del Sistema de Intercambio de Información (SII) citado en el estándar. Exigir el soporte de estos protocolos no restringe la elección de tecnología ni de proveedor, sino que garantiza que cualquier solución adoptada por el OEE sea interoperable con la plataforma centralizada del MITIC y con otros sistemas del Estado, tanto presentes como futuros.
Página: 21
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Submodalidad A – Especificaciones Técnicas – Pautas de Arquitectura del Software
Texto vigente:
"La implementación de interfaces de integración (APIs) del producto software entregado para la interconexión con otros sistemas y/o con el Sistema de Intercambio de Información del MITIC, conforme al Decreto Nº 8709/2018 y la Resolución MITIC Nº 212/2020, cuando corresponda. Además de la integración con la Identidad Electrónica del MITIC conforme a la Resolución MITIC N° 553/2024."
Texto propuesto:
"La implementación de interfaces de integración (APIs) del producto software entregado para la interconexión con otros sistemas y/o con el Sistema de Intercambio de Información del MITIC, conforme al Decreto Nº 8709/2018 y la Resolución MITIC Nº 212/2020, cuando corresponda. Además de la integración con la Identidad Electrónica del MITIC conforme a la Resolución MITIC N° 553/2024. A efectos de garantizar dicha integración, el software deberá implementar soporte para los protocolos estándar OAuth 2.0 y OpenID Connect (OIDC), de manera que la autenticación y autorización puedan delegarse a un Proveedor de Identidad (IdP) externo que implemente dichos estándares, sin dependencia a mecanismos de autenticación propietarios o acoplados al propio sistema."
Justificación:
La arquitectura de un sistema de información no puede considerarse abierta e interoperable si su mecanismo de autenticación es propietario o está acoplado internamente. Establecer como requisito de arquitectura el soporte de OAuth 2.0 y OIDC es una condición necesaria para que la integración con la Identidad Electrónica del MITIC sea técnicamente viable y sostenible en el tiempo, independientemente de qué plataforma de gestión de identidad adopte el Estado. Esta exigencia es coherente con los principios de arquitectura modular, desacoplada y basada en estándares abiertos que el propio estándar establece para las transferencias no onerosas en el Capítulo 3, y que resulta igualmente aplicable al desarrollo de software propio.
Página: 22
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Submodalidad A – Especificaciones Técnicas – Seguridad
Texto vigente:
"Adicionalmente, se deberán implementar prácticas de integración y entrega continua (CI/CD) que incorporen controles de seguridad automatizados, tales como revisión de dependencias, escaneo de código en cada commit, pruebas unitarias y de seguridad en las pipelines, despliegues controlados y verificables, y validación de integridad de artefactos."
Texto propuesto:
"Adicionalmente, se deberán implementar prácticas de integración y entrega continua (CI/CD) que incorporen controles de seguridad automatizados, tales como revisión de dependencias, escaneo de código en cada commit, pruebas unitarias y de seguridad en las pipelines, despliegues controlados y verificables, y validación de integridad de artefactos. Como parte de los entregables obligatorios, el oferente adjudicado deberá proveer un inventario completo de dependencias de software de terceros utilizado en el sistema (Software Bill of Materials – SBOM), en formato estándar y legible por herramientas automatizadas. Dicho inventario deberá incluir, como mínimo, el nombre, versión y licencia de cada componente, así como evidencia de que las dependencias utilizadas no presentan vulnerabilidades conocidas críticas o altas al momento de la entrega, conforme a bases de datos de vulnerabilidades públicas reconocidas. El SBOM deberá mantenerse actualizado durante toda la vigencia del contrato."
Justificación:
La seguridad de un sistema no depende únicamente del código desarrollado a medida, sino también de la cadena de dependencias que lo compone. Es habitual que sistemas con código propio de buena calidad presenten vulnerabilidades graves introducidas a través de librerías o componentes de terceros desactualizados o comprometidos. El documento vigente menciona la revisión de dependencias en el contexto de CI/CD, pero no la eleva a entregable formal ni establece un estándar de documentación.
La exigencia de un SBOM es una práctica consolidada internacionalmente, adoptada por marcos de referencia como el NIST Cybersecurity Framework, y permite al OEE conocer, auditar y gestionar los riesgos de la cadena de suministro de software durante todo el ciclo de vida del sistema, no solo al momento del desarrollo.
Página: 21
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Submodalidad A – Especificaciones Técnicas – Pautas de Arquitectura del Software
Texto vigente:
"La implementación de interfaces de integración (APIs) del producto software entregado para la interconexión con otros sistemas y/o con el Sistema de Intercambio de Información del MITIC, conforme al Decreto Nº 8709/2018 y la Resolución MITIC Nº 212/2020, cuando corresponda."
Texto propuesto:
"La implementación de interfaces de integración (APIs) del producto software entregado para la interconexión con otros sistemas y/o con el Sistema de Intercambio de Información del MITIC, conforme al Decreto Nº 8709/2018 y la Resolución MITIC Nº 212/2020, cuando corresponda. Toda API expuesta deberá contar con documentación técnica completa y actualizada en un formato estándar y legible por herramientas automatizadas, tal como OpenAPI. Asimismo, deberá implementarse una política de versionado explícita que garantice la compatibilidad hacia atrás durante un periodo razonable ante cambios, y que establezca un proceso formal de notificación y transición previo a la deprecación de cualquier versión. Estas condiciones son aplicables tanto a APIs internas entre módulos como a APIs expuestas para integración con otros sistemas del Estado."
Justificación:
El documento promueve la interoperabilidad entre sistemas del Estado como uno de sus principios centrales, pero no establece condiciones técnicas mínimas para que dicha interoperabilidad sea sostenible en el tiempo. Una API sin documentación estandarizada obliga a cada sistema consumidor a realizar ingeniería inversa para integrarse. Un cambio sin política de versionado puede romper integraciones existentes sin previo aviso, generando costos y fallas en cascada entre sistemas del Estado.
La documentación en formato estándar como OpenAPI facilita además la auditoría técnica, la reutilización y el mantenimiento por parte del OEE o de terceros, siendo coherente con los principios de transparencia y soberanía tecnológica que el estándar establece.
Página: 18-19
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Propiedad intelectual y licencias del software
Texto vigente:
"En estas modalidades de desarrollo de software, el autor garantiza haber realizado una obra original. En ese orden, no podrá incorporar software (en todo o parte) del que no fuere titular o no estuviera en condiciones de ceder completamente al OEE contratante..."
Texto propuesto:
Incorporar al final del párrafo existente:
"El uso de herramientas de asistencia al desarrollo basadas en inteligencia artificial no modifica las obligaciones del desarrollador en materia de originalidad, propiedad intelectual, seguridad y calidad del software entregado. El desarrollador es responsable íntegro del código producido independientemente de las herramientas utilizadas para su generación, debiendo garantizar que dicho código cumple con todos los requisitos establecidos en el presente estándar y que no infringe derechos de propiedad intelectual de terceros. Asimismo, el uso de estas herramientas no exime al desarrollador de las obligaciones de revisión, validación y prueba del código generado, ni de la obligación de documentar adecuadamente los componentes entregados."
Justificación:
El uso de herramientas de generación de código basadas en inteligencia artificial es ya una práctica extendida en la industria del software. Sin embargo, estas herramientas presentan riesgos específicos que el estándar vigente no contempla: pueden generar código con vulnerabilidades de seguridad conocidas, reproducir fragmentos de código con licencias incompatibles con los términos exigidos por el estándar, o producir código de difícil mantenimiento que el OEE no puede auditar adecuadamente.
La ausencia de una disposición al respecto genera una zona gris jurídica y técnica en la que el OEE podría recibir software que no cumple con las condiciones de titularidad o seguridad exigidas sin posibilidad de reclamar al proveedor. La incorporación de esta cláusula no prohíbe el uso de dichas herramientas sino que clarifica responsabilidades, protegiendo al Estado sin limitar la productividad del sector.
Página: 22
Capítulo: Capítulo 4 – Modalidad de desarrollo de software de titularidad del Estado
Sección: Submodalidad A – Especificaciones Técnicas – Seguridad
Texto vigente:
"Asimismo, deberán adoptarse mecanismos de registro, auditoría y monitoreo continuo que permitan detectar, mitigar y responder oportunamente a incidentes de seguridad, asegurando una protección integral durante todo el ciclo de vida del software y la continuidad de los servicios públicos."
Texto propuesto:
Incorporar como párrafo adicional en la sección de Seguridad:
"Queda expresamente prohibido el uso de datos reales de ciudadanos, funcionarios o cualquier persona física o jurídica en ambientes de desarrollo, prueba o control de calidad. Para dichos ambientes deberá utilizarse exclusivamente datos sintéticos o anonimizados, generados de forma que no permitan la reidentificación de personas. El oferente adjudicado deberá documentar el procedimiento utilizado para la generación o anonimización de datos de prueba y garantizar que dicho procedimiento sea aplicado durante toda la ejecución del contrato. El incumplimiento de esta disposición será considerado una falla grave de seguridad a los efectos contractuales."
Justificación:
El uso de datos reales en ambientes no productivos es una de las causas más frecuentes de exposición de información personal en proyectos de software, y representa una violación al principio de minimización de datos. Durante el desarrollo y las pruebas, los datos quedan expuestos a un número mayor de personas y sistemas, generalmente con controles de seguridad más laxos que los del ambiente de producción.
El Estado paraguayo gestiona datos sensibles de ciudadanos en áreas como salud, seguridad social, identificación y finanzas públicas, por lo que la protección de esos datos en todas las fases del ciclo de vida del software es una responsabilidad institucional. Esta disposición es coherente con los principios de protección de datos establecidos en el estándar y con buenas prácticas internacionales de desarrollo seguro.