Автоматический релиз доверенных исполняемых модулей анализатора из доверенного снимка знаний в замкнутом цикле

Авторский коллектив

  1. Прозоров А.А., Директор по технологиям РТЛАБ, архитектор Сбертех, ap@rtlab.ru;

Аннотация

Цель: В статье определяется контур управляемого релиза для доверенных исполняемых модулей анализатора; этот контур закрывает операционный разрыв между доверенным снимком знаний и артефактами анализатора, привязанными к релизу и пригодными для развертывания, воспроизведения и рецензирования.

Метод: Статья является методологической системной работой с ограниченными доказательствами конвейера релиза. Она разделяет замыкание семантики, создание скомпилированного пакета, построение кандидата релиза, шлюзы релиза, формирование квитанции, подписанные доказательства релиза, захват манифеста релиза и передачу управления развертыванию. Внешние источники обосновывают дисциплину жизненного цикла регулируемого программного обеспечения, рамку управления рисками, трассируемость в системе качества, аналогии доказуемого происхождения данных и событий аудита, канонические дайджесты, доказательства с ограничением схемой, структуру SBOM, подписание артефактов, идентификатор образа, жизненный цикл программного обеспечения, управление конфигурацией, безопасную разработку программного обеспечения и словарь границы цепочки поставки [1-14].

Результаты: В статье специфицируется шлюз релиза, связанный с артефактами; он объединяет доверенный снимок знаний, скомпилированный пакет, кандидат релиза анализатора, квитанцию релиза, подписанные доказательства релиза, захват манифеста релиза, совместимость волны релиза и передачу управления развертыванию. Контур релиза делает модули анализатора рецензируемыми, не превращая автоматизацию релиза в авторизованную семантику и не заявляя обеспечение доверия в цепочке поставки.

Вывод: Контур управляемого релиза превращает доверенное исполняемое знание в рецензируемые модули анализатора, сохраняя разделение ответственности между семантикой, релизом, развертыванием, выполнением и доказательствами.

Ключевые слова: управляемый релиз; доверенный снимок знаний; исполняемый модуль анализатора; кандидат релиза; квитанция релиза; подписанные доказательства релиза; захват манифеста релиза; волна релиза; передача управления развертыванию; пригодность к выполнению аудита

Сокращения и терминология

Доверенный снимок знаний: Авторизованный снимок, принятый как семантический вход для релиза. В этой статье он может сопровождаться диагностическими доказательствами, готовыми к закрытию, но не создается и не исправляется процессом релиза.

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

Кандидат релиза: Набор-кандидат модулей анализатора, собранный из доверенного снимка знаний, скомпилированного пакета, образа сервиса, доказательств конфигурации, доказательств тестирования, материала SBOM и метаданных публикации до продвижения.

Шлюз релиза: Машинно-проверяемое или контролируемое рецензентом условие, которое должно быть выполнено до продвижения кандидата релиза. В этой статье шлюзы включают проверки схемы, дайджеста, воспроизводимости, тестов, санитайзеров, SBOM/уязвимостей, подписи, квитанции и продвижения.

Шлюз продвижения: Контрольная точка для рецензента, которая принимает или отклоняет переход от кандидата релиза к опубликованному набору развертывания. Продвижение является решением о релизе, а не утверждением семантики.

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

Подписанные доказательства релиза: Доказательства релиза, в которых квитанция, образ, SBOM или связанные артефакты доказательств связаны с материалом подписи согласно заявленной политике подписания. В этой статье подписание поддерживает рецензируемые доказательства релиза; оно не является утверждением об уровне цепочки поставки или соответствии.

Захват манифеста релиза: Артефакт доказательств управления релизом, который фиксирует факты совместимости волны релиза, включая дайджест манифеста релиза, идентификатор модуля анализатора, дайджест совместимости Runtime library или Compute core, дайджест образа и необязательный дайджест снимка.

SBOM: Ведомость состава программного обеспечения, используемая здесь как доказательство релиза для инвентаризации программных компонентов и зависимостей. Материал SBOM поддерживает рецензирование релиза и шлюз проверки уязвимостей; сам по себе он не доказывает доверие в цепочке поставки.

Отчет о соответствии образа развертывания: Доказательства релиза/развертывания, которые проверяют дайджест образа, положение точки входа во время выполнения, ожидаемые контроли и доступность доказательств перед передачей управления развертыванию.

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

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

