Hardening checks

Los 4 checks

core/forja/core/hardening_checks.py implementa run_full_hardening_scan, que ejecuta cuatro verificaciones:

Modos

• stub (default · dev/tests) · los checks que dependen de herramientas externas devuelven resultado limpio sin ejecutarlas
• real (FORJA_HARDENING_MODE=real) · ejecuta las herramientas reales con timeouts

Pasar a modo real requiere instalar en el venv:

pip install detect-secrets pip-audit

Si una herramienta externa no está instalada en modo real, el check lo reporta como hallazgo (severity=medium) en lugar de fallar silenciosamente.

Endpoints

POST /api/hardening/scan          # lanza el scan completo
GET  /api/hardening/findings      # lista los hallazgos persistidos (filtrable)
GET  /api/hardening/findings/{id} # detalle de un hallazgo
POST /api/hardening/findings/{id}/resolve  # marca un hallazgo como resuelto

Cada hallazgo se persiste con su scan_kind (audit_chain, detect_secrets, pip_audit, backup_freshness), severidad y ruta afectada.

Política institucional · gate de release

El scan calcula high_severity_count (hallazgos con severidad high o critical). La regla es binaria:

Cualquier hallazgo HIGH o CRITICAL activa blockers_release = true. No se permite deployment a producción con hallazgos de esa severidad sin resolver.

Además, cada hallazgo release-blocking dispara un audit_event y una alerta al operador.

Frecuencia

• Manual · en cada release o cuando el operador lo pida
• Cron · programable (p. ej. diario)
• Post-incident · tras cualquier audit_event de severidad crítica

Integración con ISO 27001

Cada check mapea directamente a un control catalogado del Anexo A:

4 checks · 4 controles ISO 27001 cubiertos directamente.