Pentest de caja negra, gris o blanca: cuál elegir en 2026

Caja negra, caja gris y caja blanca (black box, grey box y white box) son las tres modalidades de pentest, definidas según cuánto acceso y conocimiento recibe el investigador sobre el sistema antes de empezar el trabajo. La caja negra parte de cero (como un atacante externo real); la caja gris recibe credenciales y documentación básica; la caja blanca recibe acceso completo (código, base de datos, infraestructura).

La elección entre las tres impacta directamente en la cobertura, la profundidad técnica, el tiempo de ejecución y el precio. Esta guía explica cada modalidad a fondo, las compara dimensión por dimensión y muestra exactamente cuándo contratar cada una — con recomendaciones específicas por tamaño de empresa y sector (SaaS B2B, fintech, e-commerce, healthtech).

Resumen ejecutivo: comparación rápida

Black box: pentest de caja negra

Qué es

En la caja negra, el investigador no recibe absolutamente nada. Empieza de cero, como empezaría un atacante externo real: solo con el nombre de dominio, una IP o una URL pública. Sin credenciales, sin documentación, sin acceso a la infraestructura, sin código.

Cómo funciona en la práctica

• El investigador hace un reconocimiento completo: descubrimiento de subdominios, mapeo de endpoints públicos, análisis de los bundles de JavaScript expuestos, fingerprinting de tecnologías, OSINT
• Intenta crear una cuenta como usuario común (si la aplicación permite el registro público)
• Ataca solo lo que está expuesto públicamente
• Busca configuraciones incorrectas expuestas (buckets S3 públicos, CORS permisivo, encabezados ausentes, endpoints v1/v2/staging olvidados)

Lo que la caja negra encuentra bien

• Vulnerabilidades accesibles desde el exterior
• Configuraciones incorrectas de infraestructura expuestas
• Fallas en la autenticación, el registro y la recuperación de contraseña
• Ataques previos a la autenticación (SSRF en endpoints públicos, NoSQL injection en el login)
• Fuga de información en las respuestas (stack traces, encabezados de debug)

Lo que la caja negra NO encuentra bien

• Bugs internos de la aplicación (a fondo, después del login)
• Lógica de negocio de las áreas privadas
• Fallas en los flujos administrativos
• Bugs en APIs internas que no aparecieron en el reconocimiento
• BOLA cross-tenant (requiere 2 o más cuentas en tenants distintos)
• Race conditions internas

Cuándo contratar caja negra

• Simulación fiel de un atacante externo — cuando el cliente quiere ver exactamente “cómo nos ve un atacante desde afuera”
• Primer pentest con un proveedor nuevo — todavía no hay confianza, y la caja negra deja claro qué es capaz de descubrir el proveedor por su cuenta
• Validación de la superficie de ataque — verificar qué quedó expuesto sin querer
• Cumplimiento de un requisito específico — algunos marcos regulatorios exigen pruebas “sin asistencia”

Grey box: pentest de caja gris ⭐ La modalidad más común

Qué es

En la caja gris, el investigador recibe credenciales válidas de distintos roles (por ejemplo: 1 admin, 1 usuario común, 1 viewer) y documentación básica del sistema — normalmente el Swagger/Postman de la API, la lista de URLs principales y diagramas de alto nivel. Sin acceso al código fuente.

Cómo funciona en la práctica

• El investigador inicia sesión en varias cuentas en paralelo
• Mapea rápidamente los flujos posteriores a la autenticación (sin perder tiempo en reconocimiento)
• Prueba el acceso cross-tenant — el cliente A accediendo a datos del cliente B —, algo que solo es posible con 2 o más cuentas
• Prueba la escalada de privilegios — un viewer que se convierte en admin
• Cubre el OWASP API Top 10 completo
• Evalúa el abuso de la lógica de negocio en flujos legítimos (manipulación de precios, race en cupones, bypass del antifraude)

Lo que la caja gris encuentra muy bien

• BOLA cross-tenant (filtración de datos entre clientes) — el bug #1 del OWASP API Top 10 y el más devastador en un SaaS B2B
• BFLA (acceso a endpoints de admin como usuario común)
• BOPLA / mass assignment (modificar campos privados vía PATCH)
• Abuso de la lógica de negocio (manipulación de precios, race en cupones, doble reembolso)
• OAuth ATO en flujos posteriores al login (state confusion, scope escalation — ver OAuth account takeover en SaaS B2B)
• Race conditions en endpoints financieros (ver Race condition en Pix, el sistema de pagos instantáneos de Brasil)

Lo que la caja gris NO encuentra tan bien

• Bugs en capas profundas del código (race conditions internas en queries)
• Configuraciones incorrectas de la infraestructura interna (IAM permisivo, network policies)
• Secrets hardcodeados en el código o en el historial de Git
• Vulnerabilidades en dependencias (CVEs específicos en librerías)
• Fallas de diseño de la arquitectura