Волна релиза: Управляемая область совместимости, в которой ожидается, что несколько модулей анализатора согласуются по общей основе совместимости Runtime library или Compute core.

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

Глобальный инвариант: Контур релиза не является авторизованной семантикой. Он упаковывает, проверяет, подписывает, записывает, продвигает и передает выпущенные модули анализатора; он не авторизует семантику графа, не выполняет прямое изменение графа или хранилища триплетов, не валидирует клиническую эффективность и не закрывает диагностическое устранение недостатков.

Введение

Системам исполняемого знания недостаточно доверенного снимка знаний и скомпилированного пакета. Рецензенту также нужно определить, какой модуль анализатора был выпущен, какой образ и какая конфигурация были приняты, какие тесты и шлюзы доказательств прошли, какой SBOM был приложен, какая политика подписания была выполнена и какой контур развертывания получил выпущенный набор. Без такого контура релиза аномалия выполнения может быть неотличима от устаревшего пакета, неподписанного артефакта, дрейфа квитанции, несоответствия волны релиза или сбоя передачи управления развертыванию.

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

Вклад статьи состоит в шаблоне релиза, ориентированном на артефакты, для исполняемых модулей анализатора. Он делает доказательства релиза связанными дайджестами, видимыми для рецензента и совместимыми с последующей проекцией доказательств выполнения, сохраняя единую авторизованную семантику и удерживая автоматизацию релиза в собственной границе ответственности.

Сопутствующие статьи

Контур авторизации и диагностики как универсальная инфраструктура разработки и управления исполняемым знанием отвечает за диагностическую классификацию, пакеты с устранением недостатков, управляемые запросы обновления графа, авторизованные доказательства записи, перестроенные снимки, доказательства закрытия и человеческие решения о закрытии. Настоящая статья начинается только после того, как этот предыдущий путь произвел доверенный снимок знаний или готовый к закрытию вход, пригодный для релиза.

Реализация потокового анализатора для смеси именованных признаков и осциллограмм отвечает за архитектуру потоков, сессий и окон, а также за проекцию доказательств потокового выполнения. Анализатор на основе правил без сохранения состояния для смеси именованных признаков и осциллограмм отвечает за архитектуру сервиса анализатора в пределах запроса. Настоящая статья упаковывает и продвигает модули анализатора для этих контуров; она не переопределяет их поведение выполнения.

Сквозная трассировка кодифицированных терминов для отладки и аудита компилятора и исполняемых модулей отвечает за объединения реестра/трассы и объединения доказательств выполнения. Настоящая статья переносит идентификаторы и дайджесты, привязанные к релизу, которые делают такие объединения рецензируемыми после развертывания.

Непрерывная цепочка доверия при автоматическом релизе исполняемых модулей анализатора в замкнутом цикле отвечает за долговременную непрерывность доверия и обеспечение доверия в цепочке поставки. Настоящая статья останавливается на управляемых шлюзах релиза, квитанциях релиза, подписанных доказательствах релиза, захвате манифеста релиза и передаче управления развертыванию.

Мгновенная оценка состояния здоровья на примере интерпретации смеси именованных терминов и осциллограмм ЭКГ отвечает за предметную интерпретацию и утверждения графа знаний ЭКГ. Доказательства релиза в этой статье являются инфраструктурными доказательствами, а не кардиологической валидацией.

Материалы и методы

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

Набор внешних источников намеренно компактен. IEC 62304 и ISO 13485 обосновывают жизненный цикл регулируемого программного обеспечения и трассируемость в системе качества [1,3]. ISO 14971 обосновывает рамку управления рисками, не превращая доказательства релиза в доказательство клинической безопасности [2]. PROV-O и FHIR AuditEvent дают аналогии доказуемого происхождения данных и структурированного события аудита для записей доказательств [4,5]. RFC 8785 и JSON Schema 2020-12 обосновывают канонический дайджест и оформление квитанций/доказательств с ограничением схемой [6,7]. CycloneDX, Sigstore/cosign и OCI Image Specification обосновывают словарь SBOM, подписания и идентификатора контейнерного образа, используемый контуром релиза [8-10].

