Непрерывная цепочка доверия при автоматическом релизе исполняемых модулей анализатора в замкнутом цикле
Авторский коллектив
- Прозоров А.А., Директор по технологиям РТЛАБ, архитектор Сбертех, ap@rtlab.ru;
Аннотация
Цель: В статье определяется контур непрерывной цепочки доверия для исполняемых модулей анализатора после управляемого релиза. Он закрывает разрыв доказательств между подписанными доказательствами релиза, допуском к развертыванию, проверкой запуска во время выполнения и последующим диагностическим рецензированием.
Метод: Статья является методологической системной статьей с ограниченными доказательствами проектирования цепочки доверия. Она разделяет управляемый релиз, аттестации происхождения, доказательства подписи и прозрачности, доверие к зависимостям, допуск к развертыванию, проверку во время выполнения и диагностические сигналы доверия. Внешние источники обосновывают жизненный цикл программного обеспечения и трассируемость в системе качества, рамки управления рисками, аналогии доказуемого происхождения и аудита, канонические дайджесты, доказательства, ограниченные схемой, словарь SBOM и обмена сведениями об уязвимостях, идентификатор контейнерного образа, безопасную разработку программного обеспечения, SLSA, in-toto, DSSE и подписывание в стиле Sigstore с журналами прозрачности [1-19].
Результаты: Статья задает рецензируемую цепочку доверия, которая объединяет квитанции релиза, аттестации происхождения, подписи артефактов, доказательства журнала прозрачности, материалы SBOM и VEX, записи допуска к развертыванию, проверку запуска во время выполнения, проекции доказательств выполнения и диагностические сигналы доверия без превращения доказательств цепочки доверия в авторизованную семантику.
Вывод: Доказательства непрерывной цепочки доверия делают модули анализатора, привязанные к релизу, рецензируемыми в контурах релиза, развертывания, выполнения и диагностики, сохраняя разделение ответственности за семантику, релиз, развертывание, выполнение и проверку доверия.
Ключевые слова: непрерывная цепочка доверия; исполняемые модули анализатора; SLSA; in-toto; DSSE; аттестация; журнал прозрачности; допуск к развертыванию; проверка запуска во время выполнения; непрерывная проверка
Сокращения и терминологические соглашения
Цепочка доверия: Рецензируемая цепочка доказательств, которая связывает доверенные выходы релиза с аттестованными доказательствами сборки, подписания, журнала прозрачности, развертывания, выполнения и диагностики.
Непрерывная цепочка доверия: Цепочка доверия, которая повторно проверяется во времени и на этапах жизненного цикла, а не рассматривается как однократная подпись релиза. Она охватывает актуальность доказательств, отзыв, ротацию ключей, состояние зависимостей, допуск к развертыванию, проверку запуска во время выполнения и диагностические сигналы доверия.
Субъект доверия: Артефакт, идентификатор, конфигурация, вход развертывания или наблюдение выполнения, относительно которого формулируется утверждение доверия.
Утверждение доверия: Ограниченное утверждение о субъекте доверия, например идентификатор исходного кода, идентификатор сборщика, дайджест артефакта, дайджест SBOM, статус VEX, результат проверки подписи, включение в журнал прозрачности или статус допуска к развертыванию.
Аттестация: Подписанное или иначе проверяемое доказательное заявление об одном или нескольких субъектах доверия. Материал аттестации может описывать доказуемое происхождение, входы сборки, доказательства зависимостей, результаты применения политики подписания или результаты проверки.
Конверт DSSE: Dead Simple Signing Envelope, используемый здесь как общий паттерн конверта аттестации для связывания полезной нагрузки и материала подписи.
Заявление in-toto: Паттерн заявления аттестации, который идентифицирует субъекты и предикаты для доказательств цепочки поставки.
Уровень SLSA: Словарь обеспечения доверия в цепочке поставки, используемый для обсуждения доказуемого происхождения сборки и ожиданий проверки. Заявления о соответствии требуют явных доказательств и не следуют из самого использования словаря.
Журнал прозрачности: Поверхность журнала с дозаписью, используемая для того, чтобы подписанные записи артефактов или аттестаций были обнаруживаемыми и рецензируемыми. Включение в журнал поддерживает проверку, но само наличие записи в журнале не доказывает достаточность артефакта.
VEX: Материал Vulnerability Exploitability eXchange, который фиксирует, являются ли известные уязвимости эксплуатируемыми в контексте продукта или артефакта. VEX дополняет материал SBOM, но не заменяет доказуемое происхождение зависимостей.
Непрерывная проверка: Повторная проверка подписей, аттестаций, включения в журнал, состояния зависимостей, допуска к развертыванию и доказательств запуска во время выполнения после релиза.
Глобальный инвариант: Контур цепочки доверия не является авторизованной семантикой. Он проверяет и переносит доказательства об опубликованных модулях анализатора; он не авторизует семантику графа, не выполняет прямое изменение графа или хранилища триплетов, не валидирует клиническую эффективность, не применяет автономное устранение недостатков и не заменяет человеческое управление.
Введение
Управляемый релиз делает модули анализатора рецензируемыми в точке публикации, но доказательств на момент релиза недостаточно для долгоживущего исполняемого знания. Подписанная квитанция релиза может устареть, когда сертификат отозван, зависимость становится новой уязвимой, развертывание выбирает неожиданный образ, сервис запускается с другим скомпилированным пакетом или доказательства выполнения не могут объединиться с принятой основой релиза. Операционная проблема поэтому состоит в непрерывности: рецензентам нужно знать не только, что было выпущено, но и остается ли релиз связанным с доказательствами исходного кода, сборщика, зависимостей, развертывания, выполнения и диагностики.
В статье описывается контур непрерывной цепочки доверия, который начинается с выходов управляемого релиза и проходит через аттестацию, подписание, включение в журнал прозрачности, рецензирование зависимостей, допуск к развертыванию, проверку запуска во время выполнения, проекцию доказательств выполнения и диагностическую классификацию доверия. Контур не открывает заново шлюз релиза и не исправляет авторизованную семантику. Он делает разрывы цепочки доверия видимыми как диагностические сигналы, подкрепленные доказательствами.
Вклад статьи — паттерн непрерывного рецензирования доверия к исполняемым модулям анализатора, ориентированный на артефакты. Он рассматривает SLSA, in-toto, DSSE, подписывание в стиле Sigstore, журналы прозрачности, SBOM и VEX как словарь и поверхности доказательств, поддерживающие рецензируемое обеспечение доверия.
Сопутствующие статьи
Автоматический релиз доверенных исполняемых модулей анализатора из доверенного снимка знаний в замкнутом цикле отвечает за управляемые шлюзы релиза, квитанции релиза, подписанные доказательства релиза, захват манифеста релиза, совместимость волны релиза и передачу управления развертыванию. Эта статья потребляет такие выходы релиза и расширяет их до непрерывной проверки доверия.
Реализация потокового анализатора для смеси именованных признаков и осциллограмм отвечает за архитектуру потокового анализатора с сессиями и окнами. Анализатор на основе правил без сохранения состояния для смеси именованных признаков и осциллограмм отвечает за архитектуру сервиса анализатора в пределах запроса. Эта статья проверяет цепочку доверия вокруг опубликованных модулей для этих контуров выполнения; она не переопределяет поведение выполнения анализатора.
Сквозная трассировка кодифицированных терминов для отладки и аудита компилятора и исполняемых модулей отвечает за объединения реестра/трассы и объединения доказательств выполнения. Эта статья переносит доказательства цепочки доверия, которые помогают рецензентам решить, связано ли нарушение объединения доказательств с релизом, развертыванием, зависимостью или дрейфом доверия во время выполнения.
Контур авторизации и диагностики как универсальная инфраструктура разработки и управления исполняемым знанием отвечает за диагностическую классификацию, пакеты с устранением недостатков, управляемые запросы обновления графа, авторизованное доказательство записи, перестроенные снимки, доказательства закрытия и человеческие решения о закрытии. Эта статья может порождать диагностические сигналы доверия для такого контура, но не закрывает устранение недостатков.
Мгновенная оценка состояния здоровья на примере интерпретации смеси именованных терминов и осциллограмм ЭКГ отвечает за предметную интерпретацию и утверждения графа знаний ЭКГ. Доказательства цепочки доверия в этой статье являются инфраструктурными доказательствами, а не кардиологической валидацией.
Материалы и методы
Статья является методологической системной статьей с ограниченными доказательствами проектирования цепочки доверия. Внутренняя авторская основа включает спецификации конвейера релиза и доказательств релиза, материалы квитанции релиза и захвата манифеста релиза, рукописи о выполнении анализаторов, спецификации диагностического контура, спецификации доказательств выполнения и общий канон терминологии. Эти внутренние материалы направляют рукопись, но не цитируются как публичные источники.
Набор внешних источников намеренно компактен. IEC 62304, ISO 13485, ISO/IEC/IEEE 12207 и IEEE 828 обосновывают жизненный цикл программного обеспечения, трассируемость в системе качества, управление конфигурацией и словарь инженерии релизов [1,3,11,12]. ISO 14971 задает рамку управления рисками, не превращая доказательства цепочки доверия в доказательство клинической безопасности [2]. PROV-O и FHIR AuditEvent дают аналогии доказуемого происхождения и событий аудита для записей доказательств [4,5]. RFC 8785 и JSON Schema 2020-12 обосновывают канонические дайджесты и доказательства, ограниченные схемой [6,7]. CycloneDX, OpenVEX и OCI Image Specification обосновывают словарь SBOM, эксплуатационной применимости уязвимостей и идентификатора образа [8,10,19].
SLSA предоставляет словарь обеспечения доверия в цепочке поставки; in-toto и DSSE предоставляют словарь структуры аттестаций; Sigstore/cosign, Rekor и Fulcio предоставляют словарь подписывания, журналов прозрачности и идентификатора сертификата [9,14-18]. Рукопись использует эти источники для описания рецензируемых доказательств доверия; границы соответствия и сертификации сформулированы в отдельном разделе о SLSA и в ограничениях.
Обзор непрерывной цепочки доверия
Контур непрерывной цепочки доверия начинается с выходов управляемого релиза и переводит их в проверку после релиза. Его жизненный цикл: квитанция релиза → аттестации происхождения → подписи артефактов → включение в журнал прозрачности → рецензирование доверия к зависимостям → допуск к развертыванию → проверка запуска во время выполнения → объединение доказательств выполнения → диагностический сигнал доверия.
Рисунок 1. Контур непрерывной цепочки доверия. Жизненный цикл цепочки доверия начинается с выходов релиза и добавляет аттестации происхождения, подписи, включение в журнал прозрачности, рецензирование доверия к зависимостям, допуск к развертыванию, проверку запуска во время выполнения, проекцию доказательств выполнения и диагностические сигналы доверия. Непрерывная проверка возвращается к проверкам отзыва, ротации ключей и устаревания доказательств до того, как доказательства развертывания и выполнения принимаются для рецензирования.
Рисунок 1 отделяет принятие релиза от непрерывности доверия. Квитанция релиза может быть корректной на момент продвижения, но последующая проверка все равно может обнаружить устаревшие доказательства, отозванный сертификат, отсутствующее включение в журнал, разрывы доверия к зависимостям или несоответствие запуска во время выполнения. Такие находки являются диагностическими сигналами, а не изменениями семантики.
Таблица 1. Субъекты доверия, доказательства и границы полномочий.
| Субъект доверия | Поверхность доказательств | Вопрос проверки | Граница полномочий |
|---|---|---|---|
| Ревизия исходного кода или идентификатор исходного кода | Доказуемое происхождение сборки и квитанция релиза | Какой исходный материал использовался для сборки модуля анализатора? | Идентификатор исходного кода не является авторизованной семантикой. |
| Сборщик или идентификатор сервиса сборки | Аттестация происхождения, доказательства, согласованные со SLSA, идентификатор сертификата | Какой сборщик произвел артефакт и в рамках какого объявленного процесса? | Идентификатор сборщика не является клиническим или семантическим утверждением. |
| Скомпилированный пакет | Квитанция релиза, дайджест скомпилированного пакета, аттестация происхождения | Соответствует ли артефакт выполнения принятому пакету исполняемого знания? | Доверие к пакету не исправляет объединения реестра/трассы. |
| Образ анализатора | Идентификатор образа OCI, дайджест образа, доказательства подписи | Соответствует ли развернутый образ опубликованному образу? | Проверка образа не является доказательством корректности анализатора. |
| Материалы SBOM и VEX | Дайджест SBOM, записи VEX, состояние по уязвимостям | Инвентаризированы ли зависимости и классифицированы ли известные уязвимости для области релиза? | Доказательства зависимостей сами по себе не являются полным доверием к транзитивным зависимостям. |
| Квитанция релиза | Дайджест квитанции, результат проверки подписи, захват манифеста релиза | Соответствует ли квитанция доказательствам релиза, образа, пакета, конфигурации и политики? | Проверка квитанции не открывает продвижение релиза заново. |
| Запись журнала прозрачности | Запись в стиле Rekor, доказательство включения в журнал, подписанная временная метка | Видимы ли подписанные доказательства в ожидаемой поверхности прозрачности? | Включение в журнал само по себе не доказывает достаточность артефакта. |
| Допуск к развертыванию | Политика проверки и результат допуска | Приняло ли развертывание только опубликованный образ, пакет, конфигурацию и доказательства доверия? | Допуск не выполняет анализатор и не валидирует его клинически. |
| Проверка запуска во время выполнения | Доказательства материализации при запуске и проекция доказательств выполнения | Запустился ли сервис с ожидаемыми артефактами, привязанными к релизу? | Проверка выполнения не авторизует изменения семантики. |
| Диагностическая проекция | Диагностический сигнал цепочки доверия | Является ли аномалия разрывом цепочки доверия, несоответствием релиза/развертывания или другим классом дефекта? | Диагностическая проекция сама по себе не закрывает устранение недостатков. |
Модель аттестации
Аттестация полезна только тогда, когда ее субъект, предикат, издатель и политика проверки явны. Субъект идентифицирует описываемый артефакт или объект доказательств, например дайджест скомпилированного пакета, дайджест образа, дайджест SBOM, дайджест квитанции релиза или запись допуска к развертыванию. Предикат описывает утверждение, например ревизию исходного кода, идентификатор сборщика, материалы сборки, побочные артефакты сборки, инвентаризацию зависимостей, результат проверки подписи или проверку запуска во время выполнения. Издатель идентифицирует систему или роль, которая создала аттестацию. Политика проверки определяет, что должно быть проверено до того, как аттестация может считаться доверенной для заданного этапа жизненного цикла.
Эта модель следует принципам доказуемого происхождения и событий аудита: доказательство должно фиксировать, что произошло, с каким субъектом, под каким идентификатором и с каким контекстом [4,5]. Затем цепочка доверия связывает это доказательство с каноническими дайджестами и записями, ограниченными схемой, чтобы рецензенты могли воспроизвести объединения [6,7].
Модель намеренно избегает широкого языка доказательства. Аттестация происхождения сборки может показать, что артефакт был создан объявленным сборщиком из объявленных материалов. Она не доказывает клиническую достаточность, семантическую корректность, отсутствие всех уязвимостей или соответствие уровню зрелости цепочки поставки.
Граница SLSA и in-toto
SLSA предоставляет словарь для угроз цепочки поставки, доказуемого происхождения сборки и уровней обеспечения доверия [14]. В этой статье SLSA используется для описания доказательств, которые рецензенту нужно проверить: идентификатор исходного кода, идентификатор сервиса сборки, доказуемое происхождение сборки, идентификатор артефакта и политику проверки. Статья не утверждает, что проект достигает уровня SLSA или соответствует SLSA.
in-toto предоставляет паттерн для заявлений цепочки поставки и рассуждений о производстве артефактов через структуру in-toto layout [15]. DSSE предоставляет паттерн конверта для подписывания аттестаций [16]. Вместе они дают контуру цепочки доверия дисциплинированный способ описывать субъекты и предикаты аттестации, но сами по себе не делают цепочку полной. Полнота зависит от фактического покрытия доказательствами исходного кода, сборки, зависимостей, релиза, развертывания, выполнения и диагностики.
Ключевая граница — рецензируемость, а не автоматическое доверие. Релиз может включать заявление происхождения в стиле in-toto, конверт DSSE и подписанную квитанцию, но все равно не пройти непрерывную проверку из-за истекшего сертификата, отсутствующего доказательства включения в журнал, изменившегося состояния зависимостей или несоответствия доказательств запуска во время выполнения передаче управления развертыванию.
Журнал прозрачности и проверка подписи
Проверка подписи отвечает на вопрос, был ли артефакт или аттестация подписан согласно объявленной политике. Проверка журнала прозрачности отвечает на вопрос, видимы ли эти подписанные доказательства в ожидаемой поверхности журнала. Sigstore/cosign предоставляет словарь подписывания и проверки; Rekor предоставляет паттерн журнала прозрачности; Fulcio предоставляет словарь идентификатора сертификата для сценариев подписывания без управления ключами [9,17,18].
Контур цепочки доверия фиксирует результаты проверки подписи, идентификатор сертификата, подписанную временную метку, идентификатор записи журнала и доказательство включения в журнал, когда эти поверхности являются частью объявленной политики. Эти записи поддерживают рецензируемую непрерывность: рецензенты могут спросить, остаются ли та же квитанция релиза, дайджест образа, дайджест SBOM и пакет аттестаций проверяемыми после релиза.
Прозрачность не равна достаточности. Вредоносный, устаревший или клинически нерелевантный артефакт тоже может быть подписан и записан в журнал. Поэтому контур рассматривает подпись и доказательства журнала как необходимые входы рецензирования для классификации цепочки доверия, а не как достаточное доказательство корректного поведения анализатора.
Рисунок 2. Поток доказательств аттестации и прозрачности. Субъект доверия оборачивается доказательствами подписи или DSSE, проверяется относительно идентификатора сертификата и временной метки, проверяется на включение в журнал прозрачности и сводится к результату политики проверки. Результатом становится пакет доказательств доверия, который можно объединить с доказательствами релиза, развертывания и выполнения.
Рисунок 2 показывает, почему проверка подписи и проверка включения в журнал прозрачности являются отдельными шагами. Доказательства подписи могут присутствовать при отсутствующем включении в журнал, или включение в журнал может присутствовать, но политика проверки отклонит идентификатор сертификата или временную метку.
Политика проверки и результаты
Непрерывное рецензирование доверия становится операционным только тогда, когда доказательства сводятся к явным результатам. Пакет доказательств доверия переносит дайджест квитанции релиза, дайджест образа, дайджест SBOM, субъекты и предикаты аттестации, результаты проверки подписи, идентификатор сертификата, подписанную временную метку, доказательство включения в журнал, состояние зависимостей и объявленные исключения из политики доверия. Политика проверки задает, какие доказательства требуются для этапа жизненного цикла и какие классы отказов блокируют допуск, требуют рецензирования или создают диагностический сигнал.
Проверяющий компонент оценивает этот пакет относительно политики и выпускает результат проверки. Проверенный результат может поддерживать допуск к развертыванию; отсутствующий, устаревший, отозванный или несоответствующий результат порождает заблокированные доказательства или диагностический сигнал доверия; принятое исключение должно быть зафиксировано как доказательство исключения из политики доверия. Эта статья проверяет доказательства допуска к развертыванию и их непрерывность. Она не отвечает за оркестрацию развертывания, планирование, поэтапное развертывание, откат или материализацию сервиса.
Словарь SLSA используется здесь как словарь доказательств, согласованный со SLSA: идентификатор исходного кода, идентификатор сборщика, доказуемое происхождение сборки, идентификатор артефакта и политика проверки. Это не заявление об уровне SLSA или соответствии SLSA. То же различие действует для in-toto и DSSE: они структурируют аттестации, а результаты проверки зависят от объявленной политики и фактического покрытия доказательствами.
Доверие к транзитивным зависимостям
Материал SBOM перечисляет программные компоненты и зависимости; материал VEX фиксирует, являются ли известные уязвимости эксплуатируемыми в конкретном контексте продукта или артефакта [8,19]. Эти две поверхности доказательств помогают рецензентам отличать разрыв инвентаризации зависимостей от разрыва разбора уязвимости. Сами по себе они не устанавливают доверие к транзитивным зависимостям.
Доверие к транзитивным зависимостям требует дополнительных доказательств: доказуемого происхождения зависимости, аттестации зависимости, состояния по уязвимостям, политики обновления, доказательств разрешенного отступления и непрерывной проверки новых раскрытых уязвимостей. Разрыв инвентаризации зависимостей означает, что компонент, требуемый для рецензирования, отсутствует в SBOM. Отсутствующее доказуемое происхождение зависимости означает, что компонент перечислен, но не имеет доказательств исходного кода, сборки или аттестации. Известная эксплуатируемая уязвимость означает, что состояние зависимости должно блокировать допуск или требовать явных доказательств исключения. Неэксплуатируемая уязвимость с обоснованием VEX может поддерживать рецензирование, когда обоснование актуально и ограничено опубликованным артефактом. Устаревшее состояние VEX означает, что утверждение об эксплуатационной применимости больше не удовлетворяет ожиданиям актуальности или политики.
Поэтому контур цепочки доверия рассматривает доказательства зависимостей как живые доказательства. Материалы SBOM и VEX поддерживают рецензирование релиза, допуск к развертыванию и диагностическую классификацию; они не устанавливают полное доверие к транзитивным зависимостям сами по себе. Изменения зависимостей после релиза должны оставаться объединяемыми с квитанцией релиза, допуском к развертыванию, проверкой запуска во время выполнения и диагностическим рецензированием.
Непрерывность доверия при развертывании и выполнении
Допуск к развертыванию — это точка, в которой доказательства цепочки доверия становятся предварительным условием выполнения. Политика допуска проверяет идентификатор квитанции релиза, дайджест образа, дайджест скомпилированного пакета, отпечаток конфигурации, результаты проверки подписи, доказательства журнала прозрачности, состояние SBOM/VEX и объявленные исключения из политики доверия. Если требуемые доказательства отсутствуют или устарели, допуск должен завершаться с политикой fail-closed или выпускать явное исключение из политики доверия согласно объявленной политике. Контур цепочки доверия проверяет доказательства допуска и сообщает его результат; контур развертывания отвечает за поэтапное развертывание, откат, планирование и материализацию сервиса.
Затем проверка запуска во время выполнения проверяет, что сервис анализатора фактически материализовал. Она объединяет ожидаемый дайджест пакета, идентификатор образа, отпечаток конфигурации, дайджест совместимости библиотеки времени выполнения или Compute core и доказательства захвата манифеста релиза с записью запуска сервиса. Эти доказательства запуска поддерживают последующую проекцию доказательств выполнения; они не заменяют доказательства аудита, объединения трассируемости терминов или доказательства выполнения анализатора.
Непрерывность доверия остается активной после запуска. Истечение срока действия сертификата, ротация ключей, отзыв, устаревание доказательств, изменения состояния зависимостей и исключения из политики доверия могут инвалидировать прежние предположения. Непрерывная проверка превращает такие изменения в сигналы дрейфа доверия, а не оставляет рецензентов выводить их из несвязанных симптомов выполнения.
Рисунок 3. Непрерывность доверия во время выполнения и диагностическое объединение. Допуск к развертыванию проверяет опубликованный набор развертывания относительно политики цепочки доверия. Материализация при запуске и проверка запуска во время выполнения показывают, что было фактически запущено. Непрерывная проверка может позднее выявить отзыв, состояние зависимостей или сигналы устаревания доказательств, которые объединяются с диагностическим рецензированием.
Рисунок 3 отделяет доказательства доверия во время выполнения от вычисления во время выполнения. Анализатор может вычислять детерминированно, тогда как контур доверия все равно сообщает о разрыве цепочки доверия, например об устаревшем доказательстве VEX или отозванном сертификате подписи.
Диагностическое использование доказательств цепочки доверия
Доказательства цепочки доверия становятся операционно полезными, когда помогают классифицировать аномалии. Объединение доказательств выполнения может не пройти, потому что был развернут неверный образ, отличается ожидаемый дайджест пакета, отсутствует аттестация, невозможно найти доказательство включения в журнал прозрачности, доказательства зависимостей устарели или идентификатор сертификата больше не удовлетворяет политике. Это диагностические сигналы цепочки доверия, а не дефекты авторизованной семантики.
Диагностический контур потребляет эти сигналы вместе с доказательствами выполнения, доказательствами релиза и доказательствами трассируемости терминов. Он может классифицировать проблему как несоответствие релиза и развертывания, дрейф доверия, разрыв доверия к зависимости, устаревшую аттестацию, отсутствующие доказательства прозрачности, разрыв захвата доказательств выполнения или несемантическое объяснение. Классификация может запустить управляемое последующее действие, но эта статья не определяет закрытие устранения недостатков.
Таблица 2. Результаты проверки и карта доказательств.
| Состояние | Проверяемые доказательства | Результат | Смысл для рецензента | Граница |
|---|---|---|---|---|
| Проверенные доказательства | Квитанция, образ, SBOM, аттестация, подпись, включение в журнал, допуск и доказательства запуска удовлетворяют политике. | Доказательства могут поддерживать допуск к развертыванию или рецензирование доверия во время выполнения. | Цепочка доверия связана для объявленной области. | Проверка поддерживает рецензирование; контуры развертывания и выполнения по-прежнему отвечают за исполнение. |
| Заблокированные доказательства | Требуемые доказательства отсутствуют, некорректно сформированы, не совпадают или запрещены политикой. | Выпускаются заблокированные доказательства. | Путь релиза или развертывания не должен молча продолжаться. | Блокировка является результатом доверия, а не семантическим закрытием. |
| Устаревшие доказательства | Временная метка, VEX, аттестация, состояние зависимостей или контекст политики больше не удовлетворяют правилам актуальности. | Выпускаются доказательства дрейфа доверия. | Ранее принятые доказательства требуют рецензирования перед продолжением использования. | Устаревание само по себе не идентифицирует дефект графа. |
| Отозванный сертификат, ключ или идентификатор доказательств | Сертификат, ключ, идентификатор артефакта или идентификатор доказательств отозван. | Доказательства отзыва блокируют или эскалируют согласно политике. | Историю подписи нужно интерпретировать с учетом текущего контекста отзыва. | Обработка отзыва не является юридической неотказуемостью. |
| Отсутствующее включение в журнал | Подпись существует, но требуемое доказательство включения в журнал в стиле Rekor отсутствует. | Выпускаются отсутствующие доказательства прозрачности. | Доказательства только с подписью отделяются от видимых подписанных доказательств. | Включение в журнал поддерживает прозрачность; это не доказательство корректности. |
| Разрыв инвентаризации зависимостей | SBOM не включает обязательный компонент или дайджест, нужный для рецензирования. | Выпускается разрыв инвентаризации зависимостей. | Доказательства зависимостей неполны на уровне инвентаризации. | Покрытие SBOM не является полным доверием к зависимостям. |
| Разрыв доверия к зависимости | Зависимость инвентаризирована, но не имеет доказательств происхождения, аттестации, обновления или принятия. | Выпускается разрыв доверия к зависимости. | Зависимость требует управляемого рецензирования или доказательств исключения. | Цепочка доверия не выводит отсутствующее доказуемое происхождение. |
| Устаревшее обоснование VEX | Обоснование VEX существует, но не проходит проверки актуальности, области или политики. | Выпускаются доказательства устаревшего VEX. | Эксплуатационная применимость уязвимости должна быть повторно прорецензирована для области релиза. | VEX поддерживает классификацию; это не постоянное разрешенное отступление. |
| Управляемое исключение из политики доверия | Управляемое исключение явно принято с обоснованием и владельцем. | Выпускаются доказательства исключения из политики доверия. | Система фиксирует, почему политика разрешила продолжение использования. | Исключения не должны превращаться в молчаливое принятие. |
| Несоответствие релиза и развертывания | Развертывание выбирает образ, пакет, конфигурацию или квитанцию вне принятой основы релиза. | Выпускаются доказательства несоответствия релиза и развертывания. | Проблема классифицируется до обвинения вычисления во время выполнения или семантики. | Оркестрация развертывания остается вне этой статьи. |
Таблица 3. Ключевые риски и меры купирования.
| Риск | Отказ | Купирование в контуре цепочки доверия |
|---|---|---|
| Неподдержанное заявление SLSA | Рецензенты читают словарь как заявление о соответствии или уровне. | Статья рассматривает SLSA как словарь обеспечения доверия и требует явных доказательств для любого заявления об уровне. |
| Устаревшая аттестация | Аттестация больше не отражает текущий контекст релиза, зависимости или развертывания. | Непрерывная проверка проверяет устаревание доказательств и объединяет устаревшие доказательства с диагностическими сигналами. |
| Отсутствующее включение в журнал | Артефакт подписан, но не видим в объявленной поверхности прозрачности. | Политика проверки отличает проверку подписи от доказательства включения в журнал. |
| Отозванный или истекший сертификат | Ранее принятый идентификатор подписи больше не удовлетворяет политике. | Идентификатор сертификата, срок действия, отзыв и подписанная временная метка проверяются при непрерывной проверке. |
| Разрыв доверия к зависимости | SBOM перечисляет зависимость без достаточного происхождения, состояния VEX или обоснования обновления. | Доказуемое происхождение зависимости, актуальность VEX и состояние по уязвимостям становятся отдельными входами рецензирования. |
| Дрейф доверия | Доказательства релиза были действительны при продвижении, но больше не удовлетворяют политике после релиза. | Дрейф доверия сообщается как диагностический сигнал доверия, а не выводится из симптомов выполнения. |
| Несоответствие релиза и развертывания | Развертывание выбирает артефакт вне принятой основы релиза. | Допуск к развертыванию проверяет квитанцию релиза, дайджест образа, дайджест пакета, отпечаток конфигурации и доказательства доверия. |
| Завышенное утверждение прозрачности | Подписанные и записанные в журнал доказательства трактуются как доказательство корректности анализатора. | Контур фиксирует, что подписание и включение в журнал поддерживают рецензирование, но не доказывают клиническую достаточность или достаточность во время выполнения. |
| Смешение с авторизованной семантикой | Доказательства цепочки доверия трактуются как утверждение семантики графа. | Глобальный инвариант удерживает авторизованную семантику в управляемом графовом пути. |
Проработанный сценарий цепочки доверия
Рассмотрим управляемый релиз, который создал квитанцию релиза и захват манифеста релиза для модуля анализатора без сохранения состояния и модуля потокового анализатора. Проверяющий компонент цепочки доверия начинает с дайджеста квитанции релиза, объединяет его с принятым дайджестом образа, дайджестом скомпилированного пакета, отпечатком конфигурации и дайджестом SBOM, а затем проверяет, что каждый дайджест присутствует в объявленном пакете доказательств доверия.
Шаг происхождения проверяет заявление происхождения в стиле in-toto, обернутое DSSE. Заявление идентифицирует образ анализатора и скомпилированный пакет как субъекты, фиксирует ревизию исходного кода или эквивалентный идентификатор исходного кода, идентификатор сборщика, материалы, побочные артефакты и дайджесты артефактов и связывается с квитанцией релиза. Шаг подписания проверяет подписи образа, квитанции, SBOM и аттестации согласно объявленной политике проверки. Если используется подписание без управления ключами, результат проверки фиксирует идентификатор сертификата и подписанную временную метку.
Шаг прозрачности проверяет, что требуемые подписанные доказательства имеют запись журнала в стиле Rekor и доказательство включения. Если проверка подписи проходит и включение в журнал присутствует, проверяющий компонент выпускает проверенный результат для этого класса доказательств. Если доказательства подписи существуют, но доказательство включения отсутствует, проверяющий компонент выпускает отсутствующие доказательства прозрачности, а не трактует подпись как окончательное доказательство.
Шаг зависимостей объединяет дайджест SBOM с материалом VEX. Полная инвентаризация с актуальным обоснованием VEX о неэксплуатируемости может поддерживать рецензирование допуска. Отсутствующий компонент становится разрывом инвентаризации зависимостей; инвентаризированный компонент без доказуемого происхождения становится разрывом доверия к зависимости; известная эксплуатируемая уязвимость может блокировать допуск; устаревшее заявление VEX выпускает доказательства дрейфа доверия.
Допуск к развертыванию получает опубликованный набор развертывания и пакет доказательств доверия. Он проверяет ожидаемый дайджест образа, дайджест скомпилированного пакета, отпечаток конфигурации, дайджест квитанции релиза, результат проверки подписи, доказательство включения в журнал, состояние SBOM/VEX и объявленные исключения из политики доверия. Если допуск проходит, оркестрация развертывания может материализовать сервис. Затем проверка запуска во время выполнения фиксирует фактический образ, пакет, конфигурацию и дайджест совместимости. Проекция доказательств выполнения позднее может объединить наблюдения анализатора с той же основой релиза и цепочки доверия.
Если сертификат отозван после развертывания или заявление VEX устаревает, непрерывная проверка выпускает доказательства дрейфа доверия. Диагностическое рецензирование может классифицировать последующую аномалию как разрыв цепочки доверия, разрыв доверия к зависимости, исключение из политики доверия или несоответствие релиза и развертывания, а не как дефект авторизованной семантики. Человеческое управление решает, остается ли анализатор принятым, требует ли повторного развертывания, нуждается ли в новом релизе или должен быть выведен из эксплуатации.
Этот сценарий демонстрирует рецензируемую непрерывность доверия без добавления клинических, регуляторных или семантически авторизующих утверждений.
Ограничения и отсутствия утверждений
Статья не заявляет клиническую валидацию, валидацию уровня регистрационного досье, юридическую неотказуемость, сертификацию продукта, уровень SLSA или соответствие SLSA, полное доверие к транзитивным зависимостям, отсутствие всех уязвимостей, автономное утверждение семантики, прямое изменение графа или хранилища триплетов, реализацию анализатора времени выполнения или полное доказательство цепочки поставки. Она не утверждает, что подпись, запись журнала прозрачности, SBOM, заявление VEX, конверт DSSE, заявление in-toto, квитанция релиза или результат допуска к развертыванию сами по себе доказывают доверие.
Статья также не заменяет управляемые шлюзы релиза, диагностическое закрытие, захват доказательств выполнения, объединения реестра/трассы, операции развертывания, реагирование на инциденты или процедуры системы качества. Она определяет рецензируемый контур цепочки доверия и объединения доказательств, нужные для обнаружения дрейфа доверия и разрывов цепочки доверия.
Заключение
Непрерывная цепочка доверия превращает доказательства управляемого релиза в рецензируемую непрерывность доверия. Ее центральный вклад — ограниченное объединение от квитанции релиза и захвата манифеста к аттестациям, подписям, доказательствам журнала прозрачности, состоянию зависимостей, допуску к развертыванию, проверке запуска во время выполнения, проекции доказательств выполнения и диагностическим сигналам доверия. Удерживая доказательства доверия отдельно от авторизованной семантики, продвижения релиза, материализации развертывания, вычисления во время выполнения и человеческих решений о закрытии, контур поддерживает пригодность к выполнению аудита без создания второго источника истины.
Авторская основа
Статья опирается на внутреннюю документацию проекта HealthOS: спецификации, схемы и реестры, задающие авторизованную семантику и её скомпилированную форму, на среду выполнения и инструменты, дающие доказательства выполнения, и на смежные статьи серии, объединённые общим каноном терминологии. Это рабочие источники, которые обосновывают инженерные решения и удерживают единство терминологии в серии. Они остаются внутренней авторской основой, а не публичными ссылками, и не приводятся как ссылки на репозиторий в тексте.
Конфликт интересов
Рукопись описывает реализацию определенного аспекта платформы HealthOS, а именно: непрерывную цепочку доверия поверх доказательств релиза и развертывания исполняемых модулей анализатора.
Финансирование
Финансирование работ со стороны РТЛАБ.
Литература
- IEC. IEC 62304:2006/AMD 1:2015 Medical device software - Software life cycle processes. International Electrotechnical Commission / International Organization for Standardization. https://www.iso.org/standard/64686.html
- ISO. ISO 14971:2019 Medical devices - Application of risk management to medical devices. International Organization for Standardization. https://www.iso.org/standard/72704.html
- ISO. ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes. International Organization for Standardization. https://www.iso.org/standard/59752.html
- W3C. PROV-O: The PROV Ontology. https://www.w3.org/TR/prov-o/
- HL7. FHIR R4 AuditEvent. https://hl7.org/fhir/R4/auditevent.html
- RFC Editor. RFC 8785: JSON Canonicalization Scheme (JCS). https://www.rfc-editor.org/rfc/rfc8785
- JSON Schema. JSON Schema Draft 2020-12. https://json-schema.org/draft/2020-12
- CycloneDX. CycloneDX Specification Overview. https://cyclonedx.org/specification/overview/
- Sigstore. Cosign. https://docs.sigstore.dev/cosign/
- Open Container Initiative. The OpenContainers Image Spec. https://specs.opencontainers.org/image-spec/
- ISO. ISO/IEC/IEEE 12207:2026 Systems and software engineering - Software life cycle processes. International Organization for Standardization. https://www.iso.org/standard/90219.html
- IEEE Standards Association. IEEE 828: Standard for Configuration Management in Systems and Software Engineering. https://standards.ieee.org/ieee/828/10549/
- NIST. SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. https://csrc.nist.gov/pubs/sp/800/218/final
- Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA) v1.2. https://slsa.dev/spec/v1.2/about
- in-toto project. in-toto: A framework to secure the integrity of software supply chains. https://in-toto.io/
- Secure Systems Lab. Dead Simple Signing Envelope (DSSE). https://github.com/secure-systems-lab/dsse
- Sigstore. Rekor: Software Supply Chain Transparency Log. https://docs.sigstore.dev/logging/overview/
- Sigstore. Fulcio. https://github.com/sigstore/fulcio
- OpenVEX project. OpenVEX Specification. https://github.com/openvex/spec