AI Code Security · AI SAST · validación de explotabilidad

Seguridad del código en la era de la IA

Los escáneres basados en reglas siguen encontrando de forma fiable aquello para lo que fueron creados: fallos de sintaxis. Lo que duele hoy — autorización rota, lógica de negocio, permisos asumidos por error — no tiene firma. Ordenamos reglas, razonamiento de IA y validación de explotabilidad de forma que su equipo pueda operarlo de verdad.

Reservar una primera cita Ver los servicios

Diagnóstico en dos semanas, resultado sólido en 90 días
Neutrales en herramientas: evaluamos su stack, no vendemos ninguno
Evidencia que resiste auditorías de CRA, NIS2 y clientes

Cuatro cifras que describen la situación

Todas proceden de fuentes primarias y de operadores de acceso público. Juntas explican por qué volumen y velocidad se convirtieron en un problema al mismo tiempo.

45 %

del código generado por IA suspende la prueba de seguridad

Evaluado en más de 100 modelos y 80 tareas de programación. En Java la tasa de fallo llega al 72 por ciento.

Veracode GenAI Code Security Report

A01

Broken Access Control sigue siendo el número uno del OWASP Top 10

La edición 2025 cubre expresamente BOLA y BFLA — justo los fallos que ningún patrón sabe expresar.

OWASP Top 10:2025

23 %

de las vulnerabilidades explotadas conocidas se atacan el día de su publicación

Proporción de entradas KEV con explotación el día de la publicación del CVE o antes, primer semestre de 2026.

Catálogo KEV de CISA

15–20 %

de los CVE entrantes se siguen enriqueciendo por completo

La NVD opera en modo triaje desde abril de 2026. Esperar bases de datos completas ya no es una estrategia.

NIST sobre el cambio en la NVD

Un escáner lee sintaxis. Un atacante lee intención.

La diferencia no es un problema de herramienta, sino de clase de fallo. Ambos ejemplos proceden de la misma aplicación.

pythonDETECTADO

1# Findet jede Regel-Engine seit 20052query = "SELECT * FROM users WHERE id=" + req.id3db.execute(query)4# → CWE-89 · SQL Injection · deterministisch erkennbar

Una consulta SQL concatenada tiene una forma estable. Para eso están hechas las reglas: rápidas, reproducibles y lo bastante baratas para ejecutarse en cada commit. Nadie sustituye esta capa.

Por eso no sustituimos nada. Añadimos una segunda capa capaz de razonar sobre la intención.

Tres capas en lugar de una herramienta

Cada capa tiene su clase de fallos, su cadencia y su precio. Seleccione una capa para ver su regla de uso.

Layer 2

AI SAST con razonamiento semántico

Qué encuentra: Fallos dependientes de la intención: autorización rota, IDOR y BOLA, lógica de negocio, falta de aislamiento entre inquilinos.
Dónde se ejecuta: Dirigida a repositorios de alto valor: servicios expuestos a internet, autenticación y todo lo que maneje datos personales o de pago.
Qué cuesta: Coste medio. El esfuerzo se justifica por la clase de fallo, no por el volumen.

Más rápido, más barato, sintácticoMás lento, más caro, más profundo

La pregunta nunca es «qué capa», sino «qué capa en qué repositorio y con qué cadencia». Esa asignación la elaboramos con usted — a partir de exposición y clase de datos, no por intuición.

La alcanzabilidad es una hipótesis. La explotabilidad es una prueba.

Entre un fragmento de código marcado y un riesgo real hay cuatro pasos. Saltárselos significa priorizar por intuición.

01
Hallazgo
Una regla o un modelo marca un punto del código. En ese momento no es nada más.
02
Alcanzabilidad
El punto marcado está en una ruta que puede invocarse desde fuera.
03
Exposición
El servicio es realmente accesible: ruta de red, identidad, configuración.
04
Explotabilidad
El ataque se ejecutó contra el entorno en funcionamiento y surtió efecto. A partir de aquí ya no es una sospecha.
05
Impacto
Lo que hay detrás de la ruta decide el orden de corrección.

De qué nos ocupamos

No construimos una organización paralela. Ordenamos su cadena de herramientas actual para que sostenga — y asumimos las partes que exigen conocimiento especializado.

