¿Qué hacer después de tu primer escaneo de seguridad?

Corriste tu primer escaneo de seguridad. Tienes una lista de hallazgos frente a ti. Tal vez son 8, tal vez son 40. La primera reacción natural es el pánico.

Respira. Esto es normal, y tener visibilidad es mejor que no tenerla. Lo que haces después del escaneo de seguridad es lo que determina si el scan valió la pena o fue solo una métrica.

Esta guía te dice exactamente qué hacer con esos resultados.

Primero: entiende qué significan las severidades

No todos los hallazgos son iguales. La severidad te dice cuánto riesgo representa cada uno.

Severidad	Qué significa	Cuándo arreglar
Crítico	Explotable directamente, impacto alto	Hoy mismo
Alto	Riesgo real pero puede requerir condiciones específicas	Esta semana
Medio	Debilidad que puede amplificar otros ataques	Este sprint
Bajo	Mala práctica, riesgo bajo en aislamiento	Próximo sprint
Informacional	Sin riesgo directo, pero vale saber	Cuando haya tiempo

La trampa común es intentar arreglarlo todo de una vez. No funciona así. Priorizar por severidad no es tomar atajos — es gestión de riesgo realista.

Los hallazgos que siempre van primero

Secretos expuestos — arregla ahora

Si el scan encontró una API key, token, o contraseña en tu código, eso es crítico sin excepción. No importa si es un proyecto pequeño o si "nadie lo va a ver".

Los scripts automatizados escanean GitHub constantemente. Un secreto expuesto puede ser encontrado y explotado en minutos.

Pasos inmediatos:

Rota la credencial — en el panel del servicio correspondiente, genera una nueva key
Mueve el valor a variables de entorno — process.env.TU_KEY
Verifica el historial de Git — cambiar el .env no borra el historial

# Busca si el secreto está en commits anteriores
git log -S "sk_live_" --all --oneline
 
# Si está en el historial, necesitas limpiar el historial también
# Usa git-filter-repo (más seguro que filter-branch)
pip install git-filter-repo
git filter-repo --replace-text <(echo "sk_live_XXXXXXXX==>REMOVED")

Si ya hiciste push de un secreto a un repo público, asume que está comprometido. Rota primero, luego limpia el historial.

Endpoints sin autenticación — arregla esta semana

Si el scan encontró rutas de API que no verifican quién hace la petición, cualquiera con la URL puede acceder a esos datos. Broken Access Control es el #1 del OWASP Top 10.

// Lo que probablemente tienes:
app.get("/api/users/:id", async (req, res) => {
  const user = await db.users.findById(req.params.id);
  return res.json(user);
});
 
// Lo que necesitas:
app.get("/api/users/:id", requireAuth, async (req, res) => {
  // verifica que el usuario solo puede ver su propio perfil
  if (req.params.id !== req.user.id && !req.user.isAdmin) {
    return res.status(403).json({ error: "No autorizado" });
  }
  const user = await db.users.findById(req.params.id);
  return res.json(user);
});

Dependencias vulnerables: cómo evaluar cuáles importan

Después de los secretos y la autenticación, la siguiente prioridad son las dependencias con CVEs.

Aquí no todo es igual. Antes de actualizar algo, pregúntate:

¿Esta dependencia toca datos de usuario o hace requests externos? Si sí — alta prioridad. Si es una dependencia de build o de desarrollo que nunca llega a producción — puede esperar más.

¿El CVE es explotable en mi caso de uso? Algunos CVEs requieren condiciones muy específicas para ser explotados. Lee la descripción del hallazgo. Si el vector de ataque requiere acceso local al servidor y tu app es una API web, el riesgo real es diferente.

# Actualiza solo lo que realmente necesitas actualizar
npm update nombre-del-paquete
 
# Verifica que nada se rompió antes de commitear
npm test

Configuración insegura: los hallazgos que más se ignoran

Los hallazgos de configuración tienden a acumularse porque no parecen urgentes. Un header de seguridad faltante no te hackea solo — pero hace más fácil otros ataques.

Los más importantes:

Content-Security-Policy faltante — facilita ataques XSS
X-Frame-Options ausente — permite que tu app sea embebida en iframes (clickjacking)
CORS demasiado permisivo — permite que sitios externos accedan a tu API

Puedes revisar los headers de tu URL deployada en un minuto para ver cuáles tienes y cuáles faltan.

Cómo manejar los falsos positivos

Los scanners no son perfectos. Van a marcar cosas que en tu contexto específico están bien.

Ejemplo: el scanner detecta que usas eval() en tu código. En la mayoría de casos eso es una vulnerabilidad — pero si lo estás usando para parsear un valor de configuración que tú mismo controlas, el riesgo real es diferente.

Cómo manejarlos bien:

Lee la descripción completa del hallazgo
Verifica el contexto en tu código
Si es realmente un falso positivo, documenta el razonamiento
Márcalo como aceptado o suprimido con una justificación

Lo que no debes hacer: marcar todo como falso positivo sin revisar. Es la forma más rápida de tener una ilusión de seguridad sin seguridad real.

Tu plan para las próximas 48 horas

Si acabas de hacer tu primer scan, aquí está el orden:

Ahora mismo: Rota cualquier secreto expuesto que encontraste
Hoy: Revisa los hallazgos críticos y altos — entiende cada uno
Esta semana: Arregla los críticos, crea tickets para los altos
Este sprint: Ataca los medios, planea los bajos para después
Próximo sprint: Revisa los informacionales, actualiza el backlog

No tienes que arreglar todo de un golpe. Lo que sí tienes que hacer es no ignorar los críticos.

El plan gratuito de Data Hogo te da 3 scans al mes. Úsalos: uno para la línea base, uno después de tus fixes, y uno antes del próximo deploy importante.

Escanea tu repo gratis →

Preguntas frecuentes

¿Qué hago primero después de un escaneo de seguridad?

Empieza con los hallazgos críticos que involucren secretos expuestos o falta de autenticación — estos tienen el mayor impacto y generalmente son los más rápidos de arreglar. Luego sigue con dependencias vulnerables con CVEs altos. Los findings de severidad baja o informacional pueden esperar al siguiente sprint.

¿Cuántas vulnerabilidades es normal tener en un proyecto?

Depende del tamaño y madurez del proyecto. Un proyecto nuevo con unas semanas de desarrollo puede tener 5-15 hallazgos. Un proyecto de producción con más de un año sin scan puede tener 30 o más. Lo importante no es el número — es la severidad y si hay hallazgos críticos sin resolver.

¿Cómo sé si un hallazgo de seguridad es un falso positivo?

Lee la descripción del hallazgo y verifica el contexto en tu código. Si el scanner marcó un patrón que en tu caso específico está protegido por otra capa de seguridad, puede ser un falso positivo. Documenta el razonamiento y márcalo como aceptado con una justificación.

¿Debo arreglar todas las vulnerabilidades antes de hacer deploy?

No necesariamente todas. Deberías resolver los hallazgos críticos y altos antes de deploy a producción. Los medios y bajos pueden gestionarse en el siguiente sprint. Un proyecto con solo findings de severidad baja es considerado en buen estado de seguridad.