Actualización de producto KENSAI: la publicación proof-first y la disciplina de envío endurecen la superficie same-day

KENSAI endureció las operaciones del 16 de abril al exigir orientación sobre probabilidad de aceptación, prueba en video obligatoria para envíos y archivos JSON separados por idioma para mantener alineada la publicación del mismo día en todos los idiomas requeridos.

Lo que se publicó hoy

El trabajo de hoy endureció dos sistemas a la vez: cómo KENSAI decide que un hallazgo de bug bounty está listo para enviar y cómo el blog público demuestra que un día está realmente publicado. El resultado es menos teatro. Un hallazgo no está de verdad listo sin una probabilidad clara de aceptación y sin prueba en video, y una publicación diaria no está de verdad publicada si el HTML local, el JSON local y las páginas overview no coinciden.

Suena estricto, pero es el estándar correcto. Una guía débil quema ciclos de envío, y la publicación parcial crea una deriva silenciosa que solo aparece cuando usuarios o rastreadores llegan a superficies obsoletas.

1) La guía de envío ahora empieza con la probabilidad de aceptación y con un no enviar cuando toca

La orientación de envío ahora tiene que decir primero la parte incómoda. Si la probabilidad de aceptación es baja, si la historia de alcance es débil o si el resultado probable es informativo o fuera de alcance, la recomendación debe decir claramente que no se envíe. Eso es mejor que pulir un informe que probablemente nunca debería salir de la cola.

Así la cola se vuelve más honesta. La evidencia y la probabilidad de aceptación pesan más que el optimismo, justo como debería funcionar un flujo de seguridad cuando el tiempo y la credibilidad son limitados.

2) La prueba en video ya forma parte de la definición de listo

El segundo endurecimiento está en la prueba. Un informe de texto ya no basta para llamar submission-ready a un hallazgo. Si importa la ruta de explotación, el paquete necesita un video que muestre el comportamiento con claridad y aguante el escepticismo del revisor.

Eso empuja al equipo hacia evidencia reproducible en lugar de inflación narrativa. También crea una frontera más limpia entre una señal interesante y un informe realmente listo para enviar.

3) La publicación same-day solo es honesta cuando el HTML local, el JSON local y las páginas overview avanzan juntos

En publicación aplica la misma regla: la prueba pública vale más que la intención interna. Cada idioma debe vivir solo en su propio índice JSON, inglés no puede absorber entradas no inglesas y las páginas overview deben regenerarse después de publicar los archivos locales.

Eso mantiene honesta la superficie same-day. Un día solo cuenta como publicado cuando existe el HTML renderizado, los archivos JSON correctos por idioma apuntan a esas entradas y cada overview lingüístico muestra exactamente el mismo set del 16 de abril que inglés.

Por qué importa

Ese es el comportamiento de producto que vale la pena proteger. Los sistemas ganan confianza cuando las afirmaciones fuertes son más difíciles de fingir. La preparación para enviar debe significar evidencia, y la publicación debe significar paridad visible en la superficie pública.

Es un mejor bucle operativo que esperar a que el estado interno algún día coincida con lo que realmente ve el usuario.