Кратко

  • RFC 9943 позволяет установить ограниченный факт: служба прозрачности зарегистрировала подписанное заявление по определённой политике и выдала квитанцию с проверяемыми доказательствами в структуре данных. Это доказательство регистрации, а не разрешение на выпуск описанного артефакта.
  • Выбор доверенных издателей, приемлемых квитанций, локальных правил и уполномоченного лица, которое разрешит, отложит или отменит релиз, остаётся обязанностью организации, способной устранить последствия.

Прозрачная запись не становится разрешением

Фраза «у компонента есть квитанция прозрачности» звучит как итог проверки. RFC 9943 предлагает более узкий и потому честный смысл. Опубликованный IETF в июне 2026 года как Standards Track RFC документ описывает архитектуру, которая делает прозрачными подписанные заявления о цифровых артефактах цепочки поставок. Он не учреждает орган, выдающий разрешения на production-релизы.

Издатель может подписать заявление о пакете, образе или прошивке: SBOM, подтверждение, уведомление об окончании жизненного цикла, сообщение о безопасности либо иное сериализуемое содержание. Transparency Service, или TS, может это заявление зарегистрировать. Регистрация означает подачу Signed Statement, применение Registration Policy данного TS, добавление в Verifiable Data Structure и выпуск Receipt. По квитанции проверяющий может, например, подтвердить включение заявления в указанную структуру.

Это существенная возможность. Проверяемая дописываемая история затрудняет незаметное удаление или переписывание утверждения. Она даёт аудитору материал для проверки последовательности и заявлений одного издателя. Но доказательство включения не является полной оценкой безопасности, тестом совместимости, договорным акцептом, решением о риске или распоряжением об откате. Журнал делает утверждение наблюдаемым; он не несёт потери от решения воспользоваться этим утверждением.

Четыре разных факта не должны обмениваться полномочиями

Первый факт: издатель подписал заявление. Корректная подпись связывает ключ, содержание и предусмотренные метаданные. Она не доказывает автоматически, что издатель — именно та сторона, которой рассчитывала доверять организация, что у него был мандат на такое утверждение или что содержание истинно.

Второй факт: конкретный TS зарегистрировал заявление. Registration Policy в RFC 9943 — предварительное условие, основанное на доступных для проверки полях заголовка и метаданных COSE-конверта. Политика может быть строгой, узкой или отраслевой. Поэтому результат регистрации говорит только о проверках, выполненных этой службой по этой политике в тот момент. Он не сообщает, что завершены все проверки безопасности, права, закупок и эксплуатации, нужные каждому последующему пользователю.

Третий факт: relying party проверила квитанцию, приемлемую для неё. RFC требует, чтобы она доверяла ключу проверки или сертификату и связанной идентичности хотя бы одного издателя квитанции. Она может посчитать достаточной одну квитанцию и затем применять произвольные локальные правила валидации. В квитанцию не встроено всемирное правило допуска. Пользователь сам выбирает службу, ключ, издателя, профиль доказательства и условия свежести для своего случая.

Четвёртый факт: уполномоченная сторона приняла операционное решение. Руководитель выпуска может разрешить версию; служба безопасности — удержать; закупка — принять только в пределах договора; эксплуатация — оставить текущую версию и отклонить следующую. У этих действий разные полномочия, последствия и способы исправления. Технически корректная квитанция не совершает их вместо людей.

Такое разделение необходимо на практике. Заявление может быть зарегистрировано, а организация не будет доверять издателю. Квитанция может успешно провериться, но локальное правило остановит развертывание из-за новой уязвимой поверхности, лицензии, несовместимости либо заканчивающегося исключения. Срочная ситуация может потребовать узкого временного исключения. Это не повод отказаться от следа; напротив, нужно отдельно записать, кто разрешил исключение, до какого срока и как оно будет пересмотрено.

У политики и журнала есть свои часы

