Herramienta
Auditoría de seguridad de repositorios de GitHub
Sepa si puede fiarse de una librería antes de meterla en su stack
| Ficha de la herramienta | |
|---|---|
| ¿Qué es? | Una skill para Claude que evalúa el riesgo de un repositorio antes de integrarlo |
| Precio | Gratuita |
| Licencia | MIT |
| Versión | 1.1.1 |
| Idiomas | Español e inglés |
| Repositorio | github.com/Consultora-AMDT/claude-github-security-audit |
| Requiere | Claude.ai, Claude Desktop o Claude Code |
El problema
Aparece una librería que hace justo lo que necesita su equipo. Tiene estrellas, la documentación está cuidada y el código, a primera vista, parece limpio. ¿Entra en producción?
Esa decisión se toma a diario apoyándose en dos indicios frágiles.
El primero son las estrellas. Contabilizan a cuánta gente le pareció interesante el proyecto en algún momento, no si queda alguien al cuidado, ni si el último commit tiene catorce meses, ni si el mantenedor responde cuando se le escribe.
El segundo es la documentación, redactada por quien tiene interés en que usted la instale.
Ninguno de los dos avisa de que el proyecto depende de una sola persona ilocalizable, de que hay una credencial olvidada en el historial de commits, o de que la licencia le impide facturar trabajo construido encima.
Los datos existen, pero están repartidos entre ocho pestañas del repositorio, un fichero de licencia, un manifiesto de dependencias y un buscador. Casi nadie dedica veinte minutos a eso con cada candidato, así que la comprobación se salta y la herramienta entra por olfato.
Esta skill hace esos veinte minutos.
Qué mira, y por qué
Claude lee el repositorio y lo puntúa en siete dimensiones. Cada una responde a una pregunta distinta sobre un riesgo distinto.
Antes de nada: ¿le hace falta?
La primera fase no analiza seguridad. Pregunta si el problema que resuelve ese repositorio ya está cubierto por algo que usted tenga. Si lo está, el análisis se detiene ahí y se lo dice. Es la fase más barata y evita las otras seis más a menudo de lo que parece.
| Las siete dimensiones | |
|---|---|
| Salud del proyecto | Actividad, número de mantenedores, cadencia de commits, releases, documentación e integración continua. La pregunta es si queda alguien en casa. |
| Seguridad del código | Credenciales escritas en el código, ejecución dinámica peligrosa, workflows mal configurados, higiene de dependencias, y si el software arranca de forma segura cuando no se le configura nada. Es la dimensión que más pesa. |
| Cadena de suministro | Quién lo mantiene, si esa persona es identificable, si las publicaciones van firmadas, si los cambios se revisan antes de entrar, y qué ocurre si esa persona desaparece. |
| Calidad del código | Pruebas, tipado, documentación técnica y gestión de errores. No es una cuestión de seguridad sino de mantenimiento futuro. |
| Licencia | Si legalmente puede usarlo, y con qué obligaciones. Algunas licencias alcanzan al trabajo comercial construido encima. Un repositorio sin licencia no le concede permiso para nada. |
| Superficie de integración | Se aplica cuando el repositorio va a ejecutarse dentro de su entorno con acceso a datos reales. Qué permisos pide, si envía información fuera y qué ocurre cuando falla. |
| Señales externas | Auditorías publicadas, avisos de seguridad, incidentes previos y presencia en listados de referencia. Esta dimensión solo suma. |
El veredicto es lo que la diferencia
Una lista de comprobación le entrega treinta datos y deja la decisión encima de la mesa. Aquí sale una recomendación, con su puntuación y con el motivo detrás.
| Veredicto | Qué significa |
|---|---|
| ADOPT | Intégrelo. Siga sus publicaciones como haría con cualquier dependencia. |
| EVALUATE | Intégrelo con precauciones explícitas. Deje por escrito qué riesgos ha aceptado y revíselo a los noventa días. |
| CAUTION | Solo si no hay alternativa. Aíslelo y lea el código antes de llevarlo a producción. |
| AVOID | No lo integre. Busque otra cosa. |
Algunos hallazgos anulan la aritmética. Un repositorio sin licencia queda descartado por bien que puntúe en todo lo demás, igual que uno con credenciales reales en el código. Es deliberado: las medias esconden justo el hallazgo que debería haberle frenado.
Qué no hace
Conviene decirlo antes de que se lleve una decepción, y con más motivo tratándose de seguridad.
No ejecuta el código ni descubre vulnerabilidades desconocidas
No es análisis estático ni una prueba de intrusión. Razona sobre lo que está publicado: código, manifiestos, workflows, licencia e historial. Una puerta trasera escrita para pasar por código corriente no se detecta leyendo eso. Para ese trabajo hace falta una herramienta especializada.
No releva a un revisor humano si el repositorio va a tocar datos sensibles
La puntuación le ordena por dónde empezar a mirar; no le autoriza a no mirar. Si el código va a manejar datos de clientes, credenciales o material regulado, alguien cualificado lo revisa antes de que salga.
No audita su propio código
El método da por hecho que evalúa un artefacto ajeno del que tiene que decidir si se fía. Su propio repositorio necesita otras preguntas.
Una última advertencia: la puntuación retrata el repositorio el día en que se midió. Los proyectos se recuperan y los proyectos se pudren. Vuelva a pasarla antes de una decisión que importe.
Cómo se instala y se usa
Descargue la carpeta del idioma que prefiera desde el repositorio y súbala como skill en Claude.ai o Claude Desktop, desde Ajustes. En Claude Code basta con copiarla a su directorio de skills.
A partir de ahí se invoca en lenguaje natural, sin comandos:
audita el repo https://github.com/propietario/proyecto
Para un descarte rápido, que recorre solo las tres primeras fases:
audita rápido https://github.com/propietario/proyecto
El resultado es un informe HTML autocontenido, con un gráfico radial de las siete dimensiones, una tabla por fase con lo medido y lo puntuado, los hallazgos que requieren atención y el veredicto razonado.
Licencia, origen y mantenimiento
Licencia MIT. Puede usarla, modificarla, distribuirla e integrarla en su propio trabajo, también con fines comerciales, con la única condición de conservar el aviso de copyright.
Origen del método. El enfoque bebe de las skills públicas de Trail of Bits, y en particular de dos ideas suyas: auditar los valores por defecto que fallan en abierto, y no solo las vulnerabilidades declaradas; y dejar escritas de antemano las excusas que un auditor debe negarse a aceptar. «Es código abierto, luego es seguro» es la que más va a oír.
Mantenimiento. No hay hoja de ruta ni compromiso de soporte. La herramienta se publica porque resulta útil. Las incidencias del repositorio son el sitio para avisar de un fallo o de un veredicto que no cuadra.
