С чего начать внедрение безопасной разработки?

С анализа текущего состояния (процесс 5.1): пройти 25 процессов, отметить, что уже делается и чем подтверждается, затем подготовить план развития процессов (очерёдность внедрения, изменения в структуре, закупки, обучение) и план их реализации (сроки, этапы, ресурсы, ответственные) — их можно оформить одним документом. После этого — руководство по безопасной разработке и регламенты процессов.

Можно ли не применять часть процессов стандарта?

Состав обязательных процессов определяют акт, договор или ТЗ, которые требуют соответствия стандарту. Если процесс к программе объективно неприменим — например, в ней нет заимствованных компонентов, — это обосновывают особенностями программы и фиксируют в руководстве; для НИОКР состав процессов и условия применимости закрепляют в ТЗ (пункт 4.15). Обоснование не отменяет обязательного требования, а ссылка на то, что так сейчас не делают, обоснованием не считается.

Самооценка по ГОСТ Р 56939-2024

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

Управление и обучение

5.1 Планирование процессов разработки безопасного программного обеспечения

определить, на какое ПО распространяются процессы, оценить их текущее состояние и спланировать внедрение и ресурсы

5.2 Обучение сотрудников

поддерживать знания работников о безопасной разработке, типовых ошибках и уязвимостях

Требования и проектирование

5.3 Формирование и предъявление требований безопасности

формулировать требования безопасности к ПО, доводить их до исполнителей и отслеживать выполнение

5.4 Управление конфигурацией программного обеспечения

отслеживать элементы ПО и документации, их версии и изменения на протяжении жизненного цикла

5.5 Управление недостатками и запросами на изменение программного обеспечения

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

5.6 Разработка, уточнение и анализ архитектуры программного обеспечения

проектировать архитектуру, снижающую возможность появления уязвимостей, и уточнять её по ходу разработки

5.7 Моделирование угроз и разработка описания поверхности атаки

определить угрозы, актуальные для ПО, меры их нейтрализации и части ПО, доступные нарушителю

Код и его проверка

5.8 Формирование и поддержание в актуальном состоянии правил кодирования

установить правила оформления кода и запрещённые опасные конструкции и проверять их соблюдение

5.9 Экспертиза исходного кода

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

5.10 Статический анализ исходного кода

выявлять ошибки и уязвимости кода инструментами без его выполнения и разбирать каждое срабатывание

5.11 Динамический анализ кода программы

выявлять ошибки при выполнении программы, в том числе фаззинг-тестированием

5.14 Управление доступом и контроль целостности кода при разработке

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

5.15 Обеспечение безопасности используемых секретов

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

5.16 Использование инструментов композиционного анализа

вести перечень заимствованных компонентов и выявлять в них известные уязвимости

5.17 Проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок

снижать риск внедрения вредоносного кода через поставщиков компонентов и инфраструктуры

Сборка, тестирование и выпуск

5.12 Использование безопасной системы сборки программного обеспечения

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

5.13 Обеспечение безопасности сборочной среды программного обеспечения

защищать сборочную среду, регистрировать сборки и обеспечивать их повторяемость

5.18 Функциональное тестирование

проверять соответствие ПО функциональным требованиям по плану и сценариям

5.19 Нефункциональное тестирование

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

5.20 Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения

выпускать версию только после приёмки и решения по неустранённым ошибкам, с возможностью проверки целостности

5.21 Безопасная поставка программного обеспечения пользователям

хранить копии версий и доставлять ПО и обновления пользователям с проверкой подлинности

Эксплуатация и уязвимости

5.22 Обеспечение поддержки программного обеспечения при эксплуатации пользователями

поддерживать пользователей, оповещать их об обновлениях и уязвимостях

5.23 Реагирование на информацию об уязвимостях

принимать сообщения об уязвимостях, оценивать их актуальность и критичность и принимать решения

5.24 Поиск уязвимостей в программном обеспечении при эксплуатации

регулярно искать известные уязвимости в эксплуатируемых версиях и выпускать исправления

5.25 Обеспечение безопасности при выводе программного обеспечения из эксплуатации

выводить ПО из эксплуатации по установленным условиям с оповещением пользователей

Как считается готовность

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

Такая оценка — начало анализа текущего состояния, которого требует процесс 5.1 ГОСТ Р 56939-2024. Из пробелов складывается план развития процессов. Как оформить руководство и план, разобрано в статье о регламенте безопасной разработки, а что требовать от проверок кода — в статье о проверках кода.

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