Arquitectura de escaneo y evaluación de herramientas

Antes de sumar otra herramienta aclaramos qué capa tiene sentido en qué repositorio.

Clasificar repositorios por exposición y clase de datos
Comparación neutral de su stack existente
Modelo de cadencia y costes por capa

Implantar y calibrar AI SAST

El análisis semántico vale lo que valgan sus criterios de aceptación. Los definimos antes de la primera ejecución.

Piloto en repositorios definidos
Calibración frente a hallazgos conocidos ya corregidos
Criterios de aceptación en lugar de métricas del fabricante

Validación de explotabilidad y contraprueba

Comprobamos en el sistema en funcionamiento si un hallazgo conduce realmente a una ruta de ataque.

Prueba sobre el sistema, no sobre un diagrama
Cadena de prueba por cada ruta confirmada
Entrega a desarrollo con pasos de reproducción

Revisión de código generado por IA

El código de asistente falla en clases predecibles. Ahí empieza exactamente la revisión.

Autorización, aislamiento entre inquilinos, gestión de errores
Guía de revisión para sus code owners
Riesgos de agentes y prompts dentro del propio repositorio

Remediación y responsabilidad

El hallazgo más maduro no llega a ninguna parte si nadie está designado. Cerramos la brecha entre descubrimiento y corrección.

Mapeo de code owners hasta la persona concreta
Propuestas de corrección como pull request
SLA por explotabilidad y no solo por CVSS

Evidencia para CRA, NIS2 y auditorías de clientes

Los mismos artefactos sostienen la auditoría, el cuestionario de cliente y la prueba de incidente — si se generan así desde el principio.

Informes de ensayo para la documentación técnica
Deuda de seguridad con fecha de vencimiento en lugar de lista de excepciones
Indicadores que muestran efecto y no actividad

Cuatro fases hasta un resultado sólido

Sin cambio de plataforma y sin big bang. El camino funciona con lo que la mayoría de las organizaciones ya tiene.

Fase 1 · 2 semanas
Diagnóstico
Revisamos repositorios, escáneres existentes, histórico de hallazgos y responsabilidades. El resultado es una clasificación por exposición y clase de datos — y una línea base honesta.
Fase 2 · 4 semanas
Piloto
AI SAST en los repositorios más críticos, calibrado frente a hallazgos conocidos. En paralelo, las primeras validaciones: ¿qué rutas son realmente alcanzables?
Fase 3 · 6 semanas
Anclaje
Gates en el build, propuestas de corrección a los code owners, SLA por explotabilidad. Las excepciones se documentan y reciben fecha de caducidad.
Fase 4 · continuo
Operación
Análisis frontier periódico para las aplicaciones más críticas, informe de indicadores y reajuste. Como servicio gestionado si así se desea.

Qué queda sobre la mesa

Artefactos reutilizables — en el sprint, en la auditoría y en el cuestionario de cliente.

Registro de riesgo de repositorios

Todos los repositorios por exposición, clase de datos y responsabilidad — la base de cualquier decisión de cadencia.

Imagen objetivo de escaneo

Qué capa en qué repositorio y con qué frecuencia, incluida una estimación de coste y duración.

Lista de hallazgos validados

Rutas de ataque confirmadas con cadena de prueba y pasos de reproducción — separadas con claridad de los indicios sin confirmar.

Paquetes de corrección

Propuestas dirigidas a la causa raíz, entregadas como pull request a los code owners responsables siempre que sea posible.

Informes de ensayo y evaluación

En un formato que encaja en la documentación técnica que exige el anexo I del CRA.

Informe de indicadores

Proporción de hallazgos validados, tiempo de hallazgo a corrección, cobertura de responsabilidad y deuda de seguridad por antigüedad.

La conexión con normas y regulación

Trabajamos siguiendo referencias establecidas — para que los resultados convenzan dentro y se puedan demostrar fuera.

EU Cyber Resilience Act

El anexo I parte II exige un tratamiento eficaz de vulnerabilidades durante el periodo de soporte; los informes de ensayo forman parte de la documentación técnica.

Reglamento (UE) 2024/2847