Security Bench nos ha dejado una impresión poco habitual: es una herramienta de seguridad ambiciosa que permite empezar sin convertir la instalación en el primer ejercicio de resistencia. En Enclave Guard probamos personalmente la CLI comunitaria. Fue fácil instalarla, configurarla y ejecutar sus distintos modos. También encontramos un límite que conviene explicar bien: los resultados de endpoint necesitan juicio externo y parte del contenido de comprobación llega desde una API.
La valoración general es positiva. Lo situaríamos en desarrollo, staging o preproducción, con recursos suficientes y una planificación sensata del volumen de peticiones. No es un sello automático de seguridad ni una excusa para lanzar pruebas agresivas contra producción. Bien utilizado, ayuda a reunir evidencias y a formular preguntas que un equipo de IA debería responder antes de desplegar.
Qué hace Security Bench
Security Bench es una herramienta de línea de comandos en Python para probar pipelines de IA y LLM, según su web oficial y su repositorio público. El manual oficial separa dos funciones que se complementan: las pruebas de endpoints y la auditoría de proyectos locales. La versión pública revisada es la 0.3.0 y el README la marca como Beta. El paquete de PyPI requiere Python 3.9 o superior y declara cinco dependencias directas pequeñas: Click, HTTPX, PyYAML, Rich y python-dotenv.
No es una clasificación definitiva de modelos. sb scan envía prompts adversariales, conserva las respuestas e incluye criterios para evaluarlas después. La auditoría local busca patrones en código, infraestructura y configuración. Cada modo produce evidencias distintas.
Las cifras varían según la fuente. La web habla de 327 comprobaciones locales y 32 categorías; el manual habla de unas 330 pruebas comunitarias y 31 categorías de endpoint; y el README cita más de 1.400 prompts y 330 comprobaciones locales. Es un catálogo vivo. No usaríamos una cifra exacta como titular: importa más que el operador pueda filtrar y repetir las pruebas.
Una puesta en marcha sin drama
Hicimos la verificación en un entorno aislado con uv venv y uv pip install securitybench==0.3.0. sb --version devolvió 0.3.0. Después generamos el preset para Ollama y ejecutamos un dry run. Al recibir una URL base de Ollama, la CLI la normalizó correctamente a /api/chat.
Muchas herramientas de seguridad hacen perder tiempo antes de mostrar qué pretenden ejecutar. Aquí pudimos instalar, configurar y revisar el plan con rapidez. También fue fácil cambiar de modo sin aprender una interfaz distinta para cada tarea.
El repositorio documenta presets para Ollama, servicios compatibles con OpenAI y Anthropic. Si el endpoint utiliza un formato propio, el YAML permite definir la petición, las cabeceras y la ruta de la respuesta que contiene el texto del modelo. Esa flexibilidad es necesaria en sistemas reales, donde suelen existir gateways, capas RAG, agentes o lógica de aplicación entre el usuario y el modelo.
Antes de enviar prompts, el dry run muestra el endpoint normalizado y parámetros como el modelo, las categorías, la severidad y el límite. Nuestra recomendación es utilizarlo siempre. Una herramienta de pruebas adversariales debería decir con claridad adónde va a llamar y cuánto trabajo piensa realizar.
Probar endpoints exige planificar capacidad y coste
El comando principal es sb scan. Un límite bajo sirve como prueba de humo. El modo balanced toma una muestra por categoría y --per-category amplía la profundidad. También hay filtros por categoría y severidad, retardo entre peticiones y cabeceras personalizadas. La salida puede ser texto, JSON o Markdown. Los resultados pueden guardarse y, en el código actual, el fichero se actualiza después de cada prueba, una decisión útil cuando la ejecución es larga.
En el commit revisado, ef5e05c26f14e464d0ccde9bf243f8a675afa20f, las pruebas de endpoint se ejecutan secuencialmente. Eso evita disparar una avalancha concurrente, pero no convierte una pasada equilibrada o exhaustiva en una tarea ligera. Puede haber muchas solicitudes de inferencia. Algunas pruebas requieren varios turnos, y cada respuesta consume tiempo, capacidad del servidor y dinero si el modelo está detrás de una API de pago.
Siempre que sea práctico, ejecutaríamos Security Bench en una máquina distinta de la que sirve el modelo. Así es más sencillo observar la contención de recursos y se reduce el riesgo de que el propio banco de pruebas cambie el comportamiento que intenta medir. Si ambos deben compartir equipo, hay que reservar CPU, memoria y almacenamiento para la CLI, además de capacidad suficiente de inferencia, GPU o aceleración para el servicio del modelo.
Conviene empezar con un dry run, pocas pruebas y categorías seleccionadas. Primero se validan autenticación, parseo, almacenamiento y límites. En una API externa, calculamos el coste antes de ejecutar. En una plataforma interna, acordamos la ventana con operaciones y vigilamos latencia, errores y utilización.
Las respuestas se recogen; el veredicto semántico viene después
El manual y el repositorio muestran que la CLI comunitaria guarda passed: null en los resultados de endpoint. Cada elemento incorpora el prompt de ataque, la respuesta y criterios para decidir si el intento fue bloqueado o tuvo éxito. Security Bench no produce por sí solo el veredicto semántico final en este flujo: su documentación indica que el usuario debe pedir a Claude u otro LLM que aplique esos criterios.
La diferencia es importante. Un LLM utilizado como juez sigue siendo otra capa de evaluación. El modelo elegido, las instrucciones y el contexto pueden cambiar la decisión. Conservaríamos las respuestas originales, documentaríamos qué juez y qué prompt se emplearon, revisaríamos manualmente una muestra y exigiríamos análisis humano para cualquier fallo con consecuencias relevantes.
El flujo sigue siendo útil para repetir pruebas, detectar regresiones y volver sobre categorías problemáticas. La descripción honesta sería «pruebas adversariales estructuradas con evaluación semántica externa», no «certificación automática de que la IA es segura».
Auditar el proyecto, no solo el modelo
La segunda familia de comandos mira el entorno local. sb audit reúne la revisión completa; sb infra, sb code y sb config permiten acotarla. Las comprobaciones abarcan ficheros de contenedores y Kubernetes, permisos, código, construcción de prompts, tratamiento de salidas, secretos, logging y CORS. sb fix ofrece orientación de remediación para los hallazgos.
Esta visión evita dedicar toda la atención a los jailbreaks mientras se ignoran credenciales, permisos o configuraciones ordinarias. El OWASP Top 10 para aplicaciones LLM incluye inyección de prompts, divulgación de información sensible, cadena de suministro, agencia excesiva y consumo sin límites. Security Bench relaciona pruebas de endpoint y comprobaciones locales con ese modelo de OWASP. Ninguna CLI demuestra que todo esté resuelto, pero combinar comportamiento y artefactos ofrece una imagen más útil.
Para un equipo que ya tenga un proceso de gestión de vulnerabilidades, los hallazgos de Security Bench deberían entrar como otra fuente de trabajo y evidencia de regresión. La herramienta no sustituye el inventario, el análisis de dependencias, el pentesting, el modelado de amenazas ni la revisión humana. Sí puede encontrar asuntos que merecen propietario, prioridad y seguimiento.
El límite de confianza que no conviene ignorar
El manual y el código muestran que Security Bench descarga definiciones de pruebas y comprobaciones desde https://api.securitybench.ai y las guarda en ~/.securitybench/cache. La ventaja es clara: el catálogo puede actualizarse sin publicar una nueva versión del paquete por cada cambio. La consecuencia es que el código instalado desde PyPI no es la única entrada que determina lo que hará una ejecución.
La auditoría local requiere especial atención. En el repositorio público, commit ef5e05c26f14e464d0ccde9bf243f8a675afa20f, las comprobaciones basadas en comandos pueden ejecutar con shell=True patrones recibidos de la API dentro del directorio analizado. No afirmamos que el servicio sea malicioso. Señalamos un límite de ejecución que debe entenderse antes de apuntar la herramienta a un repositorio valioso o a la estación de trabajo de un desarrollador.
Fijaríamos y revisaríamos la versión, comprobaríamos la procedencia del contenido descargado e inspeccionaríamos la caché cuando el riesgo lo justificase. Para auditorías locales, usaríamos un clon desechable o contenedor con permisos mínimos y sin secretos. El README enlaza documentación ausente en el commit revisado; conviene consultar también el manual web y el código.
El proyecto utiliza Elastic License 2.0. El código está disponible públicamente y puede reutilizarse bajo las restricciones de ELv2, incluida la prohibición de ofrecer el software como servicio alojado o gestionado. Como explica la información de licencia de Elastic, ELv2 es una licencia source-available, no una licencia de código abierto aprobada por la OSI. La precisión jurídica no resta mérito al trabajo público; evita atribuirle una clasificación que no tiene.
Su lugar razonable en el ciclo de desarrollo
Security Bench encaja mejor como herramienta de desarrollo y validación previa al lanzamiento. Las auditorías locales pueden ejecutarse mientras cambian el código y la configuración. Un endpoint de integración permite ajustar autenticación y parseo. Staging o preproducción son los lugares adecuados para una batería más representativa, cuando RAG, herramientas, guardrails y observabilidad se parecen al diseño final.
Probar en producción exige otro nivel de control. No lanzaríamos una colección adversarial contra un servicio real sin autorización expresa, alcance acordado, planificación de límites y coste, protección de datos y condiciones para detener la prueba. Si hay agentes o herramientas conectadas, también valoraríamos qué acciones secundarias podrían activar los prompts.
En nuestro trabajo de IA y automatización aplicamos el mismo criterio: la validación debe cubrir el sistema que toma decisiones, llama a herramientas y maneja datos, no solo el modelo de base. Security Bench puede aportar evidencias a esa revisión. Enclave Guard no convertiría su primer porcentaje en una garantía ni en material comercial.
Mérito para quien construye seguridad en público
Disfrutamos de verdad probando Security Bench. El manual oficial atribuye su creación a Mikko Niemela. Ha creado una herramienta que combina alcance con una entrada amable. La instalación es ligera, los modos se entienden y la propuesta obliga a mirar tanto el comportamiento adversarial del endpoint como esos ficheros menos vistosos que suelen decidir la seguridad real.
El reconocimiento no termina en una persona. Quienes publican herramientas, investigación y material de prueba permiten que equipos pequeños conviertan buenas ideas en trabajo operativo. El código visible deja revisar supuestos, detectar límites peligrosos, aprender del diseño y plantear críticas que mejoran el proyecto. Los desarrolladores que hacen este trabajo son los héroes discretos del ecosistema de seguridad: convierten investigación y experiencia difícil de ganar en herramientas que otros equipos pueden usar de verdad.
Recomendamos probar Security Bench en un entorno aislado y no productivo, empezar con un dry run y leer las evidencias guardadas antes de perseguir una nota. Se puede disfrutar del proyecto, agradecer el trabajo de su autor y mantener intacto el escepticismo profesional. Las tres cosas caben perfectamente en una revisión honesta.
¿Estás desarrollando un servicio con IA? Enclave Guard puede ayudarte a revisar la arquitectura, los controles y el plan de validación antes de producción.