Лексика инженерии релизов также связана с общими источниками программной инженерии. ISO/IEC/IEEE 12207 задает рамку жизненного цикла программного обеспечения; IEEE 828 задает терминологию управления конфигурацией, конфигурационной единицы, сборки и инженерии релизов [11,12]. NIST SSDF обосновывает безопасную разработку программного обеспечения и управление уязвимостями для шлюза SBOM/уязвимостей [13]. SLSA цитируется только для обозначения границы с сопутствующей статьей о цепочке доверия: настоящая статья не заявляет уровень SLSA, положение соответствия, структуру in-toto или сквозную цепочку аттестаций [14].

Обзор управляемого релиза

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

Цепочка жизненного цикла: доверенный снимок знаний и готовые к закрытию доказательства → скомпилированный пакет → кандидат релиза анализатора → шлюзы релиза → квитанция релиза → подписанные доказательства релиза → захват манифеста релиза → передача управления развертыванию → готовность доказательств выполнения.

IHA-SSE-04 (ru) — схема 1 A["Доверенный снимок знаний"] --> B["Готовые к закрытию доказательства из управляемого диагностического контура"]

проходит

не проходит

Доверенный снимок знаний

Готовые к закрытию доказательства из управляемого диагностического контура

Скомпилированный пакет и доказательства происхождения

Кандидат релиза анализатора

Шлюзы релиза: схема, дайджест, воспроизводимость, тесты, SBOM, политика подписания

Квитанция релиза

Заблокированный релиз с доказательствами отказа

Подписанные доказательства релиза

Захват манифеста релиза

Рецензирование совместимости волны релиза

Опубликованный набор развертывания

Передача управления развертыванию с ожидаемым дайджестом пакета и отпечатком конфигурации

Готовность доказательств выполнения

Рисунок 1. Контур жизненного цикла управляемого релиза. Жизненный цикл релиза начинается с доверенных семантических входов и готовых к закрытию доказательств, затем проходит через компиляцию, упаковку анализатора, оценку шлюзов, формирование квитанции, подписание, захват манифеста релиза, рецензирование совместимости волны релиза и передачу управления развертыванию. Непройденный шлюз создает доказательства блокировки релиза, а не частичный релиз. Финальный выход — готовность к развертыванию и доказательствам выполнения, а не утверждение семантики.

Рисунок 1 разделяет два направления, которые часто смешиваются. Предыдущий источник авторизованной семантики создает доверенный снимок знаний; автоматизация релиза его потребляет. Последующие контуры выполнения потребляют опубликованный набор развертывания; они не меняют задним числом то, что было принято релизом.

Таблица 1. Артефакты релиза, ответственность и границы полномочий.

Артефакт или поверхность Производитель Потребитель Назначение Граница полномочий
Доверенный снимок знаний Управляемый путь авторизованной семантики Компилятор и контур релиза Поставляет семантическую основу, принятую для релиза. Автоматизация релиза не создает и не исправляет его.
Готовые к закрытию диагностические доказательства Диагностический контур Рецензент релиза и шлюзы релиза Показывают, что предыдущие условия закрытия выполнены для области релиза. Сами по себе они не являются решением о продвижении.
Скомпилированный пакет Контур компилятора / Plane Кандидат релиза анализатора Материализует исполняемое знание, проекции реестра/трассы и доказательства происхождения для упаковки времени выполнения. Не выбирает развертывание и не доказывает клиническую эффективность.
Кандидат релиза анализатора Конвейер релиза Шлюзы релиза и рецензент Собирает образ, скомпилированный пакет, доказательства конфигурации, доказательства тестирования, материал SBOM и метаданные публикации. Не является релизом, пока не пройдут шлюзы и продвижение.
Материал SBOM Поверхность доказательств сборки/релиза Шлюзы релиза и рецензент Перечисляет релевантные для релиза программные компоненты и зависимости для рецензирования и шлюза уязвимостей. Не является полным доказательством цепочки доверия.
Доказательства тестирования и санитайзеров Конвейер релиза Шлюзы релиза и рецензент Демонстрируют ограниченные проверки реализации для кандидата. Не валидируют клиническую результативность.
Отчет о соответствии образа развертывания Конвейер релиза / контур доказательств развертывания Шлюз продвижения и передача управления развертыванию Проверяет дайджест образа, ожидаемые контроли, положение точки входа времени выполнения и доступность доказательств. Не развертывает сервис.
Квитанция релиза Конвейер релиза Рецензент, передача управления развертыванию, диагностический контур Связывает идентификатор образа, дайджест пакета, отпечаток конфигурации, дайджест SBOM, ссылки на тесты и метаданные релиза. Не является авторизованной семантикой и не должна содержать ПнД или секреты.
Подписанные доказательства релиза Контур подписания/доказательств Шлюз продвижения и передача управления развертыванию Фиксируют доказательства, связанные подписью, для квитанции, образа, SBOM или связанных артефактов. Поддерживают рецензирование релиза; не являются полным доказательством непрерывной цепочки доверия.
Захват манифеста релиза Контур доказательств релиза Диагностический контур Plane и рецензирование волны релиза Фиксирует факты совместимости волны релиза и дайджесты манифеста релиза. Plane потребляет эти доказательства; он не синтезирует идентификатор релиза.
Решение о продвижении Управление релизом под контролем человека/рецензента Конвейер релиза и передача управления развертыванию Принимает или отклоняет кандидат как опубликованный набор развертывания. Не утверждает изменения семантики.
Опубликованный набор развертывания Управление релизом Контур развертывания/выполнения Предоставляет ограниченный набор исполнения для развертывания, воспроизведения и рецензирования. Не является доказательством выполнения, пока не развернут и не наблюдаем.

