Госзаказчик не примет систему, в которой безопасность пришита после релиза. Приёмка идёт по ГОСТ Р 56939-2016, а для государственных информационных систем добавляются требования приказа ФСТЭК № 17 и класс защищённости. Если вы вспоминаете об этом на этапе сдачи, переделка стоит дороже самой разработки. Безопасная разработка (SSDLC) – это не отдельный этап и не аудит в конце, а набор практик, встроенных в каждый шаг от требований до сопровождения.

Где в жизненном цикле появляется защита

SSDLC распределяет контроль по всем фазам, а не концентрирует его в финале.

  • Требования. Угрозы моделируем сразу. Определяем модель нарушителя, актуальные угрозы по методике ФСТЭК 2021 года, сверяемся с БДУ. Класс защищённости ГИС задаёт, какие меры обязательны, а какие избыточны.
  • Проектирование. Разделяем контуры, минимизируем привилегии, проектируем аудит и журналирование с самого начала. Интеграции – отдельная зона риска: каждый внешний канал расширяет поверхность атаки. Если данные ходят через интеграционную шину, на ней же удобно централизовать аутентификацию сервисов, валидацию сообщений и сквозное логирование.
  • Разработка. Статический анализ (SAST) на каждый коммит, проверка зависимостей на известные уязвимости, секреты – только в защищённом хранилище, а не в репозитории.
  • Тестирование. Динамический анализ (DAST), фаззинг входных данных, ручной анализ для критичных модулей.
  • Сопровождение. Управление уязвимостями не заканчивается со сдачей: компоненты стареют, появляются новые CVE.

Каждая мера должна быть документирована – без подтверждающих артефактов аттестация ГИС не проходит.

Инструменты в условиях импортозамещения

Для объектов КИИ и ГИС инструментарий тоже подпадает под требования к отечественному ПО и реестру Минцифры. Используем анализаторы кода из реестра – PT Application Inspector, Svace, AppScreener. Контур CI/CD строим на российских платформах и self-hosted решениях, чтобы исходный код и артефакты не покидали периметр.

Отдельный риск – интеграции с унаследованными системами. Когда заказная система обменивается данными с 1С через API, проверяем не только свой код, но и контракты обмена: авторизацию вызовов, фильтрацию полей, лимиты. Подробнее о подходе – в материале про интеграцию с 1С через API. То же касается аналитики: при выгрузке в российские BI-платформы разграничиваем доступ к строкам и колонкам на уровне источника, а не дашборда.

Как это выглядит в договоре и приёмке

SSDLC должен быть зафиксирован в ТЗ и в плане работ, иначе его не оплатят и не зачтут.

  1. Модель угроз и техзадание на защиту – на старте, согласованы с заказчиком и при необходимости с регулятором.
  2. Регламент безопасной разработки: какие проверки, на каком этапе, с какими порогами блокировки сборки.
  3. Отчёты SAST/DAST и протоколы устранения уязвимостей – как приёмочные артефакты.
  4. Передача исходного кода, документации и среды сборки в составе поставки.
  5. Поддержка после сдачи: SLA на закрытие уязвимостей по уровням критичности.

Такой пакет проходит аттестационные испытания без авралов и снимает споры на приёмке.

Вывод

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