Cómo auditar seguridad, ciberseguridad, rendimiento, accesibilidad, usabilidad y calidad de forma sistemática — combinando las herramientas de siempre con prompts maestros de IA. Para cualquier proyecto y en cualquier lenguaje.
Por qué este artículo
Revisar código y configuración antes de que llegue a producción es una de las tareas que más retorno da y menos se hace bien. No por falta de voluntad, sino por falta de método: «revísalo a ver si ves algo raro» no escala, depende del día que tenga quien revisa y se olvida justo de lo que más duele.
Este artículo propone un enfoque doble, pensado tanto para desarrolladores como para administradores de sistemas:
- Sin IA: apoyarse en checklists, linters, escáneres y estándares reconocidos para no depender de la memoria ni del ojo clínico.
- Con IA: usar prompts maestros bien estructurados que convierten a un modelo como Claude en un revisor senior que encuentra problemas reales y te entrega arreglos listos para pegar.
Los dos enfoques no compiten: se refuerzan. La IA es rapidísima detectando patrones y explicando el porqué; las herramientas deterministas te dan garantías repetibles y sin alucinaciones. Juntas cubren lo que por separado se les escapa.
Todos los prompts que se citan están publicados, gratis y en abierto (licencia MIT), en github.com/dcarrero/awesome-code-review-prompts, con versión en inglés y español.
El problema de «revísalo a ver»
Si alguna vez has pegado un fichero en un asistente de IA y has escrito «revisa mi código», ya conoces el resultado: una lista educada y genérica de observaciones superficiales. Renombra una variable, sugiere «añade manejo de errores»… y rara vez encuentra la inyección SQL, la consulta N+1, el contenedor que corre como root o el secreto commiteado que te va a arruinar el fin de semana.
El modelo no es el cuello de botella. El prompt lo es.
Y lo mismo ocurre sin IA: si tu proceso de revisión es «que alguien le eche un ojo», estás dejando la seguridad de tu sistema al azar de la atención humana un martes por la tarde. La solución, con o sin IA, es la misma idea: convertir la revisión en algo sistemático, con un alcance explícito y un formato de salida fijo.
Las seis dimensiones que hay que mirar (y a quién le tocan)
Un software o una infraestructura no se juzgan solo por «¿funciona?». Una revisión completa cubre seis ángulos. Fíjate en que algunos son más de desarrollador y otros más de sysadmin, pero todos acaban tocándose:
| Dimensión | Qué busca | ¿Dev o Sysadmin? |
|---|---|---|
| Seguridad de aplicación | Inyección, XSS, control de acceso, criptografía (OWASP Top 10, CWE) | Sobre todo Dev |
| Ciberseguridad e infraestructura | Secretos, dependencias vulnerables, contenedores, IaC, CI/CD, modelo de amenazas | Sobre todo Sysadmin |
| Rendimiento | Complejidad, N+1, concurrencia, memoria, caché, escalabilidad | Ambos |
| Accesibilidad (a11y) | WCAG 2.2 AA: teclado, lector de pantalla, contraste, formularios | Sobre todo Dev (front) |
| Usabilidad / UX | Claridad, flujos, feedback, recuperación de errores, microcopy | Ambos (¡también CLIs y APIs!) |
| Calidad y mantenibilidad | Corrección, diseño, tests, legibilidad | Ambos |
La dimensión de ciberseguridad e infraestructura es la que más habla el idioma del administrador de sistemas: cadena de suministro, gestión de secretos, higiene de contenedores, IAM con exceso de permisos, puertos abiertos a 0.0.0.0/0, TLS mal configurado y pipelines de CI/CD que filtran tokens en los logs. Y la de usabilidad no es solo para webs bonitas: una CLI con flags incoherentes o una API con errores crípticos también es un problema de UX que paga el equipo entero.
Enfoque 1 — Revisión SIN IA: tu red de seguridad determinista
Antes de meter IA en la ecuación, conviene tener una base sólida de herramientas que hacen siempre lo mismo, se integran en CI y no inventan nada. Este es el arsenal por dimensión:
Seguridad de aplicación
- Linters con reglas de seguridad:
eslint-plugin-security,bandit(Python),gosec(Go), PHPCS con reglas de seguridad, Brakeman (Rails). - SAST (análisis estático): Semgrep, SonarQube, CodeQL.
- DAST y pruebas dinámicas: OWASP ZAP, Burp Suite.
- Revisión manual guiada por el OWASP Top 10 y el OWASP ASVS como checklist.
Ciberseguridad e infraestructura (terreno sysadmin)
- Dependencias y CVEs:
npm audit,pip-audit,composer audit, Trivy, Grype, Dependabot/Renovate. - Secretos:
gitleaks,trufflehog,git-secretsen pre-commit. - Contenedores e imágenes: Trivy, Hadolint (Dockerfile), Docker Bench for Security.
- Infraestructura como código:
tfsec, Checkov,terrascan,kube-score,kube-linter, Polaris. - Benchmarks: CIS Benchmarks (Docker, Kubernetes, Linux) y
Lynispara hardening de servidores. - CI/CD: firmar artefactos (Sigstore/cosign), generar SBOM (Syft), escanear secretos en logs.
Rendimiento
- Profilers del lenguaje (perf, pprof, py-spy, Blackfire),
EXPLAIN ANALYZEen SQL,k6/wrk/abpara pruebas de carga, APM (Prometheus + Grafana, Datadog).
Accesibilidad
- axe DevTools, Lighthouse, Pa11y, WAVE, y pruebas manuales con teclado y lector de pantalla (NVDA, VoiceOver).
Calidad y mantenibilidad
- Linters y formatters (ESLint/Prettier, Ruff/Black, golangci-lint), cobertura de tests, complejidad ciclomática, SonarQube, y revisión por pares con una checklist de PR.
La virtud de este enfoque es la garantía repetible: pasa siempre, en cada commit, sin cansarse. Su límite es que solo encuentra lo que sus reglas ya conocen, entiende poco del contexto y del negocio, y genera ruido (falsos positivos) que hay que triar a mano.
Enfoque 2 — Revisión CON IA: prompts maestros
Aquí es donde un modelo capaz aporta lo que las herramientas deterministas no: razonamiento con contexto. Un buen modelo puede seguir un dato no confiable desde que entra hasta donde explota, entender la lógica de negocio, explicar el porqué de cada fallo y proponer el parche exacto. Pero solo si le das el prompt correcto.
Un prompt maestro es una instrucción reutilizable y estructurada que transforma una petición vaga en una revisión rigurosa. Los buenos tienen siempre cinco ingredientes:
- Rol. «Eres un ingeniero senior de seguridad de aplicaciones.» Asignar una identidad de experto eleva el listón de la respuesta.
- Alcance. Un checklist explícito de qué buscar. Es la diferencia entre «parecía bien» y un barrido sistemático por inyección, auth, criptografía y control de acceso.
- Método. Cómo razonar: rastrear el dato desde el origen (source) hasta el punto peligroso (sink), priorizar por impacto real y evitar falsos positivos.
- Contrato de salida. Un formato fijo: severidad, fichero y línea exactos, escenario de explotación e impacto, y un arreglo listo para pegar.
- Preguntas de clarificación. El prompt pide el contexto que falta (¿producción o prototipo?, ¿qué framework?, ¿qué volúmenes?) antes de juzgar.
Omite cualquiera y la calidad cae. Inclúyelos los cinco y el mismo modelo que te daba «considera añadir manejo de errores» te entrega una lista priorizada de vulnerabilidades con sus parches.
Ejemplo: prompt maestro de seguridad (fragmento)
text
Eres un ingeniero senior de seguridad de aplicaciones haciendo una revisión de
código seguro. Revisa el código que te doy con mentalidad adversaria: asume que
toda entrada es hostil.
ALCANCE — comprueba, como mínimo: inyección (SQL/NoSQL, comandos, LDAP, plantillas),
XSS, autenticación rota, control de acceso roto (IDOR, escalada, path traversal),
exposición de datos sensibles, deserialización insegura, SSRF, CSRF, criptografía débil.
MÉTODO: rastrea el dato no confiable de source a sink; asocia cada hallazgo al
OWASP Top 10 y a un CWE; no reportes teóricos sin sustento (evita falsos positivos).
SALIDA — por hallazgo: título y severidad, ubicación exacta, escenario de explotación,
y un arreglo listo para pegar. Termina con un veredicto: Publicar / Publicar con
arreglos / No publicar.La colección incluye un prompt así para cada dimensión, más uno «todo en uno» que las ejecuta todas y devuelve una tabla de puntuaciones con veredicto de release. Y como agnósticos del lenguaje que son, se combinan con complementos por stack que añaden las trampas concretas de cada tecnología.
Primero agnóstico, después específico del stack
El prompt general de seguridad sabe rastrear entradas no confiables — da igual si es Python o Rust. Pero las trampas concretas cambian: Python tiene pickle y eval; Go, fugas de goroutines; PHP, el unserialize() y el mal escape en Blade/Twig; Kubernetes, contenedores como root; Terraform, security groups abiertos. Por eso el flujo es:
Prompt maestro general (p. ej. seguridad) + tu código + el complemento del stack (p. ej. Laravel, Docker/Kubernetes o Terraform) = una revisión con amplitud y profundidad idiomática a la vez.
Hay complementos para JavaScript/TypeScript, Python, PHP moderno, WordPress, Laravel, Symfony, Java, Go, C#/.NET, Swift, Kotlin, Rust, C/C++, SQL, React/Next.js, Node.js, Docker/Kubernetes, Terraform y Bash — estos tres últimos, especialmente jugosos para administradores de sistemas.
Ejemplos pensados para administradores de sistemas
La revisión con IA no es solo para código de aplicación. Estos son casos de uso muy de sysadmin:
Auditar un Dockerfile / manifiestos de Kubernetes Pega el prompt de ciberseguridad + el complemento Docker/Kubernetes junto a tus ficheros. Detecta runAsRoot, imágenes base sin fijar por digest, capabilities de más, ausencia de securityContext, secretos en ConfigMaps, RBAC con cluster-admin y NetworkPolicies inexistentes — mapeado al CIS Benchmark.
Revisar Terraform antes del apply Prompt de ciberseguridad + complemento Terraform: caza IAM con comodines *, buckets públicos, volúmenes sin cifrar, 0.0.0.0/0 en puertos sensibles, state sin cifrar/locking y prevent_destroy ausente en recursos con estado.
Endurecer scripts de Bash El complemento Bash señala inyección de comandos por variables sin comillar, ausencia de set -euo pipefail, curl | bash sin verificar, ficheros temporales predecibles y todo lo que ShellCheck marcaría — con la ventaja de que además te lo explica y te lo reescribe.
Triage de dependencias Pega tu package.json, requirements.txt, composer.json o go.mod con el prompt de ciberseguridad y pídele que nombre CVEs probables, versiones sin fijar y riesgo de dependency confusion.
Lo mejor de los dos mundos: un flujo combinado
En la práctica, el proceso que mejor funciona no es «IA o herramientas», sino herramientas + IA + persona, en este orden:
- Automático y determinista (CI): linters, SAST, escáneres de dependencias,
tfsec/Checkov,gitleaks. Bloquea lo que ya sabemos que está mal. Rápido, barato, sin alucinaciones. - Revisión con IA (control de PR): pega el
git diffcon el prompt «todo en uno» y el complemento del stack. Pide solo la tabla de puntuaciones y los elementos bloqueantes. Aquí aparece lo que las reglas no ven: lógica de negocio, contexto, encadenamiento de fallos. - Criterio humano: el revisor valida los hallazgos de la IA (que son pistas de experto, no dogma), confirma los exploits de alto impacto y decide. La IA acelera; la persona responde.
Una regla sencilla para el gate: bloquea el merge ante cualquier hallazgo Crítico o Alto, venga de la herramienta determinista o del veredicto de la IA.
Cómo pedirle un control de PR a la IA
text
[pega el prompt "todo en uno"]
[pega el complemento del stack: docker-kubernetes / terraform / laravel...]
Aquí está el diff de este PR:
<git diff origin/main...HEAD>
Devuelve solo: la tabla de puntuaciones por dimensión, el arreglo más importante
y el veredicto de release (Publicar / Publicar con arreglos / No publicar).Lenguaje del código: JavaScript (javascript)Y para automatizarlo: el mismo prompt puede alimentar un bot de CI o un hook de pre-commit que capture la salida Markdown del modelo y haga fallar el job cuando el veredicto sea «No publicar». Empieza en manual, mide la relación señal/ruido y automatiza solo las combinaciones que ayudan de forma consistente.
Buenas prácticas para que la IA acierte más
- Da contexto por adelantado. Producción vs. prototipo, versión del framework, proveedor cloud, objetivos de cumplimiento (¿SOC 2?, ¿ISO 27001?), volúmenes de datos («esta tabla tiene ~5M filas»). Cambia la severidad y las prioridades.
- Acota el alcance. Un volcado de 50 ficheros diluye la atención. Prefiere un
diffo una carpeta. - Pide el formato que vas a usar. Una tabla Markdown se pega limpia en un issue; comentarios inline, en una review; una tabla de puntuaciones, para el gate.
- No te saltes las preguntas de clarificación. Responderlas es donde está la mayor ganancia: el modelo deja de adivinar.
- Confía pero verifica. Especialmente en cambios de alto impacto: confirma exploits y ejecuta los benchmarks/tests que la propia IA te sugiera.
- Cuidado con lo que pegas. No metas secretos reales ni datos personales en el prompt; usa un entorno y una política acordes a tu organización.
Conclusión: sistematiza, no confíes en el ojo clínico
Ya seas administrador de sistemas o desarrollador, el mensaje es el mismo: la revisión buena es sistemática. Sin IA, esa sistematización te la dan los linters, escáneres y benchmarks que corren en cada commit. Con IA, te la da un prompt maestro con rol, alcance, método, formato de salida y preguntas de clarificación. Y el mejor resultado surge de encadenarlos: la herramienta determinista pone el suelo, la IA aporta el razonamiento y el contexto, y la persona pone el criterio final.
No necesitas un modelo mejor. Necesitas un prompt mejor —y un proceso que no dependa de tener un buen día.
La colección completa de prompts maestros, complementos por lenguaje y frameworks (incluidos Docker/Kubernetes, Terraform y Bash), en inglés y español y con licencia MIT, está en github.com/dcarrero/awesome-code-review-prompts.