RFC 9943 допускает, что оператор TS меняет Registration Policy или якоря доверия. Одновременно TS обязан предоставить достаточно материала, чтобы аудитор мог воспроизвести проверки, которые требовала политика во время регистрации. Поэтому зрелый вопрос звучит не только так: «верна ли подпись квитанции?» Нужно спросить: какая служба, какая версия политики, какой ключ, какое заявление и какое время дали этот результат?

Это не запрещает развитие политики. Ключи нужно менять, критерии могут ужесточаться, профили — обновляться. Граница в другом: сегодняшняя политика не должна молча переписывать значение вчерашней регистрации, а старая квитанция не должна выдаваться за нынешнюю политику релиза организации.

Позиция в журнале тоже не заменяет полную хронологию. VDS может фиксировать порядок зарегистрированных заявлений, но RFC 9943 говорит, что relying party не вправе считать этот порядок порядком выпуска заявлений, если Registration Policy прямо не объявляет такое свойство. Номер в журнале не доказывает, что исправление предшествовало сообщению, что руководитель увидел доказательство до решения или что решение и регистрация произошли в одно время. Для таких связей нужны собственные отметки времени и ответственные хранители.

Прозрачность не становится автоматическим арбитром истины. Издатель может намеренно или по ошибке сделать ложное заявление; его может сменить новое; разные издатели могут дать противоречивые заявления об одном артефакте. Архитектура позволяет видеть историю и выбирать, кому доверять. Она не назначает универсального судью содержания.

Часто отсутствует именно запись о решении

Во многих организациях уже хранятся хэш артефакта, подписанное свидетельство, квитанция и название политики. Решающий момент — почему эту версию пропустили — остаётся в чате, за кнопкой панели или в аварийном согласовании без понятного владельца. После инцидента можно показать, что нечто попало в журнал, но нельзя объяснить, кто и на каком основании позволил программному обеспечению пройти контроль.

Для этого нужен отдельный от SCITT документ решения о релизе. Для каждого существенного допуска, удержания, отказа или исключения он должен связывать неизменяемую версию артефакта; заявление и издателя; TS; версию и время политики регистрации; результат проверки квитанции и момент повторной проверки; применённое локальное правило или исключение; уполномоченного решающего; результат; срок или триггер пересмотра; путь исправления, отката или обжалования.

Это не новое требование RFC 9943. Именно поэтому такой документ не притворяется, будто стандарт IETF является корпоративным комитетом по выпускам. Подробности тестов, данные клиентов и пригодная для атаки информация могут оставаться закрытыми. Но уполномоченный проверяющий должен суметь восстановить, какое доказательство повлияло на какое решение и как это решение можно исправить.

Автоматизация не устраняет эту границу. Pipeline может проверить квитанцию и выполнить выбранное заранее правило. В записи всё равно следует указать версию правила, орган, который его утвердил, входные данные и результат. Формула «журнал разрешил» скрывает главное: ранее человек или институт решили, что именно это правило будет выполняться автоматически.

Стандарт доказательств не правит чужим риском

RFC 9943 оставляет за пределами своей области управление и хранение заявлений, а также обнаружение участников и уведомление их об изменениях. Эта сдержанность полезна. Производитель, больница, государственный заказчик и добровольный сопровождающий могут проверить одну квитанцию, не притворяясь, что у них один и тот же мандат на риск.

Проблема возникает, когда техническое свойство используют для легитимации институционального выбора. Закупки объявляют проверку законченной, потому что заявление зарегистрировано. Команда доставки приравнивает включение к одобрению владельца риска. Эксплуатация считает подпись издателя достаточной после появления новой информации. Во всех случаях ограниченный истинный факт несёт решение, которое никто не зафиксировал.

Более надёжный порядок прост: проверять доказательство только на то свойство, которое оно показывает; сохранять политику и время, придающие ему смысл; записывать, кто решил воспользоваться им. Тогда криптографическую ошибку и ошибку управления можно расследовать как разные ошибки.

Источники

  1. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains
  2. IETF Datatracker: RFC 9943
  3. RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts
  4. RFC 9162: Certificate Transparency Version 2.0
  5. RFC 9052: CBOR Object Signing and Encryption (COSE): Structures and Process