El ciclo de desarrollo del servicio

Un arnés de fuzzing produce un informe cada vez que encuentra una entrada que hace caer el programa, y la misma causa suele caer muchas veces con entradas distintas. Para no contar de más se agrupa por la firma de la caída: la función y la línea donde cae. Dos informes con la misma firma son un solo fallo; dos con firmas distintas son dos fallos, aunque se parezcan las entradas.

Un agente que observa la aplicación mientras corren las pruebas solo puede hablar de lo que las pruebas ejercitaron. Una operación sin hallazgos y con cientos de solicitudes de prueba tiene un silencio que significa algo; una operación sin hallazgos y sin una sola solicitud no demuestra nada: nadie la tocó. Al leer el informe se miran juntas las dos columnas.

El tiempo de cadena se presupuesta: una corrida corta por cada solicitud de cambio, que no frene al equipo, y una corrida larga programada, que acumula cobertura. Para saber cuánto cuesta una semana hay que leer el calendario tal como está escrito (qué días corre) y sumar cada tipo de corrida por su duración. Un calendario de cinco campos se lee de izquierda a derecha: minuto, hora, día del mes, mes y día de la semana, donde 1 es lunes.

Cuando aparece una firma de caída que las corridas anteriores no veían, es una regresión y el culpable está entre los cambios fusionados desde la última corrida limpia de esa firma. De todos esos cambios, el sospechoso es el que toca el archivo donde cae el programa; los demás pueden ser ruido, o incluso tocar archivos de otros fallos conocidos.

Un asistente de código puede proponer una dependencia con un nombre verosímil que no existe. Si el nombre está libre en el registro, cualquiera puede publicar un paquete con ese nombre y la próxima instalación lo traerá. Se revisa cada paquete nuevo de la solicitud contra el registro: que exista, quién lo publica y si la plataforma lo tiene aprobado. Aquí interesa el que ni siquiera existe.