Resumen

  • draft-bruhns-securitytxt-product-security-00, publicado el 10 de septiembre de 2026, plantea los campos opcionales Product-Security y Product-Security-Policy para el formato de RFC 9116.
  • El primero apunta a contactos para vulnerabilidades de productos; el segundo, a una política HTTPS que debería explicar alcance, triaje, plazos y divulgación.
  • Es un Internet-Draft individual, no un documento adoptado por un grupo del IETF ni una norma aprobada. La IANA todavía no registra ninguno de los dos campos.
  • Distinguir el buzón de producto del de infraestructura mejora el reparto inicial, pero no vincula un modelo, versión o compilación con la organización que acepta hacerse cargo.

Entregado no significa asignado

Un investigador identifica una vulnerabilidad en la versión 4.7 de un equipo. El sitio de la marca publica un contacto específico para seguridad de producto. El mensaje entra, genera un número automático y pasa al equipo de soporte. Días después, ese equipo responde que la rama la mantiene un socio. El socio sostiene que su contrato terminó con la versión 4.5.

Todos los registros de transporte pueden estar verdes. El fallo está en la asignación de responsabilidad, no en la entrega. Una URI decide el primer salto; no demuestra quién controla el código, quién puede producir una corrección ni quién asumió el caso dentro de su perímetro.

El problema aumenta con productos de marca blanca, adquisiciones y componentes reutilizados. La misma denominación comercial puede ocultar distintas compilaciones. El mismo binario puede llegar por canales de distribución diferentes. El dominio que aloja security.txt aporta una procedencia de publicación, no un catálogo histórico de obligaciones.

La propuesta tiene dos piezas

El Datatracker presenta Product Security Fields for security.txt como un Internet-Draft individual. El historial registra únicamente la revisión 00, fechada el 10 de septiembre de 2026. Publicar un borrador permite que otros lo examinen; no acredita respaldo del IETF, adopción por un grupo de trabajo ni condición de RFC.

El texto de la revisión permite repetir Product-Security. Cada aparición contiene una URI de contacto para informar vulnerabilidades de productos y sigue las restricciones de URI de Contact. El orden expresa la preferencia del editor del archivo.

Product-Security-Policy aparece como máximo una vez y debe apuntar mediante HTTPS a la política del programa. El borrador espera que esa página describa qué productos abarca, cómo acusa recibo y clasifica informes, qué tiempos maneja, cómo trata divulgación y embargos, si admite anonimato y qué garantías ofrece a la investigación de buena fe.

La política puede resolver dudas concretas si está bien escrita y actualizada. El campo no certifica que lo esté. Tampoco contiene por sí mismo un modelo, una versión, un paquete o la identidad del mantenedor responsable.

El registro conserva el estado anterior

La sección dirigida a la IANA solicita dos nuevas entradas con política de Expert Review. En el registro público de campos de security.txt todavía no aparecen Product-Security ni Product-Security-Policy. Permanecen los campos básicos —entre ellos Contact, Expires, Canonical, Encryption, Policy y Preferred-Languages— y extensiones registradas como CSAF, Bug-Bounty y Hiring.

Solicitar no equivale a registrar. RFC 8126 explica que Expert Review encarga a expertos designados la evaluación de una petición conforme a los criterios aplicables. Un operador puede experimentar con una extensión, pero no debe presentarla como si ya fuera una clave interoperable asignada.

Esa experimentación no tiene por qué romper lectores anteriores. RFC 9116 dispone que los campos desconocidos se ignoren. Por eso el nuevo borrador recomienda que Contact siga aceptando avisos de producto: un analizador antiguo conserva una salida, aunque no sepa clasificarla.

El alcance empieza en el origen, no termina allí

RFC 9116 relaciona el archivo con el dominio o la dirección IP donde se recupera. No extiende automáticamente esa relación a dominios padre o subdominios. También admite que una organización publique información sobre sus productos y servicios, pero no especifica cómo enumerar sus versiones ni cómo transferir la titularidad cuando cambia el mantenedor.

La política enlazada debe tender ese puente. El lado del investigador aporta un identificador de producto, versión, firmware, paquete o commit. El lado del editor aporta un origen web, un conjunto de contactos y una descripción de alcance. Falta conservar la regla que hizo coincidir ambas partes.

Sin esa regla, una auditoría posterior verá que la marca publicó el archivo y que el mensaje llegó. No podrá saber si el receptor aceptó la versión afectada, si la redirigió a un tercero o si aplicó una política distinta de la que hoy muestra la web. La disponibilidad presente de la página puede borrar la decisión histórica.

Canonical, caducidad y firma no sustituyen la competencia

El formato vigente exige Expires, ofrece Canonical y recomienda una firma. Son controles importantes porque un archivo obsoleto puede desviar un informe y porque quien comprometa el servidor podría sustituir los contactos por otros controlados por el atacante.

Pero cada control responde a una pregunta acotada. La caducidad señala que la información ya no debe considerarse vigente. La URL canónica identifica la copia pretendida. La firma relaciona el contenido con una clave. Ninguno demuestra que el firmante mantenga el componente concreto ni que el buzón haya aceptado su versión.

El propio RFC separa además el hallazgo del archivo de la autorización para probar. Ni la existencia ni la ausencia de security.txt concede o prohíbe esa actividad. Una página de política puede formular condiciones; hay que leerlas, versionarlas y aplicar su alcance, no proyectarlas desde el nombre del campo.

Un recibo para la decisión de custodia

El comprobante debería conservar primero la descripción exacta del artefacto recibida del investigador: familia, modelo, componente, identificador de paquete, versión, build, rama y canal de distribución cuando existan. Junto a ello, debe registrar el origen y la URL canónica del archivo, la hora de consulta, Expires, el resultado de firma y la entrada Product-Security elegida con su posición en el orden de preferencia.

Después necesita la URL de Product-Security-Policy y un hash o versión de su contenido. El receptor anota qué cláusula justificó aceptar, rechazar o desviar el caso, quién tomó custodia y qué identificador de expediente o transferencia emitió. No hace falta exponer el detalle sensible para demostrar que hubo una decisión.

Este recibo es una propuesta editorial de Daniel Kade. No figura como requisito en la revisión 00, RFC 9116 ni el registro de la IANA. Su misión no es volver a probar que el canal funciona, sino impedir que una entrega satisfactoria sea confundida con una asignación de responsabilidad.

Fuentes