Cuándo contratar caja gris

• La opción por defecto para la mayoría de los pentests de SaaS B2B y de fintechs modernas — la mejor relación costo-beneficio
• Renovación anual del pentest — la modalidad estándar para una cobertura regular
• Pentest alineado a los sprints (PTaaS) — en los modelos recurrentes, la caja gris es el estándar
• Preparación para SOC 2 / ISO 27001 — satisface al auditor sin inflar el costo
• Cuando el tiempo es limitado — se salta el reconocimiento y va directo a donde hay retorno

White box: pentest de caja blanca

Qué es

En la caja blanca, el investigador recibe acceso TOTAL al sistema: todo lo de la caja gris más el código fuente completo (repositorio Git), acceso a la base de datos (esquema + datos), acceso a la infraestructura (consola de AWS, Kubernetes, logs), documentación completa de la arquitectura y disponibilidad del equipo de ingeniería para conversar (threat modeling colaborativo).

Cómo funciona en la práctica

• El investigador combina análisis de código (estático) con explotación activa (dinámica)
• Mapea los flujos críticos a partir del código antes de atacar
• Identifica vulnerabilidades “invisibles” desde afuera (race conditions en queries internas, código muerto que se convierte en backdoor, secrets en commits antiguos)
• Hace una revisión de arquitectura e identifica problemas de diseño (no solo de implementación)
• Puede ejecutar herramientas de análisis estático (SAST) y validar manualmente los hallazgos
• Analiza a fondo las configuraciones incorrectas en la nube (IAM, S3 policies, network ACLs)

Lo que la caja blanca encuentra excepcionalmente bien

• Race conditions complejas
• Vulnerabilidades de deserialización
• SQL injection en queries internas
• Secrets filtrados en el código o en el historial de Git (API keys, credenciales hardcodeadas, tokens OAuth)
• Vulnerabilidades en dependencias (CVEs específicos)
• Fallas de diseño (no solo de implementación)
• Backdoors accidentales dejados por desarrolladores
• Configuraciones incorrectas profundas en la nube (IAM permisivo, bucket policy)
• Verificación de propiedades criptográficas (gestión y rotación de claves)

Para qué NO tiene sentido la caja blanca

• Reconocimiento (ya tiene toda la información)
• Simular a un “atacante externo a ciegas” (pierde el sentido — para eso, usa caja negra)

Cuándo contratar caja blanca

• Antes de lanzar una funcionalidad crítica — producto financiero, flujo de pago, integración regulada
• Preparación para SOC 2 Type II o ISO 27001 — el auditor pide caja blanca para validar los controles técnicos
• Diagnóstico inicial profundo en una empresa que nunca hizo un pentest serio
• Due diligence técnica en fusiones y adquisiciones (M&A)
• Threat modeling previo a la arquitectura de un sistema crítico antes del go-live
• Sectores regulados (en Brasil: fintechs supervisadas por el BACEN y healthtechs sujetas al Art. 11 de la LGPD, la ley de protección de datos del país) — auditoría en profundidad

Comparación detallada, dimensión por dimensión

Cómo usa realmente el mercado cada modalidad en 2026

Distribución típica de modalidades en los pentests realizados en Brasil en 2026:

• ~60% caja gris — el mejor ROI para el cliente medio (SaaS B2B, fintech en etapa temprana, e-commerce, marketplace)
• ~25% caja negra — cuando el cliente quiere una simulación fiel o es su primer pentest y todavía no confía en el proveedor
• ~15% caja blanca — cuando hay regulación exigente (Resolución 4.893 del BACEN, PCI DSS 4.0, SOC 2 Type II) o el cliente ya es maduro en seguridad

Árbol de decisión: cuál elegir según tu escenario

Para SaaS B2B pequeño o mediano

Caja gris por defecto. Cobertura completa de multi-tenant, OAuth, BOLA y lógica de negocio sin inflar el costo. Consulta Pentest para SaaS.

Para fintech en etapa temprana

Caja gris anual + un módulo de caja blanca en los flujos financieros críticos (pagos instantáneos como Pix o SPEI, conciliación, antifraude). A medida que madura, conviene evolucionar a una caja blanca completa. Consulta Pentest para fintech.

Para banco digital / fintech enterprise

Caja blanca obligatoria en cualquier proyecto formal. En Brasil, la Resolución 4.893 del BACEN y la Resolución BCB 85 esperan esa profundidad. Consulta Pentest para medios de pago.

Para e-commerce / marketplace

Caja gris por defecto. La caja negra sirve para validar la exposición externa de una funcionalidad nueva. Consulta Pentest para e-commerce y Pentest para marketplaces.

Para healthtech / clínica digital

Caja gris + módulo de caja blanca en los flujos de historia clínica y recetas (datos de salud sensibles; en Brasil, Art. 11 de la LGPD). Consulta Pentest para healthtech.

Para preparar SOC 2 Type II o ISO 27001

