Как подключить подпись кода ML-DSA к CI/CD в 2026 году?

Поскольку ML-DSA стандартизован в FIPS 204, сначала проверьте в изолированном конвейере управление ключами, подписание и проверку артефактов, а также совместимость программ-потребителей — и только потом включайте схему поэтапно. Стандартизация алгоритма сама по себе не означает, что ваша система сборки, формат пакета и все клиентские среды уже умеют работать с ним.

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

До настройки конвейера определите, что именно вы подписываете

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

Затем нарисуйте путь доверия. Отдельно отметьте:

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

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

Уточните также, какой формат подписи ожидает потребитель. Например, DSSE описывает оболочку для подписанных утверждений, но наличие совместимого контейнера не доказывает, что конкретный клиент поддерживает ML-DSA. Алгоритм, формат данных и программная реализация — отдельные части решения. Их нужно проверять вместе на реальном пути от публикации до установки.

В FIPS 204 определены варианты ML-DSA-44, ML-DSA-65 и ML-DSA-87; размеры открытого ключа, закрытого ключа и подписи для них различаются. Например, для ML-DSA-44 в стандарте указаны соответственно 1 312, 2 560 и 2 420 байт; для ML-DSA-65 — 1 952, 4 032 и 3 309 байт; для ML-DSA-87 — 2 592, 4 896 и 4 627 байт. Эти параметры приведены в документе NIST FIPS 204. Учитывайте их при оценке ограничений формата, передачи и хранения, но не делайте вывод о производительности вашего конвейера по размеру ключа или подписи.

Можно ли применять ML-DSA для подписи программных артефактов?

Да, ML-DSA можно рассматривать для подписи программных артефактов: это стандартизованный алгоритм цифровой подписи, закреплённый в FIPS 204. Но ответ на вопрос о готовности к внедрению зависит от конкретной реализации, формата подписи и инструмента на стороне потребителя. Стандарт определяет криптографическую схему; он не обещает, что ваша система сборки или установленное ПО уже распознаёт этот алгоритм.

До пилота зафиксируйте полное название реализации и её версию, а также выберите параметры ML-DSA, допустимые вашей политикой безопасности. Не обозначайте как ML-DSA экспериментальный или собственный алгоритм только потому, что он основан на схожих принципах. Если используемая библиотека документирует поддержку алгоритма, прочитайте её описание интерфейса и ограничения. Например, документация OpenSSL по EVP-интерфейсу для ML-DSA описывает работу именно этой реализации; сама по себе она не подтверждает совместимость другого криптографического пакета или клиента.

Для перехода к настройке подготовьте короткую ведомость совместимости:

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

Если хотя бы один обязательный потребитель не может проверить новую подпись, не считайте внедрение завершённым. Зафиксируйте, какой путь получения и проверки будет использовать этот потребитель и кто отвечает за его обновление. Рекомендации NIST NCCoE по инвентаризации и планированию перехода на постквантовую криптографию помогают рассматривать такую проверку как часть миграции, а не как одиночную замену криптографического вызова.

Этап подготовки: установите правила для ключей и доступа

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

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

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

Отдельно назначьте ответственных за ротацию и отзыв ключа. До первого тестового выпуска ответьте письменно:

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

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

Этап подключения: связывайте подпись с конкретной сборкой

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

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

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

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

Как проверить подпись и верификацию в CI/CD?

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

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

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

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

Для воспроизводимости сохраняйте вместе с журналом подписи сведения об исходном коде, сборочной среде, дайджесте результата и используемом ключе. Метаданные происхождения по SLSA помогают описывать связь артефакта с процессом сборки, однако их формат не подменяет проверку самой подписи. Если вы используете DSSE, отдельно проверьте, что система-потребитель понимает его оболочку и применённый алгоритм, а не только умеет извлечь вложенное утверждение.

Этап пилота: проверьте клиентов и задайте условия продвижения

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

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

Используйте следующие условия принятия решения:

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

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

Зафиксируйте границы тестовой среды

Даже хорошо воспроизводимая среда разработки подтверждает только то, что действительно проверялось в ней. В статье нет подтверждённых данных о конкретном окружении ZavCloud, повторном прогоне ML-DSA в нём или результатах такой проверки, поэтому делать выводы о поддержке, скорости подписи или криптографической надёжности в этой среде нельзя.

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

Если вашему тесту нужен отдельный macOS-узел для проверки сборочного сценария, аренду Mac mini можно рассматривать как вариант временной инфраструктуры. Сам факт использования такого узла не подтверждает поддержку ML-DSA: её нужно отдельно проверить в выбранной библиотеке и во всех инструментах, принимающих артефакт.

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

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

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

Перед продвижением отметьте обязательные проверки

• [ ] Вы определили, какие точные байты подписываются и какой объект проверяет потребитель.
• [ ] Вы подтвердили, что используемая реализация соответствует FIPS 204, а не только называется постквантовой.
• [ ] Вы документировали генерацию, хранение, использование, ротацию и отзыв ключей.
• [ ] Вы ограничили доступ к закрытому ключу необходимыми задачами и исключили его попадание в журналы.
• [ ] Вы связали результат подписи с идентификатором сборки, дайджестом и записью о публикации.
• [ ] Вы проверили неизменённый и изменённый артефакты, неподходящий ключ и отсутствие подписи.
• [ ] Вы проверили формат и алгоритм на всех обязательных потребителях, а не только в задаче сборки.
• [ ] Вы заранее определили, когда остановить выпуск, сохранить прежнюю проверку или вернуть утверждённый процесс.
• [ ] Вы отделили наблюдаемые результаты пилота от предположений о других средах и версиях.

Если ваши текущие средства подписания опираются на один общий секрет, не проверяют артефакт в среде потребителя и не оставляют понятного следа происхождения сборки, расширять такую схему без пилота рискованно. С другой стороны, при постоянной нагрузке или необходимости физического оборудования отдельная аренда может оказаться менее подходящей, чем собственная инфраструктура. Для временной проверки совместимости сначала сопоставьте требования к разработческой среде и криптографической библиотеке; если нужен отдельный стенд, рассмотрите аренду Mac у ZavCloud, не принимая её за подтверждение поддержки ML-DSA.