Безопасная разработка: от истории методологий к работающим процессам

Составитель учебного материала — Виталий Пиков, эксперт и преподаватель в области информационной безопасности. pikov.art.

Безопасность программного обеспечения складывается из решений, принятых на протяжении всей его жизни. Что команда считает допустимым риском? Как выбирает зависимости? Кто проверяет архитектуру? Что происходит с предупреждением анализатора? Кто отвечает на сообщение об уязвимости после выпуска? Ответы на эти вопросы определяют результат не меньше, чем выбранный язык программирования или набор инструментов.

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

После изучения материала вы сможете:

• объяснить, почему проверка готового продукта должна дополняться работой с процессами его создания;
• различать историю разработки стандарта, содержание его требований и способы подтверждения соответствия;
• правильно сопоставлять редакции ГОСТ Р 56939-2016 и ГОСТ Р 56939-2024;
• оценить исходное состояние своей команды и определить приоритетные улучшения;
• связать намеченное улучшение с людьми, ресурсами, сроками и проверяемым результатом.

Введение

Безопасная разработка объединяет инженерные практики, стандарты и организацию работы. Введение задаёт общий контекст для исторической и практической частей.

1. Безопасность начинается раньше испытаний

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

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

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

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

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

2. Как развивались методологии безопасной разработки

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

Крупные производители программного обеспечения начали оформлять собственные методологии раньше появления многих общих стандартов. Microsoft связывает включение SDL в процесс разработки с 2004 годом. Публикации о Touchpoints и CLASP также относятся к раннему этапу систематизации практик. Позднее развивались способы включения безопасности в итеративную разработку, модели организационной зрелости и общие рамки, пригодные для разных поставщиков.

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

Обзор Secure Software Development Methodologies: A Multivocal Literature Review рассматривает 28 подходов и публикаций из промышленной, государственной и академической среды. Его полезность состоит не только в перечне дат. Он показывает, насколько разные способы организации могут объединять сходные инженерные практики.

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

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

Выбранные публикации и редакции из истории методологий. Обзор рассматривает 28 подходов; шкала не исчерпывает их историю.

Часть I. История и развитие национального стандарта

Исторический доклад: Виталий Вареница.

Эта часть объясняет замысел ГОСТ Р 56939, подготовку первой редакции, международные связи и развитие системы документов. Историю создания необходимо отличать от содержания утверждённых требований.

3. Зачем понадобился национальный стандарт

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

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

По воспоминаниям Виталия Вареницы, одного из участников разработки ГОСТ Р 56939-2016, обсуждения необходимости такого документа шли примерно с 2009 года. Подготовка замысла и взаимодействие с коллегами и регуляторами предшествовали формальному началу работы над проектом. Следовательно, 2016 год обозначает утверждение документа, а не начало безопасной разработки в России.

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

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

4. История создания ГОСТ Р 56939-2016

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

Вареница связывает основную подготовку первой редакции с НПО «Эшелон». Это не означает единоличного принятия стандарта одной компанией. Другие организации участвовали в рассмотрении и обсуждении проекта, направляли замечания и предложения. При этом непосредственная подготовка текста и внешнее рецензирование — разные формы участия, которые стоит различать.

Этапы подготовки проекта приведены по историческому докладу Вареницы. В нём также указаны 22 организации, участвовавшие в публичном обсуждении, и около 200 замечаний и предложений. Даты утверждения и введения в действие зафиксированы в официальных сведениях Росстандарта и в самом стандарте.

Предисловие ГОСТ Р 56939-2016 называет разработчиком ЗАО «НПО „Эшелон“», а организацией, внёсшей документ, — ТК 362 «Защита информации». Стандарт утверждён Росстандартом. Поэтому в историческом изложении необходимо точно называть и разработчика, и технический комитет, и орган утверждения.

