Continuous compliance

Cómo funciona

Los requisitos se traducen en controles verificables dentro del flujo de entrega. Las políticas como código evalúan configuraciones; los pipelines conservan resultados vinculados a una versión del software y de la propia política.

Ejemplo: controles de una entrega

Momento	Comprobación	Evidencia
Cambio	Análisis de código y secretos	Informe del pipeline
Construcción	Componentes y procedencia	SBOM y evidencias firmadas
Despliegue	Política de configuración y permisos	Decisión y versión de la regla
Operación	Cambios respecto al estado esperado	Registro y acción de corrección

Del requisito al control automático

Requisito (ejemplo)	Control técnico	Herramienta
Los datos en reposo deben estar cifrados	Todo bucket y base de datos con cifrado y CMEK	Política sobre el plan de Terraform
Acceso a producción con mínimo privilegio	Sin roles de propietario a personas; acceso temporal	Escáner de IAM, JIT PAM
Cambios revisados por otra persona	Protección de rama con aprobación obligatoria	Configuración del repositorio, auditada
Software sin vulnerabilidades críticas conocidas	Escaneo de dependencias e imágenes	Trivy, Grype en CI
Trazabilidad de lo desplegado	Imagen firmada con SBOM	Cosign, SBOM
Registros de auditoría conservados	Logs de auditoría activos y retención mínima	Política de nube + verificación periódica

Política como código sobre un plan de Terraform

# policy/storage.rego
package main
import rego.v1

deny contains msg if {
  some r in input.resource_changes
  r.type == "google_storage_bucket"
  not r.change.after.uniform_bucket_level_access
  msg := sprintf("%s: debe usar uniform bucket-level access", [r.address])
}

deny contains msg if {
  some r in input.resource_changes
  r.type == "google_storage_bucket"
  r.change.after.labels.clasificacion == "confidencial"
  not r.change.after.encryption
  msg := sprintf("%s: datos confidenciales requieren clave gestionada (CMEK)", [r.address])
}

terraform plan -out plan.bin && terraform show -json plan.bin > plan.json
conftest test plan.json --policy policy/

La misma lógica se aplica en Kubernetes con Gatekeeper o Kyverno, y en la nube con políticas de organización.

Evidencia automática

Cada ejecución del pipeline guarda: versión del código, versión de las políticas, resultados de cada control, aprobaciones y artefactos firmados. Ante una auditoría, en lugar de capturas de pantalla reunidas a mano, se entrega un informe generado a partir de esos registros. Formatos como OSCAL (NIST) permiten expresar controles y evidencias de forma estructurada.

Gestión de excepciones

# excepciones.yaml
- control: bucket-uniform-access
  recurso: google_storage_bucket.legacy_exports
  motivo: Integración con proveedor que requiere ACL por objeto
  aprobado_por: seguridad@krediya.example
  vence: 2026-12-31
  ticket: SEC-412

Las excepciones son explícitas, tienen dueño y caducan; el pipeline vuelve a fallar al vencer. Sin este mecanismo, los equipos desactivan controles y nadie lo sabe.

Métricas

Porcentaje de controles automatizados, tiempo medio de remediación por severidad, excepciones activas y vencidas, y deriva detectada en producción. Plataformas como Plerion o herramientas abiertas como Prowler cubren la parte de evaluación continua del entorno desplegado.

Criterios de implementación

Cada control necesita un responsable, un resultado comprensible y un procedimiento de excepción con vencimiento. Automatiza lo comprobable y documenta qué requiere evaluación humana. Un pipeline aprobado solo demuestra el alcance de los controles ejecutados.