🥶 DevSecOps и сертификация CI/CD по ГОСТ 56939
Салюты,
Я тут пока отвалился не надолго, скоро вернусь с качественным обновлением для канала, будет кайф.
На сейчас пока я хотел бы поделиться одной из болей, которую обсуждали в сообществе findevsecops.ru @fintechassociation, а именно мы поговорим про сертификацию.
Зачем бизнесу?
- Экономия ресурсов — исправлять уязвимости на ранних этапах дешевле и проще
- Снижает риски инцидентов, в следствии потенциального прямого и косвенного урона в виде финансовых потерь, то есть повышает доверие к компании на рынке
- Защищенность ПО от уязвимостей и киберугроз, то есть как и на каких этапах учитывать ИБ
- Развитие сотрудников и качества, стабильности разработки, то есть повышает конкуретноспособность
- Важна при работе с государственным сектором и крупными заказчиками от их требований, если компания разрабатывает или вносит изменения в СЗИ, а также работает с объектами КИИ, ГИС и/или ИСПДн
- Стандарт помогает быстро и уверенно проходить контроль со стороны заказчиков и/или независимых аудиторов
- Подтверждает, что процессы отвечают требованиям к защищённой разработке (если проходим 2024 и не просто закрываемся бумажками в большей части ИСП РАН спрашивает конкретику, но все мы знаем как проходит сертификация)
Основные поинты согласно приказу 240
- Орган по сертификации ИСП РАН: в порядке расписаны сроки,
где большую часть времени занимает работа по сертификации
- Заявка с указанием основной информации и приложение
с руководством безопасной разработке во ФСТЭК России
- Сертификация проводится на базе изготовителя с проверкой соответствия, в том числе оценка документации и оборудования
- Заключение о соответствии процессов (Заявка на рассмотрении в течение 15 рабочих дней):
-- При несоответствии, изготовитель устраняет их и уведомляет для повторной сертификации.
-- При соответствия подготавливается проект сертификата, который рассматривается ФСТЭК России.
Ключевые маркеры ГОСТ 56939-2024
- Стандарты ГОСТ 56939 и ГОСТ 15408 являются основой для подтверждения безопасности процесса разработки
- Сертификат выдается компании, а не только на конкретное приложение
- Сертификация действует до 5 лет и может охватывать не один, а несколько продуктов, - все компоненты, зависимости, библиотеки и инструменты, участвующие в разработке
- Органы сертификации могут в любой момент проверить произвольное приложение из конвейера или готовый продукт. Это исключает возможность «подготовить только один проект для отчёта».
- В фокусе — не только код, но и сам процесс: сборка, тестирование, управление версиями, деплой. Проверка может охватывать сразу несколько CI/CD конвейеров, используемых в организации.
- Формальные документы (процедуры, политики, регламенты) должны соответствовать тому, как на самом деле устроен процесс разработки.
- Все программные компоненты и артефакты (исходники, библиотеки, сборки) должны храниться в проверенном и контролируемом хранилище, чтобы обеспечить воспроизводимость и защищённость.
- Сертификацию начинают с конкретного продукта, и только затем переходят к оценке самого процесса разработки. Исключения возможны, но крайне редки.
- Продукты и процессы должны быть связаны с конкретными техническими требованиями и угрозами. Это фиксируется в проектной документации и проверяется на соответствие.
- Для сертификации потребуется собрать более 100 требований и подтвердить их выполнением через ~120 артефактов — это технические документы, тесты, отчёты, описания процессов и систем.
Итого: по ГОСТ 56939-2024 становится более внятным, каждый день, что требуется от людей и каким образом это влияет на бизнес, так как уровень активностей связанных с инфобезом и последствиями их отсутвтия влияют не просто на работу структур, а именно на возможность монетизации, самой unit-экономики продуктов. Поэтому посмотрев это мы можем примерно понять ценность, а по факту явных требований не видели, только рекомендации в большинстве случаев от регулятора (либо я просто слепой)
#devsecops #pmi #specialty #gost #compliance