Доверенный снимок знаний и входы релиза

Контур релиза потребляет доверенные входы; он не создает авторизованную семантику. Минимальный набор входов включает доверенный снимок знаний, скомпилированный пакет, полученный из него, доказательства происхождения или квитанции, показывающие, как был произведен пакет, и готовые к закрытию диагностические доказательства, когда область релиза зависит от управляемого цикла устранения недостатков. Дополнительные входы включают материал упаковки анализатора, конфигурацию развертывания, политику релиза, доказательства тестирования, материал SBOM и ожидаемую политику подписания.

Принятие входов выполняется по политике «при сбое — запрет по умолчанию». Если отсутствует дайджест доверенного снимка знаний, скомпилированный пакет нельзя объединить со снимком, доказательства закрытия устарели или кандидат релиза несет пакет, отличный от ожидаемого, релиз должен остановиться с доказательствами блокировки релиза. Эти доказательства полезны: они позволяют рецензентам классифицировать проблему как разрыв предыдущего закрытия, разрыв компиляции, разрыв упаковки или разрыв политики релиза.

Состав кандидата релиза

Кандидат релиза — первое место, где идентификаторы семантики, компилятора, анализатора, развертывания и доказательств становятся одним рецензируемым набором. В терминах управления конфигурацией это набор конфигурационных единиц и результатов сборки, подготовленный для оценки шлюзами, но еще не пакет релиза и не опубликованный набор развертывания [11,12]. Он включает дайджест доверенного снимка знаний, дайджест скомпилированного пакета, идентификатор образа анализатора, дайджест образа, отпечаток конфигурации, дайджест совместимости Runtime library или Compute core, материал SBOM, доказательства тестирования и санитайзеров, отчет о соответствии образа развертывания, политику релиза, политику подписания и метаданные продвижения. Источники по SBOM, подписанию и идентификатору образа поддерживают этот словарь состава, а источники по схемам и дайджестам делают кандидат релиза достаточно воспроизводимым для рецензирования [6-10].

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

Модель шлюзов релиза

Шлюзы релиза превращают кандидат в рецензируемое решение о релизе. Шлюзы схемы проверяют, что квитанции релиза, артефакты захвата манифеста релиза, материал SBOM, отчеты о соответствии образа развертывания и манифесты доказательств соответствуют заявленным схемам [7]. Шлюзы дайджеста проверяют, что идентификаторы доверенного снимка знаний, пакета, образа, SBOM и квитанции стабильны и воспроизводимы; для JSON-квитанций используется каноническое дайджестирование JSON [6]. Шлюзы воспроизводимости сравнивают независимые пути материализации или заявленные отпечатки сборки. Шлюзы тестов и санитайзеров присоединяют ограниченные доказательства реализации. Шлюзы SBOM/уязвимостей делают инвентаризацию зависимостей и состояние по уязвимостям видимыми [8,13]. Шлюзы проверки подписи связывают образ, квитанцию, SBOM или артефакты доказательств с заявленной политикой подписания [9]. Вместе эти шлюзы выражают дисциплину жизненного цикла, управления конфигурацией и релиза в системе качества, а не клиническую валидацию [1,3,11,12].