Рабочие редакции текста не следует путать с утверждёнными национальными стандартами. В воспоминаниях о дальнейшей работе встречаются версии 2018, 2019, 2020 и 2022 годов. Из этого не следует существование отдельных действовавших ГОСТ Р 56939 с каждым из этих обозначений. При практическом сравнении рассматриваются утверждённые редакции 2016 и 2024 годов.

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

Подготовка проекта, утверждение и введение стандарта в действие — разные этапы.

5. Международные связи: самостоятельность не означает изоляцию

ГОСТ Р 56939-2016 не следует описывать ни как перевод одной зарубежной методологии, ни как документ, возникший вне международной инженерной практики. Его содержание и заявленные связи показывают более содержательную картину: национальная рамка создавалась с учётом уже существовавших подходов.

Раздел 1 редакции 2016 года допускает применение стандарта как источника мер и средств управления безопасностью программного обеспечения по ГОСТ Р ИСО/МЭК 27034-1. Он также допускает его использование для конкретизации или расширения компонентов доверия ГОСТ Р ИСО/МЭК 15408-3. В справочном приложении А представлены соответствующие взаимосвязи с требованиями доверия Common Criteria.

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

NIST SSDF удобен для современного сопоставления с ГОСТ, но не мог быть источником первой редакции 2016 года: первый публичный проект SSDF был объявлен NIST 11 июня 2019 года. SSDF 1.1 опубликован как NIST SP 800-218 в 2022 году. Эта последовательность устанавливает границу возможной причинной связи, однако сама по себе не доказывает ни мирового первенства ГОСТ, ни обратного заимствования.

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

6. От первой редакции к системе связанных документов

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

Одним из связанных документов стал ГОСТ Р 58412-2019 о типовых угрозах безопасности информации при разработке программного обеспечения. Его назначение помогает понять важное различие: угрозы самому процессу и среде разработки не сводятся к уязвимостям готового приложения. Можно нарушить целостность исходного кода, повлиять на сборку или управление изменениями и получить небезопасный результат даже при внешне корректной организации испытаний.

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

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

Редакция ГОСТ Р 56939-2024 утверждена 24 октября 2024 года приказом Росстандарта № 1504-ст и введена в действие 20 декабря 2024 года. Работа над обновлением велась раньше; Вареница вспоминает подготовленный к 2022 году проект и последующее расширение участия организаций. Эти воспоминания объясняют ход подготовки, но не заменяют официальные сведения об утверждении.

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

Здесь сравниваются разные единицы группировки. Нельзя считать увеличение числа заголовков непосредственным доказательством большей безопасности. Часть содержания разделена, часть конкретизирована, появились более явные акценты на отдельных направлениях. Компенсирующие меры, предусмотренные п. 4.5 редакции 2016 года, не являются ещё двумя группами оглавления: это возможность иным способом достигнуть целей и результатов базовых мер при невозможности их обычной реализации.

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

Часть II. Применение ГОСТ и планирование безопасной разработки

Совместный практический разбор: Андрей Карпов и Виталий Пиков.

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

7. Мера и процесс: что делает работу устойчивой

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

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

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

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

При этом неверно представлять редакцию 2016 года набором исключительно разовых мероприятий. Её пп. 4.4 и 4.7–4.9 уже предусматривали реализацию мер, выделение ресурсов, внутренние проверки и улучшение процессов. Различия между редакциями нужно искать в конкретных формулировках и устройстве требований, а не в упрощённой формуле «раньше один раз, теперь постоянно».

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

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

8. Как читать требования стандарта

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

Особенно нагляден пример слова «следует». В ГОСТ Р 56939-2016 п. 4.2 оно использовано для выражения рекомендации среди других возможностей. В ГОСТ Р 56939-2024 п. 4.7 слова «должен» и «следует» выражают требования, которые должны быть выполнены. Привычное прочтение старой редакции нельзя автоматически переносить в новую.

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

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

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

Наконец, стандарт, договор и правила оценки соответствия отвечают на разные вопросы. Чтобы определить обязательства конкретной организации, необходимо установить, какие документы к ней применимы и каким образом требуется подтвердить выполнение работ. Универсальный ответ на основании одного названия ГОСТ обычно недостаточен.

