Saltar al contenido

Guía

Cómo escanear código generado por IA en busca de secretos filtrados

Escanea el estado del repositorio, revisa la exposición en el frontend y el historial de Git por separado. Qué detecta vetkit y qué hacer si se filtra una credencial.

· 5 min de lectura · Por el equipo de vetkit

Un desarrollador ilumina con una linterna un montón de ventanas de código y encuentra una llave escondida, mientras un robot avergonzado se asoma por detrás del montón.Un desarrollador ilumina con una linterna un montón de ventanas de código y encuentra una llave escondida, mientras un robot avergonzado se asoma por detrás del montón.

Para escanear código generado por IA en busca de secretos filtrados, ejecuta un escáner de secretos sobre la versión del repositorio que vas a publicar, revisa la evidencia de archivo y línea, y revoca cualquier credencial expuesta. En vetkit, el Security Quick Scan incluye la detección de secretos en el repositorio; el historial de Git y la exposición de claves en el navegador requieren comprobaciones aparte. Un informe limpio cubre solo los archivos y los checks que realmente se ejecutaron.

1. Elige el alcance del escaneo

El código generado puede contener una credencial copiada, un marcador de posición realista o código que expone una clave solo al hacer el build de la aplicación. Son problemas distintos. Decide qué evidencia necesitas antes de interpretar el resultado:

PreguntaCheck relevanteLímite
¿Hay alguna credencial en los archivos escaneados del repositorio?Secrets (gitleaks), incluido en el Security Quick ScanDetección basada en patrones sobre el checkout, no una prueba de que no haya ninguna credencial
¿Se eliminó una credencial de los archivos actuales pero sigue en los commits?El analizador independiente secrets-history, cuando está disponible en el alcance de auditoría elegidoHistorial acotado; no forma parte del Quick Scan
¿Podría la configuración de build exponer una clave de proveedor a los navegadores?Los checks de aplicaciones LLM para los patrones de código compatibles, más tu propia inspección del buildNo forma parte del Quick Scan; una auditoría del código fuente no inspecciona los assets desplegados

2. Escanea la versión del repositorio que corresponde

  1. Conecta el repositorio en vetkit y selecciona el Security Quick Scan o un alcance de auditoría disponible que incluya la detección de secretos.
  2. Confirma el repositorio y la ref objetivo. Los escaneos de repositorios remotos no pueden ver el contenido sin guardar del editor ni los archivos locales que no hayas subido. No commitees un posible secreto solo para que se pueda escanear.
  3. Espera a que termine y revisa en los resultados de los analizadores si hay errores o checks omitidos antes de leer los hallazgos. Un escáner que no estaba disponible no es un check superado.

Si trabajas a través de un asistente, la guía de MCP para Claude Code y Cursor explica cómo elegir un repositorio y revisar los resultados de la auditoría. Usa marcadores de posición en los prompts; nunca pegues una credencial real en el asistente para preguntarle si es válida.

3. Revisa cada hallazgo

Lee la regla, la severidad, la ruta del archivo y la ubicación de la línea. Los hallazgos de secretos de vetkit usan fragmentos censurados; revisa el código fuente en privado para distinguir una credencial real de datos de prueba sintéticos. Los patrones genéricos pueden producir falsos positivos, y los formatos poco habituales pueden pasar desapercibidos. Una coincidencia por sí sola no establece si la credencial sigue activa.

Prioriza las credenciales que dan acceso a recursos en la nube, repositorios, publicación de paquetes o datos de producción. Anota el servicio afectado y el responsable de la remediación sin copiar el secreto en un ticket, una captura de pantalla o un chat. No descartes un hallazgo solo porque el asistente diga que el valor es un ejemplo.

4. Comprueba la exposición en el navegador y el historial

Una clave puede quedarse fuera de Git y aun así llegar a los usuarios a través del build del frontend. Revisa el uso de variables de entorno públicas, las llamadas al SDK del proveedor y la configuración del bundler, y luego inspecciona los assets generados para el navegador en un entorno que controles. Consulta la guía sobre API keys en el frontend para ver ejemplos. El escaneo del repositorio no hace automáticamente el build de tu aplicación con los secretos de despliegue ni examina los bundles del sitio en producción.

Si una credencial pudo haberse commiteado antes, incluye la comprobación independiente del historial cuando tu alcance de auditoría lo permita. Su ventana por defecto es de 500 commits como máximo y puede ser menor cuando el historial del checkout es más superficial. No es una búsqueda exhaustiva en todas las ramas, forks o copias del repositorio.

5. Responde y vuelve a escanear

  1. Revoca o rota la credencial expuesta con su proveedor. Borrar una línea o reescribir un commit no invalida una clave que ya se haya copiado.
  2. Lleva la nueva credencial a un almacén de secretos del lado del servidor o a un entorno de ejecución adecuado. Asegúrate de que no pueda acabar en el bundle del navegador ni imprimirse en los logs.
  3. Revisa los registros de acceso y uso del proveedor en busca de actividad inesperada. Coordina con los colaboradores del repositorio cualquier limpieza del historial; la rotación sigue siendo necesaria.
  4. Lanza un nuevo escaneo sobre la versión corregida y repite las comprobaciones de build o historial que correspondan. Guarda la versión objetivo de la auditoría junto con tu registro de remediación.

Fuentes y límites

Revisado el 1 de noviembre de 2026 con la configuración del Quick Scan de vetkit y las implementaciones de los analizadores gitleaks, secrets-history y de aplicaciones LLM. El Quick Scan ejecuta posture, gitleaks y OSV; no incluye todos los analizadores de una auditoría completa. La integración de gitleaks omite por defecto los archivos de más de 5 MB, y los escaneos están sujetos a límites de repositorio, de archivos y de tiempo. Revisa la cobertura y las advertencias de la ejecución real.

La documentación describe el flujo de auditoría, y el catálogo público de checks documenta las reglas propias. Ese catálogo no es una lista completa de las firmas de terceros de gitleaks. Esta guía describe los pasos de detección y remediación; ni un escaneo limpio ni una puntuación alta garantizan que una aplicación sea segura.

Solicita acceso anticipado

Cuéntanos un poco sobre tu equipo y los repositorios que quieres auditar. Incorporamos equipos en pequeños grupos y te responderemos por correo electrónico.

Solo usamos estos datos para responder a tu solicitud. Política de privacidad