Parche virtual para un hallazgo concreto

Hay dos maneras de escribir la regla. Una describe lo que se quiere impedir; la otra describe lo que es válido y detiene todo lo demás. La segunda es la buena, y la razón es aritmética: la lista de lo válido en un campo concreto suele tener tres o cuatro valores y se puede escribir entera, mientras que la lista de lo que alguien podría enviar no tiene final. Una lista de lo permitido también envejece mejor: si el componente añade un valor nuevo, el cambio se nota el primer día en lugar de abrir un hueco silencioso.

El precio de la lista permitida es que hay que conocer la aplicación. Por eso un parche virtual no se escribe mirando el aviso: se escribe mirando el aviso y el tráfico real de la ruta afectada. Los sesenta días de registro que tienes en la estación son la mitad del trabajo.

Y hay un tercer límite que se olvida: dónde se aplica. El mismo campo puede existir en varias rutas con listas de valores distintas, y una regla escrita para una ruta y aplicada a todas rompe las otras.

Abre el laboratorio. Lee aviso-componente.txt para saber qué ruta y qué campo están en juego, después trafico-legitimo.txt —fíjate en el apartado final, donde dice qué otras rutas reciben un campo con ese mismo nombre— y por último borradores-parche.txt.

Los tres borradores exigen lo mismo al campo. Lo que cambia entre ellos es dónde se aplica y cuánto margen dejan. Uno de los tres, probado contra el registro de sesenta días, detiene miles de peticiones legítimas de una ruta que no tiene nada que ver con el aviso.

El borrador que sirve es el que repite los tres límites del aviso: la regla concreta, el campo concreto y la ruta concreta donde el componente está expuesto. El tercer borrador parece inofensivo porque no rompe nada hoy, pero acepta valores que el componente no publica y, además, cubre un área entera en vez de una pantalla: dos formas distintas de no ser el parche que hacía falta.

Lee en el aviso dónde se usa el componente y escribe esa ruta tal como aparece.

Abre ficha-de-cambio.txt. La ficha tiene nombre del hallazgo, dueño y ticket del arreglo real, y tiene en blanco justo lo que convierte un parche en algo temporal: con qué modo arranca, cuántos días se queda mirando, para cuándo se espera poder retirarlo y qué condición hay que cumplir para hacerlo.

Sin esas cuatro líneas el parche se queda. Y un parche que se queda deja de ser un puente hacia el arreglo: pasa a ser la única defensa del portal frente a un fallo que sigue ahí, con la diferencia de que ya nadie lo recuerda.