Política de desarrollo seguro, validación y gestión de cambios

1. Objetivo

BiomedOS diseña, construye, prueba, libera y mantiene software de manera controlada, trazable, segura y reversible. El rigor se ajusta al riesgo sobre datos, continuidad, evidencia regulatoria, equipos y pacientes.

2. Requisitos y diseño

Todo cambio material identifica necesidad, usuario, alcance, datos, criterios de aceptación, compatibilidad, seguridad, privacidad, accesibilidad, migración y reversión. Se documentan supuestos y límites. Las funciones de alto impacto reciben revisión de Producto, Seguridad y Privacidad. Cuando una función pueda influir directamente en decisiones clínicas o controlar un dispositivo, se detiene la liberación comercial hasta completar la evaluación regulatoria.

3. Ambientes y datos

Desarrollo, pruebas y producción están separados por controles técnicos y permisos. Los datos sintéticos son la regla. No se copian bases de producción a otros entornos sin necesidad indispensable, instrucción/autorización, evaluación, minimización, protección equivalente, registro y eliminación. Los secretos se mantienen fuera del código y de repositorios; no se publican en tickets o registros.

4. Código y componentes

Los cambios reciben revisión proporcional e independiente cuando la estructura lo permite. Se usan análisis de código, dependencias, secretos y licencias apropiados. BiomedOS mantiene inventario de componentes y versiones y, cuando el riesgo o regulación lo requiera, una lista de materiales de software. Dependencias obsoletas o vulnerables se actualizan, sustituyen, aíslan o aceptan formalmente con control compensatorio y vencimiento.

5. Pruebas y validación

Se prueban función, permisos, separación de tenants, errores, rendimiento y seguridad. Para reglas CMMS se cubren identificación de activos, fechas y zonas horarias, periodicidad, generación/cierre/reapertura de órdenes, firmas/aprobaciones, estados, calibración, adjuntos, historial, alertas, exportación e integraciones.

Las migraciones se ensayan con respaldo y reconciliación. Los criterios de aceptación deben cumplirse o contar con excepción aprobada. La evidencia identifica versión, entorno, responsable, fecha y resultado.

6. Liberación y cambios

Los despliegues se autorizan, registran y monitorean. Los cambios materiales se comunican con antelación razonable; los cambios de seguridad urgentes pueden desplegarse primero y comunicarse después. Se define plan de reversión y se evita mezclar cambios innecesarios. Un cambio que altere evidencia histórica debe preservar valores anteriores, autor, fecha y razón.

7. Vulnerabilidades y parches

Las vulnerabilidades se clasifican por explotabilidad, exposición, impacto y controles. Las explotadas activamente o críticas reciben prioridad. Los plazos internos se definen por severidad; una excepción requiere dueño, justificación, compensación y fecha. La divulgación se rige por la Política 08.

8. Documentación y fin de vida

Cada versión mantiene notas, riesgos conocidos y soporte. Las funciones obsoletas reciben aviso, alternativa, fecha y plan de datos. La terminación de un componente crítico contempla exportación, compatibilidad y conservación de evidencia.

9. Auditoría y mejora

Se revisan fallas de despliegue, defectos escapados, vulnerabilidades, reversión y cobertura. Los hallazgos generan acciones. Las prácticas se inspiran en ISO/IEC 27001, guías OWASP y, cuando corresponda a software médico, requisitos regulatorios y de ciclo de vida aplicables; esto no constituye certificación.