Cómo auditar la seguridad de tu proyecto con IA y Claude

Te dejo el vídeo arriba, pero aquí lo tienes escrito y con los enlaces para que puedas ir aplicándolo mientras lees.

Mi compañero Fer hizo hace poco un vídeo enseñando cómo usaba Claude Code para revisar todos los archivos de su ordenador y buscar fallos de seguridad. En un proyecto suyo de la escuela encontró varios agujeros, y a raíz de eso me escribió mucha gente pidiéndome un plus: qué hacer para lanzar un mínimo de auditoría de seguridad sobre tu propio entorno de trabajo.

Yo del tema de ciberseguridad ando un pelín desactualizado, la verdad. Tuve una empresa de esto, pero hace años que la absorbieron y ya no trabajo en ello activamente. Aun así hay bases que se aplican siempre, y hoy tenemos IA para hacerlas sin volvernos locos montando entornos raros.

¿Sirve la IA para auditar la seguridad de un proyecto?

Sí, y bastante mejor de lo que mucha gente cree. No para sustituir a un pentester de verdad, pero sí para tener un mínimo con el que ya estás más cubierto que la mayoría.

Herramientas como Claude ya traen por defecto cosas para hacer algún tipo de auditoría de seguridad. No me voy a meter ahí porque tienes doscientos vídeos en YouTube que te lo explican. Lo que te quiero contar es un truco propio que uso, y que además sirve para otros temas como SEO.

La clave está en no pedirle a la IA algo genérico tipo "revísame cómo está la seguridad de mi sistema". Eso te da una respuesta de andar por casa. Vamos a llevarlo un paso más allá.

Por qué una skill genérica no te sirve

Lo que hago en estos casos es crearme una skill de auditor. Y crear una skill no tiene misterio: es decirle a Claude, a Gemini CLI, a Codex o a quien uses que te la haga. Se la pides y te la crea. Punto.

El problema es que si te limitas a decirle "créame una skill de auditor" a secas, te va a montar algo genérico, igual que si se lo pidieras con un prompt normal. Y ahí está la manía que tenéis muchos: bajaros skills de otras personas. Esas skills están hechas para funcionar lo máximo posible para el mayor número de gente. Si estás empezando, genial. Pero si tú estás desarrollando un proyecto de verdad, créate skills para ti. Una skill especializada para tu sistema es lo que marca la diferencia.

Paso 1: saca todas las especificaciones de tu sistema

Antes de crear nada, necesitas saber qué tienes montado exactamente. Aquí te hablo sobre todo de código, que es lo que más os interesa, pero esto lo aplicas a cualquier cosa con un poco de imaginación.

Si estás picando código con IA, es tan simple como decirle: "conéctate al repo y bájame las especificaciones de todo". Qué versión de Next.js usas, qué librerías, cómo está desplegado el servidor, cómo está la configuración de la infraestructura, si tienes un WAF metido, lo que sea. Todo. Cuanto más detalle, mejor.

¿Cómo lanzo un deep research útil para esto?

Con esa lista de tecnologías en la mano, lanzas un deep research. Hoy por hoy es de lo mejor que tienen las IA: poder hacer una investigación profunda sobre un tema concreto.

La herramienta que más me gusta para esto es NotebookLM de Google. Las fuentes que encuentra son cojonudas, e incluso puede tirar de vídeos de YouTube para ciertas cosas. Yo tengo el MCP de NotebookLM conectado a Claude, así que le pido directamente que se conecte, me cree un cuaderno y lance el deep research. Pero no hace falta: puedes entrar a NotebookLM desde la web, crear el cuaderno a mano y pedirle la investigación igual.

Y aquí está el matiz importante. No le digas "hazme una investigación de ciberseguridad" a lo bruto, porque no sirve de nada. Le dices que investigue tendencias de ciberseguridad de 2026 y agujeros conocidos que aún no estén cerrados en esas versiones concretas de tu lista de tecnologías. Con eso te hace un deep research de verdad, de problemas de seguridad de tu sistema concreto. Esa es la clave: tu sistema, no uno cualquiera.

