Gestión de vulnerabilidades en una plataforma de servicios inmobiliarios digital

El negocio era — y es — digital de verdad: portales web públicos con gran volumen de tráfico, APIs de integración con terceros (tasadoras, portales, entidades) y un ciclo de despliegues frecuente que negocio y marketing empujaban sin pausa. Cada campaña nueva significaba una landing nueva; cada acuerdo con un tercero, una integración nueva. La seguridad iba por detrás: escaneos ocasionales, sin inventario completo de activos web y sin un proceso que conectara los hallazgos con el equipo de desarrollo.

El síntoma más revelador apareció el primer mes: webs de campañas antiguas que seguían publicadas y que TI ni siquiera sabía que existían. Ningún escaneo puntual las habría cubierto, porque no estaban en ninguna lista. Y todo ese parque expuesto procesaba datos de clientes — solicitudes, valoraciones, datos de contacto — en un sector donde la confianza es el producto. Una vulnerabilidad crítica en un portal público no era un tecnicismo: era un titular potencial.

1. Descubrimiento continuo de activos web — rastreo recurrente de dominios, subdominios, certificados y registros DNS para mantener un inventario vivo. La primera pasada destapó webs de campañas y microsites de agencias que TI no controlaba; tres años después, cada activo nuevo que se publica aparece en el inventario en días, no cuando alguien lo recuerda.
2. Escaneo recurrente de aplicaciones e infraestructura expuesta — análisis periódico de los portales de gran tráfico, las APIs de integración y la infraestructura que los sirve. Los hallazgos típicos del día a día: librerías JavaScript desactualizadas, cabeceras de seguridad y configuraciones TLS débiles, algún XSS y controles de acceso mejorables en APIs.
3. Priorización con contexto de negocio, no solo con CVSS — la pregunta que ordena la cola no es "¿qué puntuación tiene?" sino "¿esto está en internet y procesa datos de clientes?". Una vulnerabilidad media en un portal público con tráfico real puede ir por delante de una alta en un sistema interno.
4. Resolución integrada en el ciclo de releases de desarrollo — los hallazgos llegan como tickets al backlog del equipo, con severidad, contexto y pasos de corrección; las críticas en activos públicos tienen SLA pactado y entran en la siguiente release o en un hotfix. Tras cada despliegue se reescanea para verificar el cierre.
5. Terceros y agencias dentro del perímetro — las webs administradas por proveedores se escanean igual, y los hallazgos se trasladan con plazos y evidencia. Con el tiempo, los requisitos mínimos de seguridad y los plazos de corrección acabaron escritos en los contratos con agencias.
6. Seguimiento constante con métricas de tendencia — reuniones periódicas con TI y desarrollo donde no se revisa una lista, sino una tendencia: activos nuevos descubiertos, tiempo de resolución por severidad, deuda acumulada y reincidencias. Es lo que convierte un escáner en un programa.

El cambio de fondo no es una cifra, es un hábito: cuando aparece una vulnerabilidad crítica en un portal público, ya existe el circuito para resolverla — quién la recibe, con qué plazo, en qué release sale y quién verifica el cierre. Las librerías JavaScript desactualizadas, las cabeceras débiles y los controles de acceso mejorables en APIs siguen apareciendo, porque el negocio sigue desplegando; la diferencia es que ahora se detectan, se priorizan con contexto y se cierran dentro de un plazo conocido.

Tres años dan también para lo que un escaneo puntual nunca ve: la deuda que baja release a release, las webs de campañas que se retiran cuando dejan de usarse en vez de quedarse publicadas para siempre, y unas agencias que ya entregan sabiendo que su trabajo se va a escanear. El programa no ha frenado el ritmo de negocio y marketing — se ha integrado en él.