El cumplimiento del software gubernamental no se limita a superar una revisión final antes del lanzamiento, sino que comienza con la forma de escribir el código, gestionar las dependencias y documentar las decisiones. Un artículo publicado en el blog de JetBrains, en el contexto de la plataforma Qodana, presenta cinco áreas prácticas que los equipos de desarrollo de software del sector público pueden utilizar para reducir los riesgos de incumplimiento, teniendo en cuenta que los requisitos legales varían de un país a otro.
Esta cuestión adquiere una importancia adicional porque los sistemas gubernamentales gestionan grandes cantidades de datos personales y sensibles. El artículo cita el informe IBM Cost of a Data Breach Report 2026, según el cual el coste medio mundial de una filtración de datos alcanzó los 4,99 millones de dólares. También hace referencia a un informe de Ponemon Institute y Globalscape que estimó que el coste del incumplimiento era 2,71 veces superior al coste del cumplimiento. Estas cifras proceden de los informes en los que se basa la fuente y no constituyen una estimación independiente de JetBrains.
1. Seguridad y protección de datos
Los riesgos comienzan con errores habituales, como almacenar credenciales dentro del código, realizar una validación deficiente de las entradas y salidas o utilizar algoritmos de cifrado antiguos y débiles. Esto puede provocar la exposición de información personal o el incumplimiento de los controles de marcos de seguridad como ISO/IEC 27001, poniendo en riesgo la certificación y la reputación institucional.
Las normas varían según la jurisdicción. Las instituciones públicas de los países de la Unión Europea están sujetas al Reglamento General de Protección de Datos (GDPR), mientras que los organismos centrales del Reino Unido deben cumplir requisitos que incluyen UK GDPR, Data Protection Act 2018 y las normas de la National Audit Office. En Estados Unidos existen marcos como Federal Acquisition Regulation, Defense Federal Acquisition Regulation Supplement y FedRAMP.
En la práctica, el artículo recomienda incorporar la privacidad y las medidas de defensa al ciclo de vida del desarrollo de software desde el principio, en lugar de aplazarlas hasta las pruebas o la fase previa al despliegue. Entre las medidas mencionadas se encuentran almacenar las credenciales de forma segura, gestionar claramente el consentimiento del usuario, realizar pruebas de penetración antes del lanzamiento y mantener las pruebas automatizadas. Las dependencias externas también deben tratarse como riesgos activos, no como componentes neutrales.
2. Contratos, adquisiciones y dependencias de código abierto
El software que gestiona adquisiciones gubernamentales o acuerdos con proveedores puede causar problemas contractuales, como el incumplimiento de los niveles de servicio o de los criterios de aceptación de la entrega. Asimismo, la presencia de una clave API secreta en una rama de desarrollo, junto con la ausencia de un análisis SAST, puede permitir que pase código que no cumple las condiciones de entrega.
Las dependencias de código abierto añaden otra capa jurídica y técnica, ya que sus licencias pueden incluir cláusulas como copyleft o restricciones al uso comercial, lo que podría entrar en conflicto con las normas de adquisición o abrir disputas sobre la propiedad intelectual. Por ello, el artículo propone realizar un análisis automatizado de las licencias a nivel de dependencia, junto con puertas de calidad dentro de CI/CD que impidan que el código no conforme avance a la fase de entrega.
3. Evidencias auditables y rendición de cuentas
En las auditorías no basta con afirmar que existen controles; los controles que no están respaldados por evidencias pueden considerarse no demostrados. El artículo considera que depender de aprobaciones manuales y de resultados inconsistentes entre los equipos de garantía de calidad aumenta la probabilidad de que la auditoría fracase y eleva los riesgos de deuda técnica.
La solución práctica propuesta consiste en crear un registro digital que vincule las pruebas, la trazabilidad y los resultados del análisis con las etapas del ciclo de desarrollo. Esto ayuda a generar informes de auditoría automatizados y a presentar evidencias objetivas al revisar controles como las directrices del NIST para los sistemas federales de Estados Unidos, o los requisitos de ISO/IEC 27001 y las normas de la National Audit Office del Reino Unido.
4. Continuidad y soporte a largo plazo
La interrupción de un sistema gubernamental puede detener servicios esenciales para los ciudadanos, por lo que la prioridad no debería limitarse a una solución rápida que acumule problemas futuros. Los componentes de código abierto sin soporte pueden impedir la aplicación de parches, y la transferencia del sistema entre contratistas o equipos diferentes se vuelve más peligrosa cuando las vulnerabilidades y el contexto de las decisiones no están documentados.
Entre las prácticas propuestas se encuentran realizar un seguimiento de la actualidad de las dependencias, utilizar la versión estable más reciente o la versión con parches disponible, reducir el número de dependencias externas, aplicar pruebas unitarias y de integración y utilizar análisis estático para detectar pronto los errores del código. Estas prácticas también están relacionadas con los requisitos de continuidad del negocio, incluida la norma ISO 22301.
5. Gobernanza de la infraestructura y las políticas
Las herramientas de desarrollo y los servicios en la nube deben ajustarse a las líneas base de seguridad y a las políticas gubernamentales de tecnología de la información. El artículo menciona, por ejemplo, la política Government Cloud First del Reino Unido, además de las restricciones que los organismos públicos pueden imponer al uso de servicios SaaS o de dependencias externas en la nube, especialmente cuando gestionan datos sensibles o requisitos de FedRAMP.
Desde el punto de vista operativo, la pérdida de conocimiento institucional constituye un riesgo para los sistemas de larga duración. Documentar el contexto de las decisiones, las soluciones alternativas y sus motivos ayuda a los nuevos equipos a mantener la infraestructura. Asimismo, las herramientas alojadas localmente o aisladas de las redes externas pueden ser una opción adecuada cuando la política impide depender de una nube externa.
¿Qué cambia en la práctica?
La conclusión más importante no es comprar una herramienta concreta, sino convertir el cumplimiento en controles continuos dentro del entorno de desarrollo: análisis de seguridad y licencias, detección de secretos, seguimiento de dependencias, pruebas automatizadas y políticas ejecutables y documentables en CI/CD. Este enfoque reduce la dependencia de una revisión manual tardía, pero no elimina la necesidad de interpretar los requisitos legales y definir las responsabilidades humanas. El artículo tampoco demuestra que estas medidas garanticen el cumplimiento total en todos los países; señala expresamente que las normas varían según la ubicación y las políticas aplicables. En este contexto, Qodana se presenta como una herramienta que puede integrarse en entornos de desarrollo y canalizaciones de integración, un aspecto promocional que debe separarse de los principios generales aplicables con distintas herramientas.