Что такое безопасная разработка ПО и с чего её начинают

Зачем безопасная разработка ПО

Уязвимость, найденная у пользователя, стоит дороже той же уязвимости, найденной до сборки. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 встраивает защиту в саму разработку, а не пристраивает её сверху перед выпуском.

ГОСТ Р 56939-2024 ставит перед практикой четыре цели: выявлять недостатки, в том числе уязвимости; снижать их количество; снижать ущерб от тех, что остались невыявленными; оперативно устранять выявленные 1. Последние два пункта важнее, чем кажутся: стандарт не обещает разработку без уязвимостей и прямо признаёт, что часть их дойдёт до эксплуатации.

Практика отвечает не за отсутствие уязвимостей, а за то, что их ищут системно, находят рано и закрывают предсказуемо.

В России у практики есть особенность, которой нет у соседних: она бывает обязательной. Для разработчиков средств защиты информации соответствие ГОСТ Р 56939-2024 проверяется сертификацией процессов 2, для значимых объектов критической информационной инфраструктуры анализ кода требует приказ ФСТЭК № 239 3. Для остальных это добровольная практика — до первого тендера, где её попросят.

Когда практика работает

Три вопроса. Ответы на них лежат в регламентах, а не в отчётах сканеров.

Проверки описаны регламентом, а не привычкой команды. Как проверить: для каждого вида анализа записано, кто его проводит, с какой периодичностью и по каким критериям он считается завершённым. Стандарт требует именно этого: периодичность статического анализа, критерии завершения тестирования, зоны ответственности 1.

Требования безопасности заданы до кода. Как проверить: у продукта есть сформулированные требования безопасности и описание поверхности атаки, а не только функциональные истории 1.

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

Что входит и что рядом

Двадцать пять процессов, а не «сканер в конвейере»

Раздел 5 ГОСТ Р 56939-2024 задаёт двадцать пять процессов — от планирования и обучения сотрудников до вывода ПО из эксплуатации 1. Инструментальные проверки занимают среди них меньше половины.

Полный состав по группам:

Организация. Планирование процессов. Обучение сотрудников.

Замысел. Формирование требований безопасности. Разработка и анализ архитектуры. Моделирование угроз и описание поверхности атаки.

Написание кода. Правила кодирования. Экспертиза исходного кода. Статический анализ. Динамический анализ. Композиционный анализ. Проверка кода на внедрение вредоносного ПО через цепочки поставок.

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

Проверка и выпуск. Функциональное и нефункциональное тестирование. Безопасность при выпуске готовой версии. Безопасная поставка пользователям.

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

Каждый процесс описан одинаково: наименование, цели, требования к реализации, артефакты реализации требований 1. Артефакт — то, что предъявляют проверяющему, и потому именно он определяет, внедрён процесс или объявлен.

Что на входе и что на выходе

На входе — требования к продукту и решения об архитектуре. На выходе — выпуск с известным уровнем защищённости и записанными сведениями о том, что осталось неисправленным.

Обратное движение важнее прямого: то, что нашли при эксплуатации, возвращается в требования и правила кодирования. Без этого практика превращается в конвейер проверок, который каждый раз ловит один и тот же класс ошибок.

Три входа: почему это может оказаться обязательным

Российская нормативка подходит к безопасной разработке с трёх сторон, и попасть под неё можно, не планируя этого.

Сертификация процессов. Порядок ФСТЭК проверяет процессы разработчика «на соответствие требованиям национального стандарта Российской Федерации ГОСТ Р 56939-2024» 2. Сертификат выдаётся не более чем на пять лет. При проверке смотрят руководство по безопасной разработке, артефакты по всем двадцати пяти процессам, наличие средств статического, динамического и композиционного анализа, а также обеспеченность сотрудниками с нужными знаниями 2.

Критическая информационная инфраструктура. Приказ ФСТЭК № 239 требует для значимых объектов статический анализ исходного кода и фаззинг-тестирование, а для объектов первой категории значимости — ещё и динамический анализ 3.

Уровни доверия. Требования к уровням доверия средств защиты — третья опора, отдельная от сертификации процессов 4.

Отсюда следует вот что. Разработчик, который продаёт ПО в госсектор или в отрасли с критической инфраструктурой, приходит к этой практике не по доброй воле, а по требованию заказчика — и лучше прийти заранее.

Как это работает

Два места стоит объяснить отдельно.

Второй и третий шаги делают до кода, а не после. Требования безопасности и модель угроз — вход для всего остального: без них проверки ищут вообще, а не то, что для этого продукта опасно.

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

Что с чем путают

Безопасная разработка и тестирование. Проверки безопасности — часть работы, а не вся она. Из двадцати пяти процессов инструментальный анализ занимает пять; остальное — требования, архитектура, среда, поставка, реагирование 1.

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

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

Сертификация процессов и сертификация продукта. Первое подтверждает, что процессы разработчика соответствуют стандарту 2. Второе — что конкретная версия продукта соответствует требованиям. Это разные документы и разные проверки.