9. Проверки безопасности решают разные задачи

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

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

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

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

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

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

Разные методы отвечают на разные вопросы о продукте; их результаты полезны в сочетании.

10. Сторонний код и код, созданный с участием ИИ

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

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

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

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

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

Это не исчерпывает специальные вопросы безопасности самих систем ИИ. Для них могут понадобиться дополнительные модели угроз и методы оценки. Но в обычной программной разработке базовое правило сохраняется: ответственность связана с принятым и поставленным продуктом, а не только с непосредственным авторством каждой строки.

11. Планирование: согласовать намерение с возможностями

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

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

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

Например, требование «внедрить композиционный анализ» слишком широко для исполнения. Нужны выбор продуктов и источников сведений о составе, определение места проверки, настройка обработки результатов, распределение ответственности и способ актуализации. Только после такого разложения можно обоснованно оценивать сроки и стоимость.

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

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

12. Установить исходное состояние

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

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

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

Полезно разделить результаты обследования на три группы:

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

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

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

13. Область применения и очередность внедрения

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

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

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

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

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

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

14. Как оценивать ресурсы и стоимость

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

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

Бесплатное программное средство не означает бесплатного процесса. Его требуется установить, настроить, включить в разработку, обновлять и поддерживать. Платная лицензия, в свою очередь, не гарантирует, что у команды появилось время на обработку результатов. Инструментальная и человеческая части бюджета должны рассматриваться вместе.

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

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

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

15. Люди, компетенции и распределение ответственности

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

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

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

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

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

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

16. Какие результаты должны остаться после планирования

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

Для разбора первого процесса ГОСТ Р 56939-2024 удобно выделить пять записей:

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

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

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

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

Пять связанных результатов планирования по процессу 5.1 ГОСТ Р 56939-2024.

17. Автоматизация работы и свидетельств

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

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

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

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

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

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

18. Сопровождение и работа с выявленными недостатками

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

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

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

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

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

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

Учебная схема работы с недостатком на протяжении сопровождения продукта.

19. Соответствие, сертификация процессов и сертификация продукта

Полезно различать несколько вопросов. Выполняет ли команда определённые инженерные практики? Соответствуют ли они требованиям выбранного стандарта? Нужна ли отдельная сертификация процессов? Как оценивается сам продукт? Какие требования предъявляются к применяемым инструментам? Эти вопросы связаны, но ответы на них не совпадают автоматически.

Если заказчик требует соблюдения ГОСТ, необходимо установить содержание требования: редакцию документа, область применения, объект и способ подтверждения. Упоминание стандарта само по себе не объясняет все условия оценки. Дополнительные обязанности могут следовать из договора или применимого регулирования.

Государственные информационные системы (ГИС) и объекты критической информационной инфраструктуры (КИИ) нельзя автоматически подводить под один набор требований. Перед применением документа определяют вид системы, роль организации и область действия документа. Сходство инженерных задач безопасной разработки само по себе не устанавливает применимость конкретного требования.

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

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

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

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

Практический принцип — ясно формулировать заявление о достигнутом состоянии. «Используем отдельные практики», «внедрили процессы в такой-то области» и «подтвердили соответствие в установленном порядке» означают разное. Точность формулировки помогает и команде, и заказчику понимать реальные основания доверия.

20. Небольшая команда: соразмерность и обязательства

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

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

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

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

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

21. Как учиться безопасной разработке

Безопасная разработка объединяет несколько самостоятельных дисциплин. Архитектурный анализ, тестирование, управление зависимостями, организация процессов и обработка уязвимостей требуют разных знаний и практического опыта. Поэтому поиск одной книги, которая полностью заменит подготовку по всем направлениям, редко приводит к нужному результату.

