Este año, publiqué un informe de la industria llamado Remediación a escala que analiza cómo los equipos de seguridad de aplicaciones (AppSec) solucionan las vulnerabilidades en su código. El conjunto de datos: decenas de miles de repositorios, un año completo de datos escaneados y organizaciones que van desde nuevas empresas hasta empresas. En total, más de 127 millones de puntos de datos que abarcan hallazgos individuales, eventos de escaneo y acciones de remediación en dos tipos de escaneo de seguridad (SAST y SCA).
Soy PMM técnico sénior en Semgrep con experiencia en informática, ciencia de datos e ingeniería de soluciones. Me gusta construir cosas. Este proyecto me permitió combinar todo eso en un solo movimiento: escribir SQL, crear scripts para gestionar el análisis, analizar y limpiar los datos, encontrar la historia que cuentan los datos y enviar el activo final pulido.
Esta publicación recorre cinco lecciones que aprendí a lo largo del camino. Si alguna vez ha tenido que tomar un conjunto de datos masivo, encontrar la narrativa que contiene y convertirlo en algo sobre lo que una audiencia técnica y no técnica pueda actuar, algo de esto podría ser útil.
1. Comience con los datos, no con la historia
La tentación con cualquier proyecto de datos es decidir primero su narrativa y luego buscar números que la respalden. Hice lo contrario.
Pasé semanas en modo pura exploración. Consultar Snowflake, observar distribuciones y ejecutar agregaciones en diferentes dimensiones. Ninguna hipótesis, ningún ángulo. Solo trato de entender qué mostraron realmente los datos.
Esto fue incómodo. Las partes interesadas querían saber qué diría el informe. No tuve una respuesta todavía.
Pero resultó ser la fase más importante de todo el proyecto. Los datos contaron una historia que no habría imaginado: la brecha entre los equipos de seguridad de alto rendimiento y todos los demás no se debía a las herramientas. Se trataba de un seguimiento sistemático de la remediación. Nunca habría llegado a ese marco si hubiera empezado con una tesis.
También debes estar dispuesto a matar a tus seres queridos. Hubo varios hallazgos que quería que fueran ciertos y que los datos no respaldaban. Por otro lado, algunas de las ideas más interesantes provinieron de lugares que no estaba mirando. Utilicé LLM locales a través de Ollama para clasificar más de 10 000 registros de clasificación basados en texto en 20 categorías temáticas. Lo que surgió fue un patrón claro: los temas más comunes fueron sobre archivos de prueba, protecciones de marco y servicios confiables. Eso contó una historia sobre cómo los equipos realmente usan herramientas de clasificación que nunca habría encontrado al observar las métricas agregadas.
Algunas cosas que ayudaron durante la exploración:
Ejecute primero las consultas de diagnóstico. Creé un conjunto de más de 12 controles de calidad de datos antes de tocar el análisis. Uno de ellos detectó que una métrica clave (parse_rate) solo tenía cobertura para una fracción de los repositorios. Cambié a un campo alternativo (NUM_BYTES_SCANNED) con una cobertura superior al 90%. Sin ese diagnóstico, todo el análisis de los hallazgos por línea de código se habría calculado mal. Cree un punto de control/currículum en su canalización. Tuve más de 108 consultas SQL en varias secciones del informe. Escribí un script de shell que descubría automáticamente archivos .sql, rastreaba cuáles ya habían producido archivos CSV de salida y los omitía en las reejecuciones. Cuando las consultas fallaron a la mitad (y lo hicieron), pude continuar justo donde lo dejé en lugar de volver a ejecutar todo. Documente sobre la marcha. Cada resultado interesante, cada callejón sin salida, cada suposición. Ese registro en ejecución se convirtió en la columna vertebral de la sección de metodología del informe y me ahorró semanas cuando necesitaba volver sobre mis pasos.
2. Conviértete en un experto en el dominio
No puedes contar una historia sobre datos que no entiendes. Antes de poder escribir una sola sección, necesitaba saber cómo funcionan los escáneres de análisis estático, cómo funcionan los flujos de remediación en la práctica y qué métricas son realmente importantes para los equipos de seguridad.
Varias empresas del sector publican informes anuales sobre temas similares. Recopilé y leí tantos como pude encontrar. No copiar, sino comprender el formato, la profundidad y las expectativas. Leerlos me dio una sensación de:
Qué espera la industria de este tipo de recurso Qué ya está bien cubierto Dónde hay espacio para decir algo nuevo
Esto también me ayudó a detectar lagunas. La mayoría de los informes se centran en el volumen de detección. Muy pocos profundizan en lo que sucede después de la detección. Ese se convirtió en nuestro ángulo.
Saltarse esta fase habría significado escribir un informe lleno de observaciones superficiales que no se diferenciaran del resto de gran contenido producido por otros.
3. Habla con tu público objetivo desde el principio y con frecuencia
Las primeras versiones del análisis solo mostraban promedios. Tasa de reparación promedio, tiempo promedio para remediar, resultados promedio por repositorio. Los números estaban bien. La historia fue aburrida.
El gran avance se produjo después de hablar con profesionales reales: los ingenieros de seguridad, los líderes de AppSec y los CISO que leerían el producto final. Todos querían responder una pregunta: ¿cómo me comparo con equipos a los que les está yendo tan bien?
Esa retroalimentación dio forma directa a dos de las decisiones más importantes del informe.
En primer lugar, condujo a una segmentación basada en cohortes. Dividí las organizaciones en dos grupos: el 15% superior por tasa fija (“líderes”) y todos los demás (“el campo”). Esto es similar a cómo los informes basados en encuestas segmentan por nivel de madurez, excepto que usé datos de comportamiento en lugar de respuestas autoinformadas. De repente los datos tuvieron contraste:
Los líderes solucionan entre 2 y 3 veces más vulnerabilidades. Resuelven los hallazgos detectados durante la revisión del código 9 veces más rápido que los hallazgos de escaneos completos del repositorio. Adoptan funciones de automatización del flujo de trabajo a mayor velocidad y extraen más valor de ellas.
La segmentación fue la diferencia entre “aquí hay algunos números” y “aquí hay algo sobre lo que puedes actuar”.
En segundo lugar, reformó la estructura del informe. La gente no sólo quería puntos de referencia. Querían saber qué hacer con ellos. “Genial, la cohorte líder corrige más vulnerabilidades de seguridad del código. ¿Cómo puedo convertirme en líder?” Esos comentarios me llevaron a agregar una sección de recomendaciones basadas en evidencia organizada por velocidad de implementación:
Ganancias rápidas para esta semana Cambios de proceso para este trimestre Inversiones estratégicas para el semestre
El informe final se parece tanto a un libro de estrategias como a un punto de referencia. Nada de eso habría sucedido sin presentar los primeros borradores a lectores reales.
4. Involucrar al diseño desde el principio
Éste casi lo aprendí demasiado tarde. Los informes de datos viven o mueren según su apariencia. Una pared de gráficos sin jerarquía visual es tan mala como no tener ningún dato.
Traje a nuestro equipo de diseño antes de lo normal y dediqué tiempo a guiarlos por el dominio. ¿Qué significa “análisis de accesibilidad”? ¿Por qué es importante la división de cohortes? Cuando los diseñadores entendieron la historia, tomaron decisiones (codificación de colores para cohortes, cuadros de llamadas para ideas clave, ejemplos de códigos de antes y después) que la reforzaron sin que yo tuviera que explicarla en texto.
5. Date tiempo
Este proyecto tomó meses. La exploración de datos por sí sola duró semanas. Luego hubo iteraciones en el análisis a medida que encontré nuevos ángulos, ciclos de diseño, revisiones legales y rondas de comentarios de las partes interesadas de toda la empresa.
Si hubiera intentado enviar esto en un trimestre, el resultado habría sido olvidable.
donde aterrizó
Mirando hacia atrás, las dos cosas que cambiaría tienen que ver con la velocidad. Escribiría cada definición y suposición el primer día. Cosas como “qué cuenta como un repositorio activo” o “cómo calculamos la tasa fija” parecen obvias al principio. Se vuelven impugnados rápidamente. Finalmente creé un documento de definiciones formales que cubría más de 40 métricas, pero hacerlo antes me habría ahorrado varias rondas de reelaboración. Y traería un segundo par de ojos durante la exploración. Trabajar solo significaba que nadie tenía que comprobar si un hallazgo era interesante o simplemente ruido.
El informe en sí, Remediación a escala, cubre seis patrones respaldados por evidencia que separan a los equipos de seguridad de alto rendimiento del resto. Si ha abordado un proyecto similar de generación de informes con muchos datos, me gustaría saber qué aprendió a lo largo del camino.