Para equipos que desarrollan analizadores, bibliotecas, SDK, protocolos o componentes de aplicación que procesan entradas no fiables.

Cuando archivos, mensajes o entradas malformados podrían revelar una debilidad.

Qué examinamos

Evaluar la viabilidad del objetivo, los requisitos de compilación, los puntos de entrada y los objetivos de las pruebas.
Configurar y ejecutar el enfoque de pruebas acordado para el componente seleccionado.
Investigar y deduplicar los fallos, minimizar los ejemplos útiles y evaluar su relevancia para la seguridad.

Cómo se desarrolla un encargo

Envíe un breve resumen

El producto, qué ha cambiado, qué necesita saber y para cuándo. Basta con un párrafo; respondo en un plazo de tres días.

Reciba una propuesta por escrito

Alcance, metodología, exclusiones, entregables, precio y fechas. La confidencialidad, el NDA y las condiciones de la nueva prueba se acuerdan en la misma propuesta.

Siga el trabajo a medida que avanza

En las evaluaciones, verá las evidencias y las prioridades a medida que surgen. En los proyectos de desarrollo, revisará los hitos acordados.

Informe y sesión de resultados

Recibe el informe o el trabajo entregado y una sesión de revisión con su equipo. Cualquier corrección o verificación posterior se acuerda con usted.

Encuentro la causa y escribo la corrección.

Escribí los parches de dos CVE del kernel de Linux y otras siete correcciones que ya están en la rama principal. En su producto, cada hallazgo incluye la ruta en el código, las condiciones que lo desencadenan y una corrección que su equipo puede revisar.

Ver los 9 parches del kernel aceptados

Preguntas antes de empezar

¿Qué hace que un objetivo sea adecuado para el fuzzing?

Un componente con límites de entrada claros y un entorno de compilación o ejecución que podamos ejercitar. Los analizadores, las bibliotecas y los manejadores de protocolos son buenos candidatos. Confirmamos la idoneidad antes de comprometer una campaña.

¿Podemos empezar con un piloto pequeño?

Sí. Una fase de viabilidad de pago puede determinar si el objetivo es abordable, qué configuración necesita y qué debería incluir una campaña más amplia.

¿Entregará un harness o una configuración de pruebas reutilizable?

Los artefactos se acuerdan al definir el alcance. Según el objetivo, pueden incluir un harness, entradas semilla, instrucciones de ejecución, reproductores o indicaciones de integración. Se especifican en la propuesta.

¿Cada caída significa una vulnerabilidad?

No. Los fallos deben investigarse. El informe distingue el comportamiento observado, el impacto de seguridad confirmado y las preguntas abiertas; no promete un número de vulnerabilidades ni de CVE.

¿Con qué rapidez responde?

En un plazo máximo de tres días. Recibirá preguntas sobre su producto o un esbozo de la propuesta.

¿Cuánto cuesta?

Los precios publicados son precios de partida. El precio final depende del alcance y de la complejidad técnica, y se fija en la propuesta escrita antes de empezar.

¿Cuánto dura y cuándo puede empezar?

La duración y la fecha de inicio dependen del alcance, de la complejidad técnica y de mi carga de trabajo. La propuesta indica las fechas.

¿Podemos trabajar con un NDA?

Sí. Las condiciones de confidencialidad, incluido un NDA si lo necesita, se acuerdan en la propuesta antes de que comparta código, credenciales o hallazgos.

¿Incluye una nueva prueba?

La nueva prueba se acuerda para cada encargo en la propuesta: qué hallazgos, qué versión y en qué plazo.

¿Trabaja con agencias?

Sí. Las agencias pueden contar conmigo para el proyecto de un cliente. Las condiciones de entrega, incluidos los informes de marca blanca, se acuerdan caso por caso en la propuesta.

Fuzzing dirigido