Эффективнее строить обучение вокруг рабочих задач. Стандарт помогает определить требования. Методология показывает способ организации. Техническое руководство объясняет метод. Практическое упражнение позволяет проверить, способен ли человек применить знание к своему продукту.

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

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

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

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

Учебный практикум

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

22. Практическая работа: первый план для одного продукта

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

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

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

Далее формируется небольшая программа работ:

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

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

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

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

Вопросы и ответы

Здесь собраны вопросы общей дискуссии и пояснения, полезные при применении материала к своему продукту.

Чем полезен ГОСТ, если сертификация не планируется?

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

Девять групп мер и двадцать пять процессов — это показатель прогресса?

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

Почему нельзя читать «следует» одинаково в обеих редакциях?

Потому что стандарты сами определяют смысл этой формулировки. В п. 4.2 редакции 2016 года она обозначает рекомендацию; в п. 4.7 редакции 2024 года — требование, которое должно быть выполнено. Значение нужно устанавливать по применимому документу.

Можно ли ограничиться одним анализатором?

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

С чего начать, если процессы безопасности не организованы?

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

Должны ли сначала пройти обучение все сотрудники?

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

Кто отвечает за безопасную разработку?

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

Какой процент бюджета нужно добавить?

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

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

Развитие можно планировать по этапам, но при этом нужно учитывать применимые обязательства. Частичное внедрение следует описывать как частичное. Оно не становится полным соответствием только благодаря наличию дорожной карты.

Требует ли ГОСТ множества отдельных файлов?

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

Чем open source отличается с точки зрения ответственности?

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

Нужно ли проверять код, предложенный ИИ?

Да. Команда принимает решение о включении кода и должна обеспечить его проверку. Способ получения фрагмента не гарантирует ни корректности, ни безопасности и не заменяет инженерную ответственность.

Нужен ли отдельный сертификат, если заказчик требует ГОСТ?

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

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

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

Что меняется для небольшой команды?

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

Как понять, что внедрение начало работать?

Рассмотреть реальные изменения и проблемы продукта. Выполняются ли предусмотренные действия? Понятны ли решения и ответственность? Сохраняются ли результаты? Использует ли команда полученные сведения для исправлений и улучшения порядка работы? Такой разбор содержательнее одной отметки «процесс внедрён».

Источники для дальнейшего изучения

1. ГОСТ Р 56939-2016. Защита информации. Разработка безопасного программного обеспечения. Общие требования. Для исторического сравнения особенно полезны разделы 1, 4, 5 и приложение А. Официальные сведения Росстандарта.
2. ГОСТ Р 56939-2024. Защита информации. Разработка безопасного программного обеспечения. Общие требования. Общие положения определяют правила применения; п. 5.1 посвящён планированию. Официальные сведения Росстандарта.
3. ГОСТ Р 58412-2019. Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.
4. Виталий Вареница. «История создания и актуальное состояние РБПО в России. ГОСТ Р 56939-2016/24». Исторический доклад НПО «Эшелон», представленный 2 июля 2025 года.
5. Arina Kudriavtseva, Olga Gadyatskaya. Secure Software Development Methodologies: A Multivocal Literature Review. Препринт arXiv:2211.16987v2, 4 июля 2023 года. Полезен для сопоставления назначения и содержания разных подходов. Версия v2.
6. NIST SP 800-218. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, 2022. Окончательная публикация. Для исторической шкалы: объявление первого публичного проекта SSDF, 11 июня 2019 года.
7. Microsoft Security Development Lifecycle. История и назначение SDL. Официальное описание.
8. OWASP SAMM. Модель развития организационной зрелости безопасной разработки. Материалы проекта.

Основа материала — вебинар МАСКОМ и PVS-Studio от 2 июля 2025 года, проведённый Виталием Пиковым и Андреем Карповым, и исторический доклад Виталия Вареницы. Исторические сведения об участниках и этапах подготовки проекта атрибутированы докладчику; сведения об утверждённых редакциях приведены по соответствующим стандартам. Практическая работа в разделе 22 — учебный пример.