Contenido detallado
🎯 El objetivo del escáner
La auditoría de seguridad suele ser un evento poco frecuente: alguien ejecuta algunas herramientas antes de un deploy importante y se olvida de ellas el resto del tiempo. Con IA local ilimitada y siempre encendida, puedes invertirlo: un worker recorre tu repositorio continuamente, en busca de secretos filtrados, dependencias vulnerables y patrones inseguros, sin que gastes nada más que electricidad.
🆕 ¿Eres nuevo por aquí?
"Secreto" es cualquier credencial que se filtre al código por accidente: clave de API, token, contraseña de base de datos. "Escáner de seguridad" es un programa que lee el código para buscar estos secretos y otros riesgos conocidos. Aquí se convierte en un worker 24/7: un proceso que funciona solo, en ciclo, sin que tengas que presionar el botón.
🔑 Qué busca este empleado
- •Secretos filtrados: claves de API y contraseñas que se incluyeron en el commit por descuido.
- •Dependencias vulnerables: bibliotecas con CVE conocidos (npm, pip).
- •Patrones inseguros: cosas sospechosas que merecen la atención de un revisor.
- •Qué hay de nuevo: avisar solo cuando aparezca algo que ayer no existía.
📊 Por qué esto solo tiene sentido en local
- El escaneo continuo implica muchas llamadas al modelo. En la nube, cada llamada tiene un costo; usarlo 24/7 se vuelve caro rápidamente.
- Tu código fuente es sensible: enviarlo a un servidor de terceros solo para «analizarlo» es precisamente lo que quieres evitar.
- Local resuelve las dos cosas a la vez: es ilimitado e privado. El código nunca sale de la máquina.
🗺️ Diseño de la solución
Antes del código, el diseño. El secreto de un buen escáner no es echarle todo al LLM: es una cinta transportadora: herramientas económicas y precisas detectan; el modelo local solo evalúa y explica, y cron lo repite. Cada pieza hace lo que mejor sabe hacer.
Lee de izquierda a derecha: el repositorio alimenta las herramientas deterministas (paso 1), los hallazgos van al modelo local que evalúa el riesgo (paso 2) y devuelve un informe fechado. La flecha cian de abajo es el cron (paso 3), cerrando el ciclo 24/7.
Estos tres pasos son exactamente las próximas tres secciones. En resumen:
Primero, escaneo determinista
Herramientas como gitleaks e npm audit encuentran secretos y CVE con precisión: son rápidas, económicas y no alucinan. Se encargan de la detección inicial.
El modelo local clasifica los hallazgos
Entra el LLM después: lee la lista de hallazgos, clasifica el riesgo (alto/medio/bajo) y sugiere una corrección en lenguaje claro. Explica, no inventa.
Cron programa y mantiene el funcionamiento 24/7
Un programador ejecuta el script cada pocas horas y guarda relatorio-AAAA-MM-DD.md y solo te avisa cuando aparece algo nuevo. Sin ruido.
🔍 Paso 1 · exploración determinística
La tentación es pedirle al LLM «encuentra los problemas de seguridad». No hagas esto primero. Un modelo puede pasar por alto un secreto obvio o inventar uno que no existe. Las herramientas determinísticas —que siempre dan la misma respuesta para la misma entrada— detectan con precisión quirúrgica. Ejecútalas primero. El LLM entra solo en el paso 2.
⌨️ Copy-run: las herramientas que detectan
Objetivo: encontrar secretos filtrados y dependencias vulnerables sin tocar el modelo. Ejecútalo en la raíz de tu proyecto.
Cómo verificar: si hay un secreto, el gitleaks termina con un código distinto de cero y enumera el archivo + la línea. El npm audit / pip-audit imprimen los CVE con su severidad. Repo limpio = salida vacía y exit 0.
💡 Consejo práctico
Combina ambos mundos a propósito: la herramienta determinista es necesaria pero tonta (encuentra el patrón, no entiende el contexto); el LLM es flexible pero falible (entiende, pero puede equivocarse). Deja que cada uno haga lo que mejor sabe: la herramienta detecta y el modelo explica. Nunca al revés.
🤖 Paso 2 · el agente revisa
Ahora el modelo local adquiere una utilidad real. No busca nada: recibe la lista de hallazgos de las herramientas y hace lo que haría una persona en una revisión: asigna un nivel de riesgo a cada elemento y explica la corrección en una línea. Llamas al modelo mediante API local compatible con OpenAI (la de Ollama, de la ruta 3.5).
⌨️ Copy-run: el modelo local clasifica un hallazgo
Objetivo: enviar un hallazgo al modelo y recibir el riesgo + la corrección. Endpoint localhost — nada sale de la máquina.
Cómo verificar: la respuesta JSON incluye .choices[0].message.content con algo como "Riesgo: alto — revoca la clave en AWS, elimínala del historial y usa una variable de entorno." Una temperature una temperatura baja mantiene la clasificación consistente.
El punto clave es la división del trabajo: el modelo es excelente para priorizar y explicar, pero pésimo como fuente de verdad. Mira cuándo confiar en él y cuándo no:
✓ Buen uso del modelo
- ✓Prioriza: qué es realmente grave frente al ruido
- ✓Explicar el riesgo en lenguaje claro
- ✓Sugerir la corrección concreta
- ✓Resumir 50 hallazgos en un párrafo
✗ Uso indebido del modelo
- ✗Ser el único que «busca» secretos
- ✗Confiar en él para que diga que todo está limpio
- ✗Aplicar correcciones por tu cuenta, sin que las veas
- ✗Inventar CVE que la herramienta no encontró
⏰ Paso 3 · programar 24/7
La detección + el triage se convierten en un empleado cuando se ejecutan solas. Aquí es donde el cron (el programador por tiempo, de la sección 4.2) entra en acción: ejecuta el script cada pocas horas, guarda un informe fechado y — la parte que te mantiene cuerdo — solo te molesta cuando hay algo nuevo desde la última ronda.
⌨️ Copy-run principal: el script de la cadena
Objetivo: juntarlo todo: gitleaks detecta, la API local clasifica y sale relatorio-AAAA-MM-DD.md. Guárdalo como scan.sh.
Cómo verificar: ejecuta bash scan.sh una vez. Debe aparecer ok: relatorios/relatorio-2026-06-29.md y el archivo debe contener la clasificación del modelo. Todo mediante localhost.
⏱️ Copy-run: dejarlo funcionando 24/7
Objetivo: ejecutar cada 6 horas, automáticamente. Abre crontab -e y agrega:
Cómo verificar: después de unas horas, revisa ~/scan.log y la carpeta relatorios/ ganando archivos fechados. Para «alertar solo cuando haya algo nuevo», compara el informe de hoy con el de ayer (diff) y notifica solo si hay alguna diferencia.
💡 Consejo práctico
El enemigo de un worker 24/7 es la fatiga de alertas: si te avisa en cada ronda, dejarás de leer. Por eso, "alertar solo sobre lo nuevo" no es un detalle: es lo que decide si confiarás en el empleado o lo silenciarás durante la primera semana.
🔒 Fortaleciendo el worker
Funciona: ahora hazlo confiable. Un scanner que grita falsos positivos todo el día o que se sale del alcance se convierte en otro ruido que se ignora. Y hay una línea que no se cruza: el código no va a ninguna parte. Estas prácticas distinguen un juguete de un empleado en quien confías.
✓ Hazlo
- ✓Mantener el modelo 100% local (endpoint localhost)
- ✓Definir el alcance: carpetas y tipos de archivo que importan
- ✓Mantener una allowlist de falsos positivos conocidos
- ✓Tratar el informe como una sugerencia: tú decides y corriges
✗ Evita
- ✗Enviar fragmentos de código a una API en la nube «solo para ayudar»
- ✗Permitir que el agente aplique correcciones sin revisión humana
- ✗Escanear todo sin delimitar el alcance (lento y lleno de ruido)
- ✗Confiar en que «sin alerta» = «100% seguro»
⚠️ Recuadro de alerta: la regla de oro
Todo el sentido de este worker es recorrer código sin exponer código. Si en algún momento envías los hallazgos — o peor, los fragmentos — a un servicio de terceros, perdiste: creaste una nueva filtración mientras buscabas filtraciones.
- •Todo local: las herramientas y el modelo se ejecutan en tu máquina; el tráfico no sale de localhost (o de tu tailnet privada).
- •Revisión humana: el scanner prioriza y sugiere; quien revoca una clave y abre un PR eres tú.
Autoevaluación (opcional): ¿por qué ejecutar gitleaks / npm audit ¿ANTES de llamar al modelo local?
📌 Resumen del módulo
Siguiente módulo:
4.4 — Vigilante de la web en busca de oportunidades