Caja blanca recomendada. Ninguna de las dos normas la exige, pero los auditores suelen valorar la cobertura más amplia que ofrece.

Para startup en etapa temprana (MVP, sin ingresos recurrentes)

Caja negra como primer pentest. Valida la superficie externa con un presupuesto limitado. A medida que crezca, evoluciona a una caja gris anual.

Modelo híbrido: lo que está haciendo toda fintech seria

En la práctica, una fintech madura en 2026 no elige un solo modelo. Combina:

• 1 caja blanca anual — deep dive completo, cobertura máxima, alimenta el expediente regulatorio
• 2 a 4 pentests de caja gris trimestrales — cobertura ágil de las funcionalidades nuevas
• Pentest alineado a los sprints (PTaaS) en caja gris — recurrente y mensual: cada funcionalidad pasa por una validación adversarial antes de llegar a producción
• Caja negra puntual cuando se lanza una funcionalidad con exposición externa (un SDK público nuevo, una integración nueva con terceros)

Qué considerar al decidir

1. Madurez de seguridad actual

Sin ningún pentest previo, conviene empezar con caja gris o caja blanca para tener una línea base real. La caja negra en una organización inmadura subestima la exposición.

2. Regulación aplicable

Los sectores regulados (BACEN en Brasil, PCI DSS, SOC 2, ISO 27001) esperan cada vez más profundidad. La caja blanca desbloquea certificaciones.

3. Frecuencia de releases

Un equipo de producto que hace deploy cada semana necesita caja gris recurrente, alineada a los sprints. Un pentest puntual anual queda obsoleto en semanas.

4. Presupuesto disponible

La caja negra es la más barata y la caja blanca, la más cara (con el mismo total de horas). La caja gris suele ser el punto óptimo de costo-beneficio.

5. Disponibilidad interna

La caja blanca exige acceso al código y a la infraestructura: si tu equipo es restrictivo con eso, la caja gris puede ser el único camino viable.

Preguntas frecuentes

¿La caja negra siempre es más barata?

Por hora, sí. Pero el total de horas puede ser mayor, porque dedica mucho tiempo al reconocimiento. En un proyecto pequeño (hasta 50 endpoints), la caja gris suele costar algo similar a la caja negra, con el doble de cobertura.

¿Vale la pena la inversión extra en caja blanca?

En un SaaS inmaduro o antes de un lanzamiento crítico, sí. Los bugs que solo aparecen en el código (race conditions internas, secrets hardcodeados, vulnerabilidades en dependencias) pueden costar millones en una brecha posterior. En un SaaS ya maduro, con pentests recurrentes de caja gris, la diferencia de cobertura se justifica menos.

¿La caja gris cumple con SOC 2 e ISO 27001?

Sí, con una salvedad. El auditor acepta caja gris en el ciclo regular si hay una caja blanca anual complementaria. Una caja gris sola, sin caja blanca, puede ser cuestionada en un SOC 2 Type II riguroso.

¿Puedo empezar con caja negra y evolucionar?

Sí, es una práctica común con proveedores nuevos. El primer pentest en caja negra genera confianza. El segundo evoluciona a caja gris. El tercero, a caja blanca, cuando ya hay una relación establecida.

¿La caja negra es más “realista” que la caja gris?

Para simular a un atacante externo SIN credenciales, sí. Pero la mayoría de los ataques reales exitosos parte de credenciales comprometidas (phishing, filtraciones, insiders). La caja gris simula esa realidad posterior al compromiso de una credencial, que en la práctica es más relevante.

¿Cuánto tiempo toma cada modalidad?

En un proyecto comparable: caja negra, ~3 semanas (mucho tiempo en reconocimiento); caja gris, ~2 semanas (foco en la explotación); caja blanca, ~3–4 semanas (más cobertura por hora, pero el alcance crece naturalmente).

Conclusión: cómo elegir hoy

En el 99% de los casos, la caja gris es la respuesta correcta para SaaS B2B, fintechs en etapa temprana, e-commerce, marketplaces y healthtechs. Combina una cobertura amplia (60–75%), un costo moderado y velocidad de ejecución.

Usa caja negra cuando necesites simular solo la exposición externa o sea tu primer proyecto con un proveedor nuevo. Usa caja blanca cuando necesites la máxima profundidad: preparación para un cumplimiento exigente, lanzamiento crítico, due diligence técnica o sector regulado.

Y, sobre todo: combina modalidades a lo largo del tiempo. Una empresa seria en 2026 no se queda en un solo modelo. Caja gris anual + caja blanca semestral en las áreas críticas + caja negra puntual cuando lanzas una funcionalidad con exposición externa = una postura de seguridad madura.

Para conversar sobre qué modalidad tiene más sentido en tu escenario, consulta la oferta de No Vuln o la guía de precios por tamaño y sector (mercado brasileño). Para comparar con otras empresas de pentest en Brasil, revisa la comparación de 10 empresas.