Paso 2: crea tu skill de auditor a medida

Con todas esas fuentes ya le dices a Claude que te cree la skill. Ahora sí va a tener detrás fuentes muy buenas: prácticas, exploits, agujeros conocidos, un montón de material real. Incluso puedes pedirle que piense un poco fuera de la caja para que encuentre cosas relacionadas que no estén escritas de forma literal.

Y te crea una skill entrenada específicamente para tu sistema y tu entorno. No va a ser infalible, que quede claro. Esto es algo con lo que empezar, un mínimo de seguridad. No te va a pillar todo lo que un nivel técnico muy fuerte encontraría, porque para eso están los pentesters. Pero sí te va a revisar muchísimo y te va a dejar más cubierto que un porcentaje enorme de gente que hay en internet.

Con este mismo sistema me he montado skills de SEO y de otros temas que me han servido un montón. Si quieres una guía aparte para esto, aquí tienes cómo crear una skill en Claude paso a paso, y si vas a apoyarte en NotebookLM para las fuentes, mira cómo funciona NotebookLM sin que se invente nada.

¿Dónde lanzo la auditoría? Nunca contra producción

Esto es sentido común, pero lo he visto fallar mucho. Si tienes un entorno web en producción, por favor, no lances un pentesting directamente contra él.

¿Por qué? Porque te puede borrar una base de datos, hacer una escalada de privilegios o meterte cambios que luego revertir sea un infierno. La has liado, y la has liado gorda. En mi época trabajando en ciberseguridad vi a mucha gente lanzar pruebas contra producción y acabar con problemas serios por cafres.

Lo correcto es duplicar el entorno. Replicas una copia exacta de lo que tienes en producción, lanzas la auditoría ahí y listo. Lo que encuentre en un lado te lo va a encontrar en el otro, porque es prácticamente lo mismo. Y de ahí le pides que te genere un informe con un plan de acción detallado, categorizando lo que es urgente y grave frente a lo que es una tontería.

Seguridad sí, pero hasta donde te sientas cómodo

Una cosa que aprendí trabajando en esto: la seguridad hay que llevarla hasta el punto en el que te sientas cómodo. Un entorno 100% seguro no existe. Siempre aparecen exploits nuevos, agujeros nuevos, zero-days que te fastidian la vida. Cualquiera que trabaje en ciberseguridad lo sabe.

Pasa como con la legalidad: cumplir a rajatabla el 100% a veces te lleva a que no puedas ni trabajar. Con la seguridad igual. Llevarla al extremo hace que tu plataforma sea un dolor de usar. El típico ejemplo son los bancos que te deslogean cada minuto de inactividad. Un pentesting en condiciones te va a decir que deberías tener esa expiración de sesión. ¿Es necesario en tu caso? Probablemente no. Si lo metes, la gente deja de usar la plataforma al tercer día.

Que la IA te diga que tienes ciertos problemas no significa que tengas que aplicarlos todos. Si te marca algo crítico o grave, arréglalo, no hay más. Lo demás, sentido común: entiende de qué va la cosa y decide si te compensa. Cada uno hasta donde quiera arriesgar.

Herramientas que menciono en el vídeo

• Claude Code para pedirle que cree la skill y lance la auditoría.
• NotebookLM (de Google) para el deep research y las fuentes.
• Gemini CLI y Codex como alternativas a Claude para crear la skill.

Si te interesa entrar de lleno en Claude Code sin saber programar, tienes la guía completa de Claude Code para no programadores.

Si quieres aprender cómo trabajo yo con la IA de verdad, montando skills y agentes que trabajan conmigo, eso es justo lo que enseño en Yo S.A.. Ahí está todo el sistema de documentación con el que sale esto.