Aikido Security's pentesting de IA encaja en el entorno que ya utilizas. Aunque estés convencido de tu código actual y de tus herramientas de e seguridad en la nube , puedes añadir pentesting de IA como complemento para detectar los fallos lógicos complejos que las herramientas determinísticas pasan por alto.
Si quieres profundizar en tus pruebas de penetración o comprobar cada lanzamiento, quizá estés buscando una solución que vaya más allá de contratar a pentester manuales. Cuando el First National Bank of America necesitó realizar una prueba de penetración en un nuevo portal para clientes con un plazo límite, su equipo ejecutó una prueba de penetración con Aikido AI en menos de un día. La prueba finalizó en 1 hora y 40 minutos y detectó un problema de alta gravedad, que el banco solucionó antes de que el portal se hiciera público. Dado que cada prueba dura unas horas, los equipos pueden ejecutarla cada vez que se produce un cambio en la aplicación, y cada prueba genera un informe listo para la auditoría.
Los lectores que aún estén eligiendo un proveedor deberían consultar la Guía del comprador depentesting de IA , pero si estás barajando seriamente la posibilidad de adquirir Aikido, sigue leyendo.
{{cta}}
Lo que necesitas para realizar una prueba de penetración con Aikido AI
Opcional, pero recomendable: las pruebas de caja blanca (que consisten en dar acceso a un pentest de IA a los repositorios conectados) detectan más vulnerabilidades que las pruebas de caja negra con el mismo número de créditos. Aikido Infinite (pentesting continuo) realiza pruebas de penetración en los cambios de las nuevas implementaciones.
Empieza con una prueba de penetración
No es necesario que incorpores ningún otro producto de Aikido para realizar una primera prueba de penetración, y todas las herramientas que ya tienes en tu entorno pueden quedarse exactamente donde están. Para las pruebas de penetración de aplicaciones web y API, la mayor parte de la configuración se reduce a dos decisiones: qué aplicación quieres someter a prueba y cuáles de sus dominios se incluyen en el alcance.
Recomendamos realizar la prueba de penetración en un entorno de prueba o de preproducción que sea idéntico al de producción, pero que utilice datos de prueba. De este modo, las pruebas se mantienen aisladas de tu aplicación en producción y permiten a los agentes llevarlas a cabo en su totalidad sin riesgo alguno para los usuarios reales ni para los datos.
Aikido también te pide que facilites a los agentes las credenciales de inicio de sesión y una cuenta para cada rol de usuario, como un usuario estándar y un administrador, de modo que puedan navegar por las áreas protegidas de la aplicación y comprobar si un rol puede acceder a datos que pertenecen a otro. Sin credenciales, la prueba solo muestra lo que vería un visitante anónimo.
Conectar tus repositorios es opcional, pero influye en lo que la prueba puede detectar. Las pruebas de caja blanca, con acceso al código fuente, son mucho más exhaustivas que las que no lo tienen; en más de 1.000 pruebas de penetración, las pruebas de caja blanca detectaron siete veces más vulnerabilidades que las de caja gris.
Esta profundidad también se ha puesto de manifiesto en la experiencia de los clientes de Aikido. El First National Bank of America puso en marcha su primera prueba de penetración apenas un día después de decidir utilizar Aikido, y el ingeniero de gestión de identidades y accesos del banco atribuyó el impacto de los resultados al enfoque de caja blanca, ya que los agentes disponían del contexto de cada repositorio.
«El hecho de que Aikido pudiera examinar nuestros repositorios y contar con ese contexto nos proporcionó tareas de corrección realmente útiles. Al disponer de esa información de fondo, se obtienen resultados mucho más detallados... Detectamos [una vulnerabilidad de alta gravedad] antes de que entrara en producción. Eso supone un claro valor añadido para nosotros».
La documentación de configuración explica detalladamente cada opción de evaluación y acceso.
Elegir qué someter a una prueba de penetración
Los términos relacionados con las pruebas de penetración se utilizan de forma imprecisa, por lo que conviene partir de lo que se quiere comprobar y, a partir de ahí, buscar el nombre adecuado.
Si quieres realizar pruebas en cada implementación, añade « pentesting continuo » con Aikido Infinite.
Para aquellas organizaciones que necesitan pruebas continuas, Aikido Infinite puede realizar pruebas de penetración de forma ininterrumpida a medida que la aplicación cambia. Utiliza la última evaluación completa como referencia y supervisa las ramas que configures. Cuando un cambio parece relevante para la seguridad, pone en marcha agentes específicos, ya sea en el momento de la implementación o según la programación que establezcas.
Antes de activarlo, comprueba que las personas adecuadas tengan los permisos necesarios, que las ramas o la programación se ajusten a la forma en que tu equipo realiza las entregas, que los agentes sigan pudiendo acceder a la aplicación y que dispongas de créditos suficientes para las pruebas previstas. Los repositorios también deben estar conectados, ya que Infinite los consulta para determinar qué cambios deben someterse a prueba.
Cómo integrar los resultados de « pentesting de IA » en tu flujo de trabajo de seguridad
Tus herramientas SAST y SCA siguen haciendo lo que hacen: detectar código de riesgo y dependencias vulnerables. La prueba de penetración responde a una pregunta diferente: qué es lo que un atacante puede aprovechar realmente en la aplicación en ejecución. Esto incluye fallos que el análisis estático no puede detectar, como control de acceso roto, o la falsificación de firmas electrónicas que los agentes de Aikido encontraron en una aplicación de firma de documentos y que se le pasó por alto al equipo de análisis manual.
Cada hallazgo es validado por otros agentes para descartar falsos positivos y confirmar su explotabilidad, de modo que los resultados de las pruebas de penetración pueden pasar directamente al principio de la cola sin necesidad de una clasificación manual previa. Además, cada hallazgo incluye una prueba de concepto y los pasos para reproducirlo, lo que significa que un desarrollador puede confirmar el problema sin tener que recurrir al equipo de seguridad para obtener más contexto. Los hallazgos se presentan con una clasificación de gravedad y un tiempo estimado de corrección, lo que permite al equipo establecer prioridades y asignar la corrección directamente a los desarrolladores.
Cómo corregir y volver a comprobar los resultados de las pruebas de penetración con IA
Una prueba de penetración que se suma a una lista de tareas pendientes ya sobrecargada no hace más que aumentar el volumen de trabajo, así que decide dónde se registrarán los hallazgos y quién se hará cargo de ellos antes de la primera ejecución. En una configuración sencilla, el equipo crea una tarea en su sistema de seguimiento existente para cada hallazgo, la vincula al hallazgo de Aikido y la asigna al desarrollador responsable del código afectado.
A continuación, la corrección pasa por el proceso habitual de revisión de código y se implementa en el entorno de pruebas, donde se vuelve a comprobar el hallazgo. Los resultados de estas nuevas pruebas te proporcionan la prueba de que el problema ha desaparecido, algo que una solicitud de incorporación de cambios fusionada por sí sola no puede demostrar. Si deseas que se creen tickets automáticamente o que se sincronice el estado, pruébalo con un hallazgo real de una prueba de penetración antes de implantarlo en todos los equipos. El tutorial sobre pruebas de penetración en CI/CD cubre este flujo de principio a fin.
Qué hay que decidir antes de tu primera prueba de penetración con IA
- Ámbito: Para las pruebas de penetración de aplicaciones web y API (abordaremos otros ámbitos en un artículo futuro), empieza por enumerar lo que necesitas someter a prueba, lo que suele incluir aplicaciones específicas, servidores, API y los roles de usuario que acceden a ellos. Es importante incluir cada rol, ya que muchos de los hallazgos más graves —como que un usuario acceda a los datos de otro— solo se detectan cuando la prueba puede iniciar sesión como más de un tipo de usuario. También tendrás que decidir si incluir todo tu perímetro expuesto a Internet o centrar la primera prueba en una sola aplicación.
- Acceso: Una prueba de penetración basada en IA solo puede analizar lo que está a su alcance, por lo que necesita credenciales para cada rol incluido en el alcance. También deberás decidir si quieres incluir el código fuente. Con acceso al código, la prueba puede rastrear un hallazgo hasta el archivo y la línea exactos, lo que agiliza la corrección. Sin él, la prueba funciona igual que lo haría un atacante externo, basándose únicamente en la aplicación en ejecución.
- Cadence: Una prueba de penetración puntual ofrece una visión de la situación en un momento dado, que suele ser lo que solicita un auditor o una revisión de seguridad de un cliente. Las pruebas continuas vinculadas a las implementaciones comprueban cada versión en el momento de su lanzamiento, de modo que un nuevo punto final se somete a prueba antes de que lleve meses en funcionamiento. La elección adecuada depende de la frecuencia con la que cambie tu aplicación y de quién solicite los resultados.
- Responsabilidades: Decide quién configura las pruebas, quién consulta los resultados, quién puede solicitar nuevas pruebas y quién aprueba las correcciones antes de que se obtengan los primeros resultados. Los resultados de las pruebas de penetración suelen afectar a varios equipos, por lo que aclarar esto desde el principio evita que un resultado crítico quede sin leer porque todo el mundo da por hecho que se encarga de él otra persona.
- Coste: El precio depende del número de evaluaciones que realices o del volumen de pruebas continuas que utilices. Al basarse en el uso, puedes adaptarlo al alcance que hayas elegido y ajustarlo a medida que dicho alcance cambie. Consulta los precios actuales de las pruebas de penetración para obtener más detalles.
Aikido pentesting de IA para aplicaciones web y el resto de la plataforma Aikido Security
Una prueba de penetración basada en IA de una aplicación web es una de las formas en que Aikido Security utiliza agentes autónomos para detectar vulnerabilidades, y cada uno de ellos comprueba algo que los demás, por su estructura, no pueden. Los mejores resultados se obtienen combinándolos, de modo que cada uno se ejecute donde resulte más económico y útil.
SAST Como opción predeterminada: el análisis determinístico SAST se ejecuta en cada confirmación y en el IDE, detectando patrones conocidos, como la inyección, siempre de la misma manera. Es lo suficientemente rápido y económico como para actuar de filtro en tu canalización de CI/CD, lo que lo convierte en la base sobre la que se construye todo lo demás. Sin embargo, no puede interpretar la intención, por lo que los fallos lógicos, como los IDOR y los « control de acceso roto », se dejan en manos de las capas superiores.
Auditoría de seguridad del código para nuevas aplicaciones y versiones importantes: la auditoría de seguridad del código analiza toda la base de código, siguiendo el recorrido de una solicitud desde el gestor de rutas hasta la consulta a la base de datos y comprobando si el código hace lo que se supone que debe hacer. Solo necesita acceso al repositorio, por lo que detecta fallos lógicos antes de que exista un entorno de producción en el que realizar pruebas, incluyendo el código oculto tras indicadores de funcionalidades y rutas exclusivas para administradores a las que una prueba de penetración quizá nunca llegue. Esto la convierte en el primer paso lógico al desarrollar una nueva aplicación o antes de un lanzamiento importante.
Revisión exhaustiva de PR para mantenerse al día entre lanzamientos: Deep PR Review aplica el mismo razonamiento a cada solicitud de incorporación de cambios, comprobando cómo interactúa cada modificación con el código del resto del repositorio y de los repositorios vinculados. Detecta los fallos lógicos que, de otro modo, aparecerían en la siguiente prueba de penetración o en producción, mientras el desarrollador que escribió la modificación aún recuerda por qué la escribió de esa manera.
pentesting de IA con una periodicidad que se adapte a tu nivel de riesgo: la prueba de penetración verifica todo esto con respecto a la aplicación en ejecución, y el alcance se garantiza mediante controles técnicos que mantienen a los agentes en los objetivos incluidos en la lista de permitidos y fuera del entorno de producción, a menos que se haya establecido deliberadamente dentro del alcance.
La frecuencia con la que se ejecute dependerá de los requisitos normativos y del grado de sensibilidad de tu sector. La mayoría de los equipos realizan pruebas anualmente o con cada lanzamiento importante, a menudo para cumplir con las normas SOC 2 o ISO 27001. Los equipos de sectores regulados o de alto riesgo que necesitan comprobar la vulnerabilidad de sus aplicaciones a medida que estas cambian utilizan Aikido Infinite, que realiza pruebas en cada implementación, y Aikido Machine ejecuta las mismas pruebas de penetración de forma local para sectores en los que el código no puede salir de la red. Las pruebas de penetración en redes externas abarcan todos los sistemas conectados a Internet que se encuentran bajo tu dominio.
Los resultados se incorporan directamente a la corrección de fallos. Cuando es posible, AutoFix propone cambios en el código para los hallazgos de las pruebas de penetración, y los desarrolladores los revisan y los incorporan, para luego volver a realizar las pruebas y confirmar que la corrección ha funcionado. Los equipos pueden empezar solo con « pentesting de IA » y añadir las demás capas más adelante, tal y como hizo Tyro cuando incorporó el resto de sus pruebas de aplicaciones a Aikido, junto con sus pruebas de penetración.
{{walkthrough}}
