Cómo usar Inteligencia Artificial para detectar vulnerabilidades en código Python, JavaScript, Java y C/C++

Idea central: la mejor estrategia es combinar IA + SAST + análisis de dependencias + revisión humana. La IA ayuda a encontrar, explicar y sugerir correcciones; el equipo técnico debe validar si el hallazgo es real, explotable y correctamente corregido.

name: "CodeQL"

on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]

jobs:
analyze:
name: Analyze
runs-on: ubuntu-latest
strategy:
matrix:
language: [ 'python', 'javascript-typescript', 'java-kotlin', 'c-cpp' ]

```
steps:
  - name: Checkout repository
    uses: actions/checkout@v4

  - name: Initialize CodeQL
    uses: github/codeql-action/init@v4
    with:
      languages: ${{ matrix.language }}
      queries: security-extended,security-and-quality

  - name: Autobuild
    uses: github/codeql-action/autobuild@v4

  - name: Perform CodeQL Analysis
    uses: github/codeql-action/analyze@v4

1. Escanear: ejecutar CodeQL, Semgrep, Snyk o SonarQube.
2. Triar: separar hallazgos críticos, altos, medios y falsos positivos.
3. Explicar: pedir a la IA que explique la ruta vulnerable y el impacto.
4. Corregir: pedir una solución mínima, segura y testeable.
5. Validar: ejecutar pruebas, repetir escaneo y revisar manualmente.
6. Documentar: registrar causa raíz, corrección y lección aprendida.

Actúa como revisor AppSec senior.
Voy a pegar una alerta de SAST y un fragmento de código.
No inventes datos.
Explica:
1. Por qué es vulnerable.
2. Qué entrada no confiable participa.
3. Qué función peligrosa o sink se alcanza.
4. Cómo corregirlo con el cambio mínimo.
5. Qué prueba unitaria agregaría.
6. Qué falso positivo podría existir.

Revisa este código Python buscando:
- command injection
- SQL injection
- uso inseguro de eval/exec
- deserialización insegura
- secretos expuestos
- debug en producción

Devuelve una tabla con vulnerabilidad, línea, riesgo, corrección y prueba recomendada.

Analiza este código JavaScript/TypeScript.
Busca XSS, SSRF, prototype pollution, uso inseguro de eval, validación insuficiente, exposición de secretos y dependencias peligrosas.
Para cada hallazgo, indica:
- entrada no confiable
- sink vulnerable
- impacto
- corrección segura
- prueba automatizada

Revisa este código Java como AppSec senior.
Busca:
- SQL injection
- command injection
- XXE
- deserialización insegura
- path traversal
- autorización incompleta
- criptografía débil

Explica la vulnerabilidad y propone una corrección compatible con buenas prácticas OWASP.

Revisa este código C/C++.
Busca buffer overflow, use-after-free, double free, integer overflow, format string, race conditions y APIs inseguras.
No propongas cambios cosméticos.
Para cada hallazgo, indica:
- línea vulnerable
- condición de explotación
- impacto
- corrección segura
- prueba o sanitizer recomendado

1. En el IDE: sugerencias tempranas y explicación de riesgos.
2. En pre-commit: secretos, formato, reglas básicas y dependencias.
3. En pull request: SAST, CodeQL, Semgrep, Snyk, SonarQube.
4. En CI/CD: bloquear vulnerabilidades críticas o secretos reales.
5. En producción: monitoreo, logs, SCA, SBOM y respuesta ante CVE.

Actúa como auditor de seguridad de aplicaciones.
Lenguaje: [Python / JavaScript / Java / C++]
Contexto: [API web / CLI / microservicio / librería / backend]
Objetivo: detectar vulnerabilidades reales, no problemas de estilo.

Revisa el código buscando:

1. Entradas no confiables.
2. Validación insuficiente.
3. Sinks peligrosos.
4. Inyección.
5. XSS o salida insegura.
6. Deserialización insegura.
7. Manejo inseguro de archivos.
8. Secretos expuestos.
9. Errores criptográficos.
10. Problemas de memoria si es C/C++.

Devuelve:

* hallazgo
* severidad
* evidencia
* posible falso positivo
* corrección mínima
* prueba recomendada
* regla SAST o Semgrep sugerida

• Copiar y pegar código sensible de clientes en servicios externos sin autorización.
• Aceptar una corrección generada por IA sin pruebas.
• Confundir “explicación convincente” con evidencia técnica.
• Usar la IA solo como chatbot y no como parte del pipeline SAST.
• Corregir solo el síntoma y no la causa raíz.
• Ignorar falsos negativos: si la IA no reporta nada, no significa que el código sea seguro.
• Desactivar reglas porque generan ruido sin revisar si el patrón es importante.
• Permitir que agentes de IA generen cambios masivos sin revisión humana.
• No revisar licencias, dependencias y secretos.
• No repetir el escaneo después de aplicar el parche.

1. Revisar el diff: entender cada línea modificada.
2. Probar el caso vulnerable: confirmar que ya no se reproduce.
3. Agregar prueba unitaria: evitar regresión.
4. Ejecutar SAST otra vez: comprobar que la alerta desaparece.
5. Ejecutar pruebas funcionales: confirmar que no se rompió el flujo normal.
6. Revisar dependencias: evitar introducir librerías innecesarias o inseguras.
7. Documentar: registrar vulnerabilidad, causa, solución y evidencia.

• Usar IA sin escáner SAST de respaldo.
• No indicar lenguaje, framework, versión ni contexto de ejecución.
• Analizar fragmentos aislados sin rutas de entrada y salida.
• No revisar dependencias vulnerables.
• No incluir archivos de configuración, rutas, controladores o plantillas.
• No diferenciar falso positivo de vulnerabilidad explotable.
• Corregir con cambios demasiado grandes que introducen nuevos errores.
• No proteger código propietario o datos sensibles al usar IA externa.
• No agregar pruebas después de corregir.
• Confiar en una sola herramienta.

¿La IA puede encontrar vulnerabilidades reales?

Sí, especialmente cuando se combina con SAST, análisis semántico, reglas de seguridad y contexto del repositorio. Pero también puede producir falsos positivos o pasar por alto vulnerabilidades, por lo que debe validarse con revisión humana y pruebas.

¿Qué herramienta conviene para empezar?

Para repositorios en GitHub, CodeQL con code scanning es una excelente base. Para equipos que quieren reglas personalizadas y revisión rápida en CI/CD, Semgrep es muy práctico. Para plataformas comerciales con corrección asistida, Snyk y SonarQube AI CodeFix son opciones fuertes.

¿Sirve para C y C++?

Sí, pero en C/C++ la revisión debe ser más rigurosa. Hay que complementar IA con CodeQL, sanitizers, análisis de memoria, fuzzing, revisión manual y pruebas específicas para errores de memoria.

¿Puedo aceptar automáticamente el parche de IA?

No. El parche debe revisarse, probarse y volver a escanearse. Una corrección aparentemente segura puede romper funcionalidad o introducir otro problema.

¿Qué datos no debo pegar en una IA externa?

No pegues código propietario sensible, secretos, claves privadas, tokens, credenciales, reportes de seguridad embargados, datos personales ni información interna sin autorización y sin una política clara de uso de IA.

• Python seguro desde cero: buenas prácticas para evitar vulnerabilidades en aplicaciones y APIs.
• Python para ciberseguridad: 20 proyectos prácticos para aprender automatización, redes y análisis de seguridad.
• Cómo auditar proyectos de software libre antes de utilizarlos en una empresa: seguridad, comunidad, licencias y mantenimiento.
• Cómo saber si tu Linux está bien protegido: 30 comprobaciones de seguridad que puedes realizar ahora mismo.
• Cómo usar IA para administrar Linux: comandos, diagnóstico, automatización y seguridad con asistentes inteligentes.

Conclusión editorial

La nueva seguridad del software no será solo manual ni solo automática: será híbrida. Los equipos que combinen IA, CodeQL, Semgrep, Snyk, SonarQube, pruebas y revisión humana podrán detectar más rápido, corregir mejor y reducir riesgos antes de que el código llegue a producción. La IA no sustituye al equipo AppSec; lo multiplica.