D3 · Vulnerabilidades y parches
Este procedimiento define cómo se detectan, clasifican, corrigen y verifican las vulnerabilidades de Bolívar Connect, y cómo se aplican los parches de seguridad. Cubre el código propio, sus dependencias, el sistema operativo de los servidores, la base de datos y la configuración de la infraestructura.
1. Fuentes de detección
Sección titulada «1. Fuentes de detección»| Fuente | Alcance | Cuándo |
|---|---|---|
| Pruebas automatizadas de seguridad | Aislamiento entre tenants, duplicados, firmas, scopes, idempotencia | En cada cambio |
Revisión de dependencias (npm audit) |
Dependencias de producción | Al menos una vez al mes y antes de cada actualización |
| Avisos de seguridad del sistema operativo y de la base de datos | Amazon Linux, PostgreSQL | Al publicarse |
| Auditoría interna de código y diseño | API, modelo de datos, configuración | Ante cambios mayores y al menos una vez al año |
| Pruebas de estrés con verificación de integridad | Instrucciones de pago, concurrencia, conciliación | Ante cambios del motor de pagos |
| Revisión de la configuración de AWS | Grupos de seguridad, IAM, cifrado | Ante cambios de infraestructura |
| Reportes externos | Clientes, terceros o investigadores | Al recibirse |
2. Clasificación
Sección titulada «2. Clasificación»Cada hallazgo se clasifica según su severidad técnica (CVSS cuando exista) y se ajusta por su exposición real: si el componente afectado es alcanzable desde la API y qué datos compromete.
| Severidad | Ejemplo | Plazo máximo de remediación |
|---|---|---|
| Crítica | Ejecución remota de código, acceso entre tenants, exposición de secretos | 7 días |
| Alta | Elevación de privilegios, denegación de servicio alcanzable | 30 días |
| Media | Fuga de información interna sin datos personales | 90 días |
| Baja | Endurecimiento o buenas prácticas | Próxima revisión programada |
Una vulnerabilidad crítica explotada o con exposición de datos se trata además como incidente (D4).
3. Tratamiento
Sección titulada «3. Tratamiento»- Registro: cada hallazgo se registra con su fuente, severidad, componente, responsable y fecha límite.
- Contención: si no puede corregirse de inmediato, se aplica un mitigante, como deshabilitar la ruta, restringir por IP o rotar credenciales.
- Corrección: el arreglo incluye una prueba de regresión que impide que el fallo reaparezca.
- Verificación: el cambio pasa la suite completa de pruebas antes de desplegarse.
- Cierre: se registra la fecha de cierre y la evidencia.
Si no se puede cumplir el plazo, la excepción la aprueba el Responsable de seguridad, con un mitigante documentado y una nueva fecha.
4. Gestión de parches
Sección titulada «4. Gestión de parches»- Sistema operativo y base de datos: los parches de seguridad se aplican dentro de los plazos de la sección 2. Los demás se aplican en una ventana mensual.
- Dependencias de la aplicación: las actualizaciones de seguridad se priorizan según la sección 2. Una actualización mayor se valida en el entorno de evaluación antes de pasar a producción.
- Procedimiento de despliegue: antes de un cambio relevante se toma un snapshot de la base de datos. El cambio se despliega fuera de las horas de mayor tráfico y se verifica la salud del servicio después.
5. Pruebas de intrusión
Sección titulada «5. Pruebas de intrusión»Se hacen pruebas de seguridad al menos una vez al año y antes de cada cambio mayor de la superficie expuesta. Siguen las categorías del OWASP API Security Top 10 y se ejecutan sobre un entorno aislado con datos sintéticos. Sus hallazgos siguen este mismo procedimiento. Los socios que lo soliciten pueden ejecutar sus propias pruebas en ese entorno, bajo reglas acordadas.
6. Indicadores
Sección titulada «6. Indicadores»El Responsable de seguridad revisa cada trimestre los hallazgos abiertos por severidad, los que exceden el plazo y el tiempo medio de remediación.