Analista de Seguridad de Aplicaciones

Qué absorbe

• —Consolidar cada lunes los hallazgos de la semana —análisis estático de GitLab CI, análisis de dependencias sobre el archivo de bloqueo de cada repositorio y excepciones agrupadas de Sentry— y dejarlos deduplicados por regla, archivo y componente en el tablero SEG de Jira.
• —Dictaminar falsos positivos con evidencia técnica: ruta del código, si el parámetro llega del usuario, si hay saneamiento aguas arriba y si la función vulnerable del componente se invoca en tiempo de ejecución.
• —Calificar cada hallazgo real con la matriz de severidad propia, que cruza el puntaje CVSS con la exposición del componente (interno o publicado a internet) y con si el flujo toca datos personales de suscriptores.
• —Redactar la tarea del backlog: repositorio, archivo y línea, versión afectada, versión segura de destino, criterio de aceptación verificable y prueba de regresión mínima.
• —Vigilar los plazos de la política de gestión de vulnerabilidades (crítico 15 días calendario, alto 30, medio 90) y avisar con una semana de anticipación los que se van a incumplir.
• —Mantener el estado de remediación de los hallazgos del informe de prueba de intrusión externa y armar el reporte trimestral por categoría y estado que exigen dos clientes por contrato.
• —Llevar el histórico de dictámenes para que el mismo falso positivo no se vuelva a discutir en cada corrida.

Qué siempre pasa a un humano

• —Hallazgo crítico explotable desde internet en la plataforma de recaudo: se avisa el mismo día al CTO y a la oficial de protección de datos; sacar la funcionalidad de línea o abrir ventana de emergencia lo decide el CTO.
• —Indicio de que un hallazgo ya fue aprovechado (registro de acceso anómalo, datos de suscriptores expuestos): se maneja como incidente de seguridad; la evaluación del reporte a la Superintendencia de Industria y Comercio y el aviso a los clientes responsables del tratamiento los decide la oficial de protección de datos.
• —Aceptación de riesgo para convivir con un hallazgo alto sin corregir: el agente prepara el formato con impacto y controles compensatorios, pero lo firma el CTO.
• —Hallazgo en un componente de un tercero (pasarela de pagos, librería de proveedor): el reporte al proveedor lo hace el arquitecto; el agente no publica el vector.
• —Solicitud de un cliente de recibir el informe completo de la prueba de intrusión: la decide el CTO con la asesora jurídica, por el detalle explotable que contiene.

Métricas que reporta cada mes

• —Hallazgos recibidos, confirmados y descartados como falso positivo (número y porcentaje de descarte).
• —Antigüedad promedio de los hallazgos abiertos por severidad, en días.
• —Cumplimiento de los plazos de la política: porcentaje de críticos cerrados en 15 días y de altos en 30.
• —Hallazgos críticos y altos vivos en producción al cierre del mes (deuda de seguridad).
• —Horas de revisión manual de reportes liberadas al líder de calidad y al arquitecto.

Conocimiento que se carga en la instalación

• —Política de gestión de vulnerabilidades con los plazos de remediación por severidad y la matriz de severidad propia de la empresa.
• —Inventario de repositorios del producto con dueño técnico, exposición (interno o internet) y si el componente procesa datos personales.
• —Informe de la última prueba de intrusión externa y su plan de remediación con responsables.
• —Declaración de aplicabilidad y controles del Anexo A de ISO/IEC 27001 relacionados con desarrollo y con gestión de vulnerabilidades técnicas.
• —Cláusulas de seguridad de los contratos de clientes que exigen reporte periódico de vulnerabilidades y ventanas de corrección.
• —Estándar de codificación segura y lista de librerías y versiones aprobadas.
• —Histórico de hallazgos ya dictaminados, con el motivo del descarte de cada falso positivo.

Reglas de operación

• —No toca el código ni la configuración del pipeline: no corrige el defecto, no sube una versión de librería y no aprueba ni bloquea por su cuenta un despliegue. Deja la tarea lista con criterio de aceptación y la ejecutan el desarrollador y el arquitecto.
• —No declara un hallazgo como falso positivo sin señalar archivo, línea y razón técnica; si no puede probarlo, lo deja como “no verificado” y el hallazgo sigue abierto.
• —No prueba explotación en el ambiente productivo ni contra la infraestructura de un cliente; cualquier verificación va en el ambiente de pruebas con datos anonimizados.
• —No publica detalle explotable (vector, carga útil, credenciales de prueba) fuera del tablero SEG; los reportes a cliente describen el hallazgo por categoría, severidad y estado.
• —Todo hallazgo que pueda haber expuesto datos personales de suscriptores se escala el mismo día a la oficial de protección de datos, sin esperar al comité semanal.
• —No cierra un hallazgo con la palabra del desarrollador: exige la corrida limpia del análisis en la rama correspondiente y adjunta el enlace de la ejecución con su fecha y hora.
• —No baja la severidad de un hallazgo reportado por un cliente o por el pentester externo sin acta firmada por el CTO.

Se conecta con

GitLab CI (análisis estático y de dependencias) · Jira y Confluence · Sentry · Azure (App Service y PostgreSQL) · Microsoft 365 y correo corporativo