En caja negra encuentras lo que se ve. En caja blanca encuentras lo que hay.

En caja negra atacamos desde fuera sin información: vemos lo que se ve y encontramos lo que da tiempo a encontrar. En caja blanca partimos del código, las credenciales y la arquitectura, así que revisamos el 100% de lo que hay en el alcance. La diferencia se nota sobre todo en dos sitios: control de acceso y lógica de negocio. Desde fuera, un fallo de autorización se comporta exactamente igual que el funcionamiento correcto, porque la aplicación devuelve un 200 y un dato válido. Solo que el dato es de otro cliente.

Sí, es lo que hace que sea caja blanca. Firmamos NDA antes de cualquier acceso, trabajamos sobre una copia en entorno aislado y no conservamos el código al terminar: se destruye tras la entrega del informe y te lo confirmamos por escrito. Si tu política no permite que el código salga de la empresa, podemos trabajar en tus instalaciones o contra tu repositorio con una cuenta de solo lectura y sin descargar nada.

Un SAST es un buen filtro de higiene y de hecho lo usamos como primer paso, pero no entiende tu negocio. No sabe que ese descuento no debería poder encadenarse, que ese identificador no debería ser incremental o que ese endpoint interno lleva dos años publicado. Esos son fallos de lógica y de autorización, y son justamente los que más caros salen. Se encuentran leyendo el código con contexto, no con una regla genérica. Si ya tienes un SAST en el pipeline, mejor: partimos de ahí y no perdemos tiempo en lo obvio.

No trabajamos en producción. La explotación y las pruebas de concepto se hacen en preproducción o en una copia con datos anonimizados que preparamos contigo en la fase de accesos. Si por algún motivo hay que validar algo concreto en producción, se acuerda ventana por escrito y se hace con tu equipo delante. La revisión de código en sí no tiene ningún impacto sobre tus sistemas.

Te llamamos el mismo día. No esperamos al informe final para avisar de un hallazgo crítico, y mucho menos si aparecen indicios de que alguien ya ha estado dentro. En ese caso paramos, te lo explicamos y decidimos contigo si esto se convierte en respuesta a incidente.

El informe incluye el cómo, no solo el qué: cada hallazgo lleva los pasos concretos de corrección y el riesgo de aplicarlos. En la modalidad Extendida acompañamos a tu equipo de desarrollo durante la corrección y hacemos re-test a los 60 días para verificar que se cerró de verdad. Si prefieres que implementemos nosotros las correcciones, se dimensiona como servicio aparte.

Sí. El informe documenta alcance, metodología, fecha, hallazgos con evidencia y plan de corrección. Es exactamente lo que piden los cuestionarios de proveedor, los auditores de ENS e ISO 27001 y las aseguradoras cuando preguntan cómo verificas la seguridad de tu software antes de publicarlo. Las empresas que aportan auditoría de aplicación documentada suelen mejorar condiciones frente a las que solo declaran antivirus y copias de seguridad.

Sirve, y suele ser donde más aparece. El código antiguo acumula excepciones que se metieron para salir del paso, permisos que se ampliaron para una migración y funciones que ya nadie llama pero siguen accesibles. Lo que cambia es el dimensionado: en esos casos acotamos el alcance a los flujos que mueven dinero o datos sensibles en lugar de intentar cubrirlo todo, y lo dejamos claro en la propuesta.