Justificaciones de no afectado

Las cinco etiquetas que comparten CISA, OpenVEX y CSAF son component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary e inline_mitigations_already_exist. Van de lo más comprobable a lo más dependiente de un argumento.

• Las dos primeras se comprueban con la lista de componentes o con la configuración de compilación: o el componente está, o el código no se compila.
• La tercera y la cuarta dependen de un análisis: de alcanzabilidad o del origen de los datos.
• La quinta depende de que la medida exista y funcione.

La tabla justificaciones dice cuándo aplica cada una y qué debería poder mostrar quien la usa.

Leer una declaración de no afectado es contrastar dos columnas: la etiqueta que el proveedor eligió y la evidencia que adjunta. Si la evidencia dice lo contrario de lo que la etiqueta afirma, la declaración no se puede aceptar tal cual, por muy bien formada que esté.

En la tabla declaraciones_no_afectado, una etiqueta afirma algo que la propia evidencia desmiente.

inline_mitigations_already_exist es la razón más cómoda de escribir: basta decir que ya hay una medida. Por eso es la que más necesita una descripción de la medida y una prueba de que funciona. Una etiqueta sin evidencia es una opinión; con la política de Valdemora, que exige evidencia adjunta, no retira nada.

Una de las seis declaraciones no trae evidencia alguna.

En OpenVEX, una declaración not_affected debe traer al menos una justificación estructurada o una declaración de impacto en texto libre (impact_statement), y puede traer las dos. La justificación estructurada permite que una herramienta filtre; el texto libre permite explicar lo que las cinco etiquetas no alcanzan a decir. Una declaración not_affected sin ninguna de las dos no cumple el formato.