El pentesting tenía sentido cuando las versiones se lanzaban cada pocos meses. Una evaluación puntual podía ofrecer una imagen precisa del riesgo durante semanas, a veces meses. Hoy en día, los equipos de ingeniería despliegan continuamente. Nuestra encuesta sobre el estado de la IA en el pentesting, realizada a 200 CISOs y 200 líderes de ingeniería, reveló que el 76% despliega cambios significativos al menos semanalmente, mientras que casi el 40% lo hace a diario. Sin embargo, solo el 21% valida la seguridad en cada versión.
Esa brecha tiene consecuencias.
- El 79% está preocupado por pasar por alto vulnerabilidades entre pentests.
- La mitad dice que los hallazgos ya están desactualizados cuando llega el informe.
- El 64% dice que los plazos de las pruebas de seguridad influyen en las decisiones de lanzamiento, ya sea retrasando los despliegues o forzando a los equipos a aceptar riesgos adicionales.
Para muchas organizaciones, el pentesting de IA se está convirtiendo en la forma práctica de cerrar esa brecha. Pero como sigue siendo una categoría relativamente nueva, los compradores a menudo evalúan las plataformas utilizando criterios diseñados para las pruebas de penetración tradicionales. Esos criterios ya no indican qué plataforma funcionará mejor una vez que forme parte de su flujo de trabajo de desarrollo.
Preguntas que todo proveedor de pentesting de IA debería poder responder
Todo proveedor puede demostrar el descubrimiento de vulnerabilidades.
Las preguntas más difíciles surgen una vez que la plataforma se integra en su flujo de trabajo de ingeniería. ¿Puede utilizar el código fuente? ¿Cómo se evita que los agentes de IA se salgan del alcance? ¿Seguirá la plataforma aportando valor a medida que su software evolucione?
¿Puede la plataforma utilizar el código fuente?
En más de 1.000 pentests de IA, las pruebas de caja blanca descubrieron 7 veces más vulnerabilidades, requiriendo menos intentos que las pruebas de caja gris por sí solas.
No todas las plataformas de pentesting de IA admiten pruebas de caja blanca, y las que sí lo hacen no necesariamente utilizan el código fuente de la misma manera. Comprender cómo los proveedores utilizan el código y la evidencia detrás de los resultados debe ser parte de cada evaluación.
Pregunte a los proveedores:
- ¿La plataforma admite pruebas de caja blanca?
- ¿El acceso al código es opcional?
- ¿Cómo se utiliza el código fuente durante las pruebas?
- ¿Cómo se protege el código fuente del cliente?
- ¿Qué evidencia demuestra que el acceso al código mejora los resultados?
¿Está comparando a los proveedores de manera justa?
Una evaluación de proveedores solo es útil si cada plataforma se prueba bajo condiciones comparables.
Si un proveedor recibe código fuente y otro no, o si una plataforma funciona durante un tiempo significativamente mayor o consume sustancialmente más créditos, los informes finales resultan difíciles de comparar.
Una de las recomendaciones de la guía es:
La checklist amplía esto con preguntas prácticas que abarcan autenticación, código fuente, alcance, validación e informes, para que cada proveedor se evalúe bajo las mismas condiciones.
¿Cómo se mantiene el testing dentro del alcance?
Los agentes de IA están diseñados para explorar aplicaciones. Los compradores deben comprender exactamente cómo se aplican esos límites.
Pregunte cómo se aplica el alcance. ¿Se puede excluir la producción por defecto? ¿Están los dominios en lista blanca? ¿Qué ocurre si un agente sigue una redirección fuera del entorno acordado? ¿Se pueden monitorizar o detener las pruebas mientras se ejecutan?
Las plataformas más robustas aplican estos controles técnicamente, en lugar de depender de indicaciones o instrucciones escritas.
¿Cómo sigue la plataforma el ritmo de los cambios de software?
Los equipos de ingeniería modernos no dejan de desplegar después de que una prueba de penetración haya finalizado. El nuevo código, las nuevas funcionalidades y las nuevas dependencias cambian la superficie de ataque.
Pregunte a los proveedores cómo se integra su plataforma en su proceso de lanzamiento. ¿Puede el testing ejecutarse automáticamente a medida que el software cambia? ¿Con qué rapidez se puede incorporar una nueva aplicación? ¿Se vuelven a probar las correcciones sin programar otra intervención? ¿Cuánto tiempo se tarda en obtener los primeros resultados significativos?
Estas preguntas cobran cada vez más importancia para las organizaciones que despliegan varias veces a la semana o que integran la seguridad directamente en CI/CD.
Señales de alarma comunes durante una evaluación
La guía también destaca señales de advertencia que merecen un examen más detenido.
- Los proveedores no pueden explicar cómo se validan los hallazgos.
- Se descarta el acceso al código sin pruebas comparativas.
- Las barreras de seguridad dependen de indicaciones en lugar de controles técnicos.
- Cada demostración se centra en vulnerabilidades OWASP conocidas con poca evidencia de pruebas de lógica de negocio.
Ninguno de estos puntos descarta automáticamente una plataforma, pero cada uno merece un examen más detenido antes de tomar una decisión.
Descargue la Guía del Comprador de pentesting de IA
Los ejemplos anteriores son solo una pequeña parte del marco de evaluación.
La guía completa también incluye:
- Una checklist práctica para la evaluación de proveedores
- Comparaciones entre pentesting de IA y manual
- Investigación de más de 1.000 pentests de IA
- Análisis de pruebas de caja blanca frente a caja gris
- Hallazgos clave de nuestro informe 'Estado de la IA en el pentesting'
- Un estudio de caso de cliente anonimizado donde el pentesting de IA descubrió 13 problemas después de que un pentest manual de 120 horas no reportara ninguno
Tanto si está evaluando Aikido como otra plataforma, la guía está diseñada para ayudarle a comparar a cada proveedor con el mismo conjunto de criterios.
Descargue la guía completa aquí:
