Para fabricantes de software de escritorio, bibliotecas, SDK y herramientas para desarrolladores que trabajan con C, C++ o Java y con componentes que procesan entradas no fiables.
Al introducir un analizador, un protocolo, una biblioteca o un componente nativo importante.
Qué examinamos
- Definir los componentes objetivo, el entorno operativo, los requisitos de compilación y los límites de confianza.
- Examinar el código relevante, el procesamiento de entradas y el comportamiento de la aplicación.
- Utilizar revisión de código, pruebas dinámicas o fuzzing dirigido, según lo acordado para el objetivo.
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 aceptadosPreguntas antes de empezar
¿Qué tipo de proyectos de escritorio encajan?
Aplicaciones, bibliotecas y componentes con preguntas de seguridad claras, sobre todo en torno a entradas no fiables. Indique el lenguaje, el sistema operativo y los requisitos de compilación para confirmar que encaja.
¿El fuzzing forma parte de la evaluación?
Puede incluirse cuando es adecuado para el objetivo. Acordamos por separado el trabajo de viabilidad, la campaña y los artefactos, en lugar de suponer que todas las aplicaciones necesitan el mismo enfoque.
¿Qué trabajo público respalda este servicio?
Mi trabajo público incluye CVE-2024-26855 y CVE-2025-37858 en el kernel de Linux, con correcciones aceptadas upstream. Esos registros muestran un trabajo concreto de investigación y corrección en código nativo.
¿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.
Lecturas relacionadas
- PHP2Shell: CVE-2026-109618 y el límite del runtime
- GhostAction: borrar un secreto no es revocarlo
- LMCache CVE-2026-105192: ejecución antes del rechazo
Servicios
- Pruebas de penetración de aplicaciones
- Revisión de seguridad del código
- Fuzzing dirigido
- Corrección y verificación
- Pentest de aplicaciones web y API
- Auditoría de seguridad de aplicaciones móviles
- Revisión de seguridad para apps creadas con IA
- Desarrollo de herramientas de seguridad e ingeniería SAST/DAST
- Desarrollo de software y sitios web a medida