Desarrollo seguro y gestión de cambios
Objetivo
Que el software de ELEMENTHOR se diseñe, construya, pruebe y publique de forma segura y controlada.
Ciclo de desarrollo seguro
- Requisitos y diseño: cada funcionalidad nueva considera desde el inicio quién puede usarla (roles), qué datos toca y cómo se protege. La separación entre empresas es un requisito de toda funcionalidad.
- Construcción: la plataforma no usa librerías de terceros de npm (sin dependencias externas), lo que reduce la superficie de ataque de la cadena de suministro. Las entradas se validan en el servidor; las contraseñas se guardan con scrypt; las peticiones que cambian datos solo se aceptan desde la propia plataforma (protección CSRF).
- Pruebas: cada compilación pasa todas las pruebas automáticas (más de 250) antes de publicarse, incluidas pruebas de aislamiento entre empresas, permisos por rol y límites de intentos. Además se revisan en el navegador todas las páginas públicas y todas las secciones de la consola.
- Publicación: cada compilación queda numerada, con fecha, descripción de los cambios y la huella SHA-256 de su código. La plataforma comprueba al arrancar y cada hora que el código en ejecución coincide con esa huella y avisa si no.
- Operación: las fallas que se reporten se priorizan por riesgo (ver Gestión de vulnerabilidades).
Criterios de aceptación
Una versión solo se publica si: todas las pruebas pasan, la revisión del sitio y de la consola no muestra errores, y el registro de cambios está actualizado.
Cambios
- Todo cambio en el código o en la infraestructura sigue el flujo: describir el cambio → probar → compilar → publicar → verificar en producción.
- Los cambios de configuración de la plataforma se hacen desde la consola y quedan registrados en la bitácora de seguridad.
- Los cambios de emergencia (por ejemplo un parche crítico) pueden publicarse primero, pero se documentan y prueban en las 48 horas siguientes, como excepción registrada.
- Ningún cambio toca los datos de una empresa cliente salvo lo que esa empresa pidió o lo que exige el contrato.
Vuelta atrás
Si una versión causa errores o problemas de seguridad, se vuelve a instalar la compilación anterior (se conservan los paquetes publicados) y, si hace falta, se restauran los datos desde la última copia verificada.
Interfaces (API)
Las API exigen sesión o token, respetan los permisos del rol, tienen límite de uso por empresa, viajan solo por HTTPS y se revisan una vez al año.
Métricas
Se miden: pruebas automáticas aprobadas por versión, fallas de seguridad abiertas y su antigüedad, y disponibilidad del servicio (página de estado).
Revisión
Este documento se revisa al menos una vez al año y cada vez que haya un cambio importante en el servicio, en la infraestructura o en la ley. La revisión y la aprobación quedan registradas en Consola → Seguridad y cumplimiento, con su versión y fecha.
Sobre este documento
Esta es la versión 1 de la política, aprobada el 2026-11-12. Forma parte del programa de seguridad de la información de ELEMENTHOR, que cubre los 17 dominios de la Cloud Controls Matrix de la Cloud Security Alliance y aplica a OSNEX Service Desk, CRM, HCM y Nómina. Cada política tiene un responsable, se revisa al menos una vez al año y cada revisión queda registrada con su fecha y su versión.
Si tu empresa está evaluando a ELEMENTHOR como proveedor y necesita más detalle, por ejemplo el cuestionario de seguridad, el modelo de responsabilidad compartida o la lista de componentes del servicio, escríbenos a support@elementhor.com y te respondemos por correo.