Модель шлюзов релиза использует общие роли программной инженерии, но не заменяет их. Конфигурационные единицы и результаты сборки оцениваются относительно политики релиза; квитанция релиза действует как компактная запись релиза и поверхность объединения проекта; шлюз продвижения фиксирует решение о продвижении релиза; захват манифеста релиза вносит вклад в учет статуса конфигурации для последующего рецензирования. Ни один из этих контролей не является утверждением об уровне цепочки поставки или соответствии [12,14].

Продвижение является шлюзом, ориентированным на рецензента. Кандидат релиза может пройти автоматические шлюзы и все равно быть удержан для человеческого рецензирования релиза, если этого требует политика. И наоборот, человек-рецензент не может молчаливо разрешить отсутствие машинных доказательств; само разрешение должно стать доказательством разрешенного отступления, а обоснование управления рисками для исключения должно оставаться явным [2].

Квитанция релиза и подписанные доказательства

Квитанция релиза — компактная поверхность объединения для рецензирования релиза. Она записывает идентификатор релиза, идентификатор модуля анализатора, ревизию исходного кода или эквивалентную ссылку на доказуемое происхождение, дайджест образа, дайджест скомпилированного пакета, отпечаток конфигурации, дайджест SBOM, ссылки на доказательства тестирования, время релиза и версию политики. В общепринятом словаре управления конфигурацией она функционирует как запись релиза проекта; она не заменяет более широкую систему управления конфигурацией или процесс обеспечения доверия в цепочке поставки [11,12,14]. Она должна быть достаточно небольшой для инспекции и достаточно стабильной, чтобы ее можно было хешировать, подписывать, архивировать и присоединять к доказательствам развертывания [6-10].

Подписанные доказательства релиза связывают артефакты релиза с заявленной политикой подписания. Контур может подписывать квитанцию, образ, SBOM и пакеты доказательств; он также может записывать результаты проверки подписи перед продвижением. Sigstore/cosign предоставляет используемый здесь словарь подписания, при этом статья намеренно не заявляет соответствие SLSA, уровни цепочки поставки, структуру происхождения in-toto или доверие к транзитивным зависимостям [9,14]. Этот более полный вопрос непрерывности относится к сопутствующей статье о цепочке доверия.

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

Захват манифеста релиза и совместимость волны релиза

Захват манифеста релиза записывает факты волны релиза, необходимые для рецензирования совместимости. Волна релиза — управляемая область совместимости: несколько модулей анализатора могут быть выпущены вместе только тогда, когда их заявленный дайджест совместимости Runtime library или Compute core согласуется с политикой волны. Захват также записывает дайджест манифеста релиза, дайджест образа, идентификатор модуля анализатора, отпечаток конфигурации и необязательный дайджест снимка.

Диагностический контур потребляет доказательства захвата манифеста релиза, когда классифицирует аномалии выполнения или развертывания. Несоответствие между анализаторами без сохранения состояния и потоковыми анализаторами внутри одной волны релиза является доказательством целостности релиза, а не дефектом семантического графа. Plane может коррелировать доказательства, но он не синтезирует идентификатор волны релиза и не исправляет релиз.

Передача управления развертыванию

Передача управления развертыванию передает опубликованный набор развертывания в контур развертывания/выполнения. Передача включает квитанцию релиза, ссылки на подписанные доказательства релиза, идентификатор образа, ожидаемый дайджест пакета, отпечаток конфигурации, захват манифеста релиза и ссылки на политику развертывания. Хост сервиса использует эти значения для проверки материализации при запуске и для переноса доказательств, привязанных к релизу, в поверхности результатов выполнения, аудита, отладки, метрик и проекции доказательств.

Сама передача управления не выполняет развертывание. Развертывание выбирает и материализует выпущенный набор в конкретной среде; последующие доказательства выполнения показывают, что действительно выполнялось. Если развертывание выбирает образ, пакет или конфигурацию, отличные от заявленных выпущенной передачей управления, итоговые доказательства должны классифицировать проблему как несоответствие релиза и развертывания, а не как дефект семантики или вычислений во время выполнения.

Контроли доказательств релиза

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