Кто участвует

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

NIST выносит роли в отдельную практику PO.2 и требует ролевого обучения, а также обязательства руководства, «переданного всем, у кого есть роли в разработке» 7.

Как измерять

Здесь у практики особенность, которую стоит знать до того, как от вас потребуют отчётность.

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

Показатели с названиями есть только в открытых моделях зрелости.

Сроки в первоисточниках есть как обязанность, а не как число. OWASP SAMM на втором уровне требует «задать сроки для классов критичности», на третьем — их соблюдать 8. Ни одна модель не говорит, сколько дней это должно быть: число задаёт компания, исходя из своих рисков.

Двух ходовых метрик в источниках нет. «Доля выпусков без известных уязвимостей» и «плотность дефектов безопасности» звучат разумно, но ни ГОСТ, ни NIST, ни SAMM, ни DSOMM их не называют. Если вы их вводите — это ваша метрика, и обосновывать её придётся самим.

Зрелость безопасной разработки

Готовых шкал две, и они меряют разное. OWASP SAMM описывает организацию: пять бизнес-функций, пятнадцать практик, у каждой два потока и три уровня 8. OWASP DSOMM смотрит на конвейер: пять измерений и пять уровней, от базового понимания практик безопасности до их развёрнутого применения в масштабе 9. Смешивать их уровни нельзя — это разные линейки.

Российской методики оценки соответствия пока не существует: ГОСТ отсылает к отдельному национальному стандарту, которого в базе Росстандарта нет 1. На практике оценку ведут по Порядку ФСТЭК — то есть по составу артефактов 2.

Где ломается чаще всего

Шесть мест. Первые три названы российским стандартом-спутником ГОСТ Р 58412-2019, где перечислены типовые угрозы разработки 5.

Требования безопасности не заданы, и уязвимость закладывается на старте. Угроза появления уязвимостей из-за ошибок при задании требований — первая в перечне 5.

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

Найденное сознательно не исправляют. Стандарт-спутник называет это прямо: решение о неисправлении обнаруженных ошибок принимается, «например, для сокращения времени разработки» 5. Это управленческий выбор, а не халатность, — и потому его требуют фиксировать вместе с оценкой влияния 1.

Инструменты разработки сами становятся источником уязвимостей. Второй источник угроз в стандарте — не нарушитель, а средства разработки, алгоритм работы которых может привести к появлению уязвимости 5.

Сборочную среду защищают хуже, чем продуктовую. OWASP описывает это дословно: требования безопасности продуктовой среды часто не переносят на сборочный конвейер, реестр образов остаётся незащищённым, и это грозит кражей всего исходного кода компании 9.

Безопасность не встроена в модель разработки. NIST начинает документ с того же наблюдения: немногие модели жизненного цикла явно и подробно занимаются безопасностью, поэтому практики приходится добавлять в модель отдельно 7.

Что говорят своды

68Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ГОСТ Р 56939-2024 — головной документ российского семейства. Действует с 20 декабря 2024 года, заменил редакцию 2016 года. Разработчиков десять, головной — ФСТЭК России; среди остальных «Лаборатория Касперского», ИСП РАН, «ИнфоТеКС», Positive Technologies, «РусБИТех-Астра», «СберТех» 1. Задаёт двадцать пять процессов с целями, требованиями и артефактами.

Порядок сертификации ФСТЭК делает эти требования обязательными для разработчиков средств защиты информации и описывает, что именно проверяют 2.

Приказ ФСТЭК № 239 — второй вход: анализ кода для значимых объектов критической информационной инфраструктуры 3.

ГОСТ Р 58412-2019 — стандарт-спутник: перечень типовых угроз, из-за которых практика ломается 5. Оговорка: его приложение сопоставляет угрозы с мерами редакции 2016 года, и на новые процессы его пересчитывать нельзя.

ГОСТ Р 71206-2024 и ГОСТ Р 71207-2024 уточняют отдельные технологии — безопасный компилятор и статический анализ 6.

NIST SP 800-218 SSDF — открытая международная рамка. Четыре группы практик: подготовить организацию, защитить само ПО, выпускать хорошо защищённое ПО, реагировать на уязвимости 7.

OWASP SAMM и DSOMM — открытые модели зрелости, первая про организацию, вторая про конвейер 8, 9.

ISO/IEC 27034 говорит о безопасности приложений в целом — это соседний ориентир, а не международный аналог ГОСТ Р 56939 10.

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

Где описано

Бесплатного официального текста ГОСТ Р 56939-2024 нет: просмотрщик Росстандарта его не отдаёт, а правовые базы показывают документ не целиком.

Что почитать дальше

Три соседние практики: DEVРазработка и управление ПО — разработка вообще, TSTПроверка и тестирование услуг — проверка и тестирование результата, SECУправление информационной безопасностью — что происходит с уязвимостями за пределами разработки.