La postura de seguridad como sistema observable
Convierte los escaneos mensuales de seguridad en la nube en métricas dimensionales, señales de frescura y un dashboard de triaje útil.
La visibilidad por lotes incluye dimensiones de riesgo y la frescura de los escaneos; no es detección de amenazas en tiempo real.
Contribución de un vistazo
- Mi responsabilidad
- Exporter de resultados de seguridad, enriquecimiento de métricas, creación de dashboards y controles de secretos acotados.
- Alcance
- Visibilidad de escaneos por lotes, más cambios en el escáner y en la gestión de secretos validados por separado.
- Colaboración y límites
- Construí visibilidad de la infraestructura y controles reversibles; este trabajo no es una afirmación de detección de amenazas en tiempo real ni de cobertura completa de vulnerabilidades.
- Resultado
- El riesgo y la frescura de los escaneos se volvieron observables. El trabajo relacionado verificó la alcanzabilidad de las sondas y controles reversibles de versiones de secretos dentro de los alcances registrados.
El problema
Los informes periódicos de seguridad en la nube requerían un triaje manual. Un informe puntual dificultaba comparar los hallazgos entre proyectos y servicios, o ver si el escaneo subyacente se había quedado obsoleto.
Mi contribución
Conecté los resultados de escaneos mensuales de 14 proyectos en la nube a un pipeline de métricas y a un dashboard de Grafana. El trabajo incluyó el enriquecimiento de CSV, un pequeño exporter, un despliegue de Pushgateway, la configuración de Prometheus y vistas de dashboard por proyecto, servicio y riesgo.
Las decisiones
El escáner es un proceso por lotes, no un servicio de larga duración. Enviar los resultados a un gateway le permite a Prometheus hacer scrape de ellos después de que el job termina. Las métricas exportadas distinguen los tipos de hallazgo, los recursos afectados y el momento del último escaneo; eso representa preguntas diferentes y no debería combinarse en un único conteo.
Mantuve el exporter sin dependencias para que pudiera correr en la imagen existente del escáner, y preservé las labels necesarias para el drill-down por proyecto/servicio/riesgo. La marca de tiempo del escaneo es esencial: un dashboard que todavía muestra los resultados del mes anterior no debe dar a entender que se trata de un escaneo reciente.
Resultados y medición
El registro de la entrega incluye un dry run que cubrió los 14 proyectos, un push end-to-end exitoso, la confirmación de que Prometheus almacenó la métrica y un dashboard poblado con resultados en vivo.
La cadencia de escaneo es mensual. La visibilidad del dashboard entre ejecuciones no convierte esto en detección de vulnerabilidades en tiempo real. Aquí no se afirma nada sobre una reducción verificada de forma independiente de incidentes de seguridad o de hallazgos.
Hacer que el escaneo sea repetible y útil
En una modernización anterior del pipeline, moví las dependencias del escáner a una imagen versionada, paralelicé los escaneos y las subidas, corregí el manejo de la salida y reduje el ruido relacionado con los permisos. La ejecución end-to-end registrada bajó de unos 50 minutos a 15 minutos para ese conjunto de proyectos. El despliegue posterior del dashboard cubrió 14 proyectos; los dos alcances de validación no deberían fusionarse en un único benchmark.
Un verificador de políticas de bucket aparte se refactorizó con workers acotados, resultados tipados y mensajes de reporte accionables. Registró 80 pruebas unitarias y un 93.62% de cobertura. Una salida correcta seguía mostrando fallas reales de políticas; reparar el verificador no significó que todos los buckets quedaran en conformidad.
Demostrar que el escáner alcanzó sus objetivos
Reparé un escáner de exposición de configuración para que un host inalcanzable no pudiera confundirse con una respuesta limpia. La ejecución final registrada recibió respuestas HTTP para 5,681 sondas en 299 hosts y 19 variantes de ruta, con cero fallas de conexión. Su runtime fue de unos 0.9 minutos, frente a unos nueve minutos anteriormente.
En esa ejecución no se identificó ningún archivo de configuración expuesto. Ese es un resultado para las rutas y las respuestas probadas, no una afirmación de que todos los servicios estuvieran libres de vulnerabilidades.
Llevar la misma disciplina a los secretos
Hice un piloto de External Secrets Operator con Secret Manager en tres repositorios, con 16 ExternalSecrets y actualizaciones de 12 aplicaciones de ArgoCD. Desarrollo, staging y sandbox usaron workload identity; la ruta de producción heredada conservó una excepción de clave de service account.
También cambié un workflow destructivo de actualización de secretos para que preservara los campos existentes. Una validación en desarrollo agregó un campo mientras conservaba los 183 originales, luego eliminó el campo de prueba y restauró el conteo original. Una normalización posterior deshabilitó de forma reversible 133 versiones más antiguas en 97 secretos de cuatro proyectos, conservando la última versión habilitada en lugar de destruir las opciones de recuperación.
Estos son controles acotados y registros de validación. No establecen que cada credencial se haya rotado, que cada aplicación haya usado una identidad dedicada, ni que Vitor haya certificado de forma independiente a la organización.
Lo que aprendí
El reporte de seguridad se convierte en una capacidad operativa cuando sus dimensiones, su frescura y su responsabilidad son claras. Un conteo total por sí solo no puede decirle a un equipo dónde actuar ni si la fuente sigue estando vigente.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Mantener solo informes estáticos es barato, pero dificulta inspeccionar la frescura y las tendencias. Las métricas exportadas agregan visibilidad compartida y responsabilidad de mantenimiento.
Contrapartida
Los datos obsoletos pueden parecer tranquilizadores; la alcanzabilidad del escaneo y las marcas de tiempo deben mantenerse separadas del número de hallazgos.
Lo que mejoraría a continuación
Próxima mejora: probar alertas de escaneos obsoletos y documentar la responsabilidad del triaje y la caducidad de las excepciones de cada control.