Хранение доказательств и доказательства разрешенного отступления являются частью контракта релиза. Сбой шлюза релиза может блокировать продвижение, а управляемое исключение может разрешить продвижение только тогда, когда доказательства разрешенного отступления фиксируют, что было разрешено, кто принял исключение, какое обоснование управления рисками применяется и какие последующие обязательства рецензирования остаются. Отладка выполнения и доказательства выполнения являются последующими поверхностями; они не реконструируются из квитанции релиза и не исправляют отсутствующие доказательства релиза [2,4,5].

Непрерывность дайджестов и доказательств

IHA-SSE-04 (ru) — схема 2 A["Дайджест доверенного снимка знаний"] --> B["Дайджест скомпилированного пакета"]

Дайджест доверенного снимка знаний

Дайджест скомпилированного пакета

Дайджест образа анализатора

Дайджест SBOM

Отпечаток конфигурации

Квитанция релиза

Дайджест квитанции

Подписанные доказательства релиза

Захват манифеста релиза

Передача управления развертыванию

Объединения доказательств выполнения

Рисунок 2. Непрерывность дайджестов и доказательств. Непрерывность дайджестов начинается с доверенного снимка знаний и скомпилированного пакета, продолжается через идентификатор образа, идентификатор SBOM, отпечаток конфигурации, квитанцию релиза, подписанные доказательства релиза, захват манифеста релиза и передачу управления развертыванию, а заканчивается объединениями доказательств выполнения. Каждое ребро является точкой объединения для рецензента; отсутствующий или несогласованный дайджест становится классифицируемым доказательством релиза.

Рисунок показывает, почему квитанция релиза является центральной. Она не заменяет лежащие под ней артефакты, но делает их идентификаторы инспектируемыми и переносимыми через продвижение, развертывание и последующее диагностическое рецензирование.

Совместимость волны релиза и диагностическая передача

IHA-SSE-04 (ru) — схема 3 A["Политика волны релиза"] --> B["Кандидат релиза анализатора без сохранения состояния"]

совместимо

несоответствие

Политика волны релиза

Кандидат релиза анализатора без сохранения состояния

Кандидат релиза потокового анализатора

Дайджест совместимости Runtime library / Compute core

Захват манифеста релиза

Рецензирование совместимости

Опубликованный набор развертывания

Диагностический сигнал целостности релиза

Передача управления развертыванию

Классификация диагностическим контуром

Рисунок 3. Совместимость волны релиза и диагностическая передача. Политика волны релиза связывает кандидаты анализатора без сохранения состояния и потокового анализатора с одной заявленной основой совместимости Runtime library или Compute core. Совместимые кандидаты могут быть продвинуты в опубликованный набор развертывания; несоответствия становятся диагностическими сигналами целостности релиза для классификации, а не дефектами графа авторизации.

Диагностическая передача намеренно узкая. Она дает последующим рецензентам достаточно доказательств, чтобы решить, вызвана ли проблема выполнения несоответствием волны релиза, устаревшим развертыванием, отсутствующими доказательствами или другим классом проблемы. Она не устраняет релиз автоматически и не изменяет авторизованную семантику.

Таблица 2. Ограниченные доказательства реализации и остаточные разрывы.

Элемент доказательств Текущее утверждение Значение для рецензента Остаточный разрыв
Модель шлюзов конвейера релиза Контур релиза может выражать шлюзы схемы, дайджеста, воспроизводимости, тестов, SBOM/уязвимостей, подписи и продвижения. Рецензенты видят, где кандидат был принят или заблокирован. Статья не заявляет зрелость управления релизами во всей организации.
Квитанция релиза Доказательства квитанции связывают идентификатор образа, дайджест пакета, отпечаток конфигурации, дайджест SBOM и ссылки на тесты. Результаты анализатора позднее можно объединить с принятой основой релиза. Содержимое квитанции должно оставаться согласованным с фактическими доказательствами развертывания.
Подписанные доказательства релиза Квитанция, образ, SBOM или связанные артефакты могут быть связаны с заявленной политикой подписания. Рецензенты могут проверить, что политика подписания была применена к артефактам релиза. Доказательство непрерывной цепочки доверия отложено до статьи о цепочке доверия.
Захват манифеста релиза Факты совместимости волны релиза могут быть материализованы для диагностического рецензирования. Несоответствие Runtime library или Compute core может быть классифицировано как доказательство целостности релиза. Доказательства захвата нельзя принимать за авторизованную семантику.
Соответствие образа развертывания Перед передачей управления можно проверить дайджест образа, положение точки входа времени выполнения, ожидания контроля и доступность доказательств. Рецензенты развертывания могут отличить соответствие образа от поведения анализатора во время выполнения. Фактические наблюдения выполнения все равно требуют развертывания и проекции доказательств.
Передача управления анализатора Опубликованный набор развертывания переносит ожидаемый дайджест пакета и отпечаток конфигурации в проверку запуска времени выполнения. Доказательства выполнения могут объяснить устаревший пакет или несоответствие конфигурации. Эта статья не реализует пути потокового анализатора или анализатора без сохранения состояния.
Контроли доказательств релиза Доказательства релиза несут идентификаторы, дайджесты, ссылки, результаты применения политики и ограниченные резюме без секретов, ПнД, сырого сигнального материала или дампов полезной нагрузки. Рецензенты могут инспектировать решения релиза, не превращая артефакты релиза в хранилища данных. Политика хранения и разрешенных отступлений должна оставаться управляемой вне рукописи.

Таблица 3. Ключевые риски и меры купирования.

Риск Отказ Купирование в контуре релиза
Устаревший снимок Кандидат релиза использует более старый или незакрытый доверенный снимок знаний. Дайджест снимка, готовые к закрытию доказательства и происхождение скомпилированного пакета должны совпадать до прохождения шлюзов релиза.
Неподписанный артефакт Образ, квитанция, SBOM или доказательства продвигаются без требуемого материала подписи. Шлюзы проверки подписи блокируют продвижение или создают явные доказательства разрешенного отступления.
Сбой шлюза SBOM/уязвимостей Инвентаризация зависимостей или состояние по уязвимостям невидимы или неприемлемы. Материал SBOM и результаты шлюза уязвимостей становятся доказательствами релиза.
Дрейф квитанции Утверждения квитанции больше не совпадают с образом, пакетом, SBOM или конфигурацией. Проверки дайджеста и подписание квитанции делают дрейф видимым до продвижения или при передаче управления развертыванию.
Несоответствие Runtime library Модули анализатора без сохранения состояния и потокового анализатора используют несовместимый материал Runtime library или Compute core внутри одной волны релиза. Захват манифеста релиза записывает дайджесты совместимости и создает диагностический сигнал целостности релиза при несоответствии.
Несоответствие релиза и развертывания Развертывание выбирает образ, пакет или конфигурацию, не принятую релизом. Передача управления развертыванию несет ожидаемый образ, дайджест пакета, квитанцию и отпечаток конфигурации.
Утечка секрета или ПнД Доказательства релиза случайно включают учетные данные, закрытые ключи, ПнД, сырые сигнальные данные или дампы полезной нагрузки. Контроли доказательств релиза ограничивают квитанции и сопутствующие артефакты идентификаторами, дайджестами, ссылками, результатами применения политики и ограниченными резюме.
Необоснованное утверждение о цепочке доверия Доказательства релиза принимаются за обеспечение доверия в цепочке поставки или утверждение об уровне цепочки поставки. Ограничения и границы сопутствующих статей резервируют уровни цепочки поставки, аттестации и транзитивное доверие для статьи о цепочке доверия.
Смешение с авторизованной семантикой Автоматизация релиза трактуется как утверждение семантики графа. Глобальный инвариант удерживает утверждение семантики выше по потоку относительно шлюзов релиза.

Проработанный сценарий релиза

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

Затем конвейер релиза собирает два кандидата релиза анализатора. Каждый кандидат несет идентификатор образа анализатора, дайджест образа, отпечаток конфигурации, дайджест совместимости Runtime library или Compute core, материал SBOM, доказательства тестирования и санитайзеров, отчет о соответствии образа развертывания, политику релиза и политику подписания. На этом этапе кандидаты являются рецензируемыми объектами, а не выпущенными модулями.

Оценка шлюзов идет в фиксированном порядке. Шлюзы схемы валидируют черновик квитанции релиза, черновик захвата манифеста релиза, отчет о соответствии образа развертывания, материал SBOM и манифесты доказательств. Шлюзы дайджеста сравнивают дайджест доверенного снимка знаний, дайджест скомпилированного пакета, дайджест образа, дайджест SBOM, отпечаток конфигурации и дайджест квитанции. Шлюзы тестов и санитайзеров присоединяют ограниченные доказательства реализации. Шлюзы SBOM/уязвимостей делают состояние зависимостей видимым. Шлюзы проверки подписи проверяют наличие требуемых подписей квитанции, образа, SBOM или доказательств.

Если кандидаты анализатора без сохранения состояния и потокового анализатора имеют ожидаемый дайджест совместимости Runtime library или Compute core, захват манифеста релиза записывает факты волны релиза. Затем рецензент принимает шлюз продвижения, создавая опубликованный набор развертывания. Передача управления развертыванию переносит квитанцию релиза, ссылки на подписанные доказательства, идентификатор образа, ожидаемый дайджест пакета, отпечаток конфигурации, захват манифеста релиза и ссылки на политику релиза в контур развертывания/выполнения. Проверка запуска времени выполнения позднее проверяет эти значения передачи управления до того, как сервис анализатора становится готовым, а доказательства выполнения могут объединяться с принятой основой релиза.

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

Сценарий демонстрирует управляемую и рецензируемую упаковку релиза. Он не валидирует клиническую результативность, не устанавливает обеспечение доверия в цепочке поставки, не развертывает анализатор и не авторизует изменения семантики.

Ограничения и отсутствия утверждений

Статья не заявляет клиническую валидацию, валидацию уровня регистрационного досье, обеспечение доверия в цепочке поставки, зрелость цепочки релиза, автономное утверждение семантики, прямое изменение графа или хранилища триплетов, реализацию анализатора времени выполнения, развертывание ровно один раз или юридическую неотказуемость. Она не утверждает, что SBOM, подпись, дайджест образа, квитанция релиза, захват манифеста релиза или доказательства разрешенного отступления сами по себе доказывают доверие.

Она не использует автоматизацию релиза как замену диагностическому закрытию, авторизованным доказательствам записи, человеческому рецензированию релиза, доказательствам развертывания, доказательствам выполнения или постразвертывающему аудиту. Она не заявляет уровень SLSA или положение соответствия, не определяет структуру in-toto, не предоставляет сквозную цепочку аттестаций и не устанавливает доверие к транзитивным зависимостям. Эти темы относятся к сопутствующей статье о цепочке доверия.

Заключение

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

Авторская основа

Статья опирается на внутреннюю документацию проекта HealthOS: спецификации, схемы и реестры, задающие авторизованную семантику и её скомпилированную форму, на среду выполнения и инструменты, дающие доказательства выполнения, и на смежные статьи серии, объединённые общим каноном терминологии. Это рабочие источники, которые обосновывают инженерные решения и удерживают единство терминологии в серии. Они остаются внутренней авторской основой, а не публичными ссылками, и не приводятся как ссылки на репозиторий в тексте.

Конфликт интересов

Рукопись описывает реализацию определенного аспекта платформы HealthOS, а именно: управляемый релиз от доверенного снимка знаний до передачи управления развертыванию.

Финансирование

Финансирование работ со стороны РТЛАБ.

Литература

  1. 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
  2. ISO. ISO 14971:2019 Medical devices - Application of risk management to medical devices. International Organization for Standardization. https://www.iso.org/standard/72704.html
  3. ISO. ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes. International Organization for Standardization. https://www.iso.org/standard/59752.html
  4. W3C. PROV-O: The PROV Ontology. https://www.w3.org/TR/prov-o/
  5. HL7. FHIR R4 AuditEvent. https://hl7.org/fhir/R4/auditevent.html
  6. RFC Editor. RFC 8785: JSON Canonicalization Scheme (JCS). https://www.rfc-editor.org/rfc/rfc8785
  7. JSON Schema. JSON Schema Draft 2020-12. https://json-schema.org/draft/2020-12
  8. CycloneDX. CycloneDX Specification Overview. https://cyclonedx.org/specification/overview/
  9. Sigstore. Cosign. https://docs.sigstore.dev/cosign/
  10. Open Container Initiative. The OpenContainers Image Spec. https://specs.opencontainers.org/image-spec/
  11. 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
  12. IEEE Standards Association. IEEE 828: Standard for Configuration Management in Systems and Software Engineering. https://standards.ieee.org/ieee/828/10549/
  13. NIST. SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. https://csrc.nist.gov/pubs/sp/800/218/final
  14. Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA) v1.2. https://slsa.dev/spec/v1.2/about