← pikov.expert

РБПО — разработка безопасного
программного обеспечения

Авторская учебная серия: нормативная база, процессы и практика безопасной разработки — на шести слайдах.

Слайд 01 · Серия РБПО

Уязвимости

ЧТО ТАКОЕ УЯЗВИМОСТЬ

ГОСТ Р ИСО/МЭК 27000-2021

«уязвимость (vulnerability): Слабое место актива или меры обеспечения информационной безопасности (3.14), которое может быть использовано одной или несколькими угрозами (3.74)».

[ГОСТ Р ИСО/МЭК 27000-2021 «Информационные технологии. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общие сведения и словарь», п. 3.77].

ГОСТ Р 56545-2015

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

[ГОСТ Р 56545-2015 «Защита информации. Уязвимости информационных систем. Правила описания уязвимостей»].

УЯЗВИМОСТЬ НУЛЕВОГО ДНЯ (0-DAY)

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

[ГОСТ Р 56545-2015 «Защита информации. Уязвимости информационных систем. Правила описания уязвимостей», п. 3.8].

CWE (COMMON WEAKNESS ENUMERATION)

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

[Источник: https://cwe.mitre.org/].
КЛАССИФИКАЦИЯ УЯЗВИМОСТЕЙ ИНФОРМАЦИОННЫХ СИСТЕМ ПО ГОСТ Р 56546-2015
Область происхождения · 5 классов: уязвимости кода · уязвимости конфигурации · уязвимости архитектуры · организационные уязвимости · многофакторные уязвимости
ТИПЫ НЕДОСТАТКОВ · 20 ТИПОВ
  1. недостатки, связанные с неправильной настройкой параметров программного обеспечения;
  2. недостатки, связанные с неполнотой проверки вводимых (входных) данных;
  3. недостатки, связанные с возможностью прослеживания пути доступа к каталогам;
  4. недостатки, связанные с возможностью перехода по ссылкам;
  5. недостатки, связанные с возможностью внедрения команд ОС;
  6. недостатки, связанные с межсайтовым скриптингом (выполнением сценариев);
  7. недостатки, связанные с внедрением интерпретируемых операторов языков программирования или разметки;
  8. недостатки, связанные с внедрением произвольного кода;
  9. недостатки, связанные с переполнением буфера памяти;
  10. недостатки, связанные с неконтролируемой форматной строкой;
  11. недостатки, связанные с вычислениями;
  12. недостатки, приводящие к утечке/раскрытию информации ограниченного доступа;
  13. недостатки, связанные с управлением полномочиями (учетными данными);
  14. недостатки, связанные с управлением разрешениями, привилегиями и доступом;
  15. недостатки, связанные с аутентификацией;
  16. недостатки, связанные с криптографическими преобразованиями (недостатки шифрования);
  17. недостатки, связанные с подменой межсайтовых запросов;
  18. недостатки, приводящие к «состоянию гонки»;
  19. недостатки, связанные с управлением ресурсами;
  20. иные типы недостатков.
МЕСТО ВОЗНИКНОВЕНИЯ · 7 МЕСТ
уязвимости в общесистемном (общем) программном обеспечении · в прикладном программном обеспечении · в специальном программном обеспечении · в технических средствах · в портативных технических средствах · в сетевом (коммуникационном, телекоммуникационном) оборудовании · в средствах защиты информации
Примечание: стандарт не распространяется на уязвимости, связанные с утечкой информации по техническим каналам, включая уязвимости электронных компонентов технических средств.
ОЦЕНКА ОПАСНОСТИ: CVSS
CVSS 4.0 — открытая методика FIRST для описания характеристик и количественной оценки технической серьёзности уязвимости. В CVSS 4.0 используются группы метрик Base, Threat, Environmental и Supplemental. CVSS не является полной оценкой риска и не предсказывает вероятность эксплуатации. Спецификация и калькулятор: first.org/cvss
CVSS v2.0 (устаревшая версия)
Низкая (Low) 0.0–3.9 · Средняя (Medium) 4.0–6.9 · Высокая (High) 7.0–10.0
CVSS v3.x / v4.0
None 0.0 · Low 0.1–3.9 · Medium 4.0–6.9 · High 7.0–8.9 · Critical 9.0–10.0
Категории обозначают диапазоны итогового балла CVSS и не означают фиксированный вид доступа, последствий или техники эксплуатации.
EPSS
EPSS — ежедневно обновляемая модель FIRST, оценивающая вероятность того, что для опубликованной CVE в следующие 30 дней будет наблюдаться активность эксплуатации в реальных условиях (in the wild). EPSS не учитывает последствия для конкретной организации и не является полной оценкой риска. Наблюдаемая активность означает попытку эксплуатации, а не обязательно успешную атаку. Источник: first.org/epss/model. Модель: сбор информации об уязвимостях; сбор данных об активности эксплуатации; обучение модели; оптимизация; ежедневные оценки на следующие 30 дней для каждого CVE.
ИЗВЕСТНАЯ / ВПЕРВЫЕ ВЫЯВЛЕННАЯ
Известная уязвимость — уязвимость, опубликованная в общедоступных источниках с описанием соответствующих мер защиты информации, исправлений недостатков или соответствующих обновлений. Впервые выявленная уязвимость — уязвимость, неопубликованная в общедоступных источниках [ГОСТ Р 56545-2015, пп. 3.7, 3.9].
ГДЕ ИСКАТЬ
БДУ ФСТЭК России bdu.fstec.ru · NIST NVD nvd.nist.gov · CNVD cnvd.org.cn · Debian security-tracker.debian.org · Ubuntu CVE ubuntu.com/security/cves · Red Hat CVE Database access.redhat.com/security/security-updates/cve · CISA KEV cisa.gov/known-exploited-vulnerabilities-catalog · Exploit-DB exploit-db.com · Каталог Сканер-ВС vulnerabilities.etecs.ru
ПУТЬ УЯЗВИМОСТИ — данные за 2023 год, медианные значения; интервалы — от вехи «Назначен идентификатор»: внесена в базу — 34 дня · эксплойт — 47/48 дней (Exploit-DB / GitHub PoC) · стала популярной — 62 дня
УЯЗВИМОСТЬ НУЛЕВОГО ДНЯИЗВЕСТНАЯ УЯЗВИМОСТЬ
Уязвимость
обнаружена
Назначен
идентификатор
Эксплойт
нулевого дня
Исправлена
Опубликован бюллетень /
Внесена в базу
Эксплойт
Стала
популярной
Слайд 02 · Серия РБПО
РБПО
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ГОСТ Р 56939-
2016
заменён ГОСТ Р 56939-2024
«3.2 безопасное программное обеспечение: Программное обеспечение, разработанное с использованием совокупности мер, направленных на предотвращение появления и устранение уязвимостей программы».
ГОСТ Р 56939-
2024
действующая редакция
«3.1 безопасное программное обеспечение: Программное обеспечение, разработанное в ходе реализации совокупности процессов (мер), направленных на предотвращение появления и устранение недостатков программы».

НЕДОСТАТОК ПРОГРАММЫ · ГОСТ Р 56939-2024, п. 3.8

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

Понятие расширено: процессы РБПО направлены на предотвращение появления и устранение недостатков программы;
уязвимость программы является одним из видов таких недостатков.

Слайд 03 · Серия РБПО
25
ПРОЦЕССОВ РБПО — С 20 ДЕКАБРЯ 2024 ГОДА
ГОСТ Р 56939-2024 — действующая редакция стандарта
АВТОРСКАЯ УЧЕБНАЯ СХЕМА. ГОСТ Р 56939-2024 не классифицирует процессы как «сквозные» и «проектные» и не устанавливает показанные стрелками связи с анализом и трансформацией программ. Названия процессов сокращены для слайда: ПО — программное обеспечение, РБПО — разработка безопасного программного обеспечения.
выделенные процессы — 13 NEWпроцессы, не имевшие отдельного прямого соответствия в редакции 2016 года по авторскому сопоставлению (№ 5.1, 5.15, 5.16, 5.17, 5.25); обозначение не является классификацией ГОСТ Р 56939-2024 «Анализ и трансформация программ: технологические требования» — стрелки ровно к 12 процессам: ко всем выделенным, КРОМЕ № 5.2
Слайд 04 · Серия РБПО

Сертификация процессов безопасной разработки ПО средств защиты информации

ПРИКАЗ
ФСТЭК РОССИИ
№ 240
от 1 декабря 2023 г.
в редакции приказа ФСТЭК России
от 30.06.2025 № 230
зарегистрирован Минюстом России 18.09.2025, рег. № 83573; официально опубликован 19.09.2025

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

утверждён приказом ФСТЭК России от 1 декабря 2023 г. № 240 (зарегистрирован Минюстом России 16.04.2024, рег. № 77896)
Область Порядка № 240: процессы проектирования и производства ПО СЗИ, предназначенных для защиты сведений, составляющих государственную тайну, или иной охраняемой законом информации ограниченного доступа (п. 1 Порядка)

ГОСТ Р 56939-2024
процессы оцениваются на соответствие требованиям; ссылки актуализированы приказом от 30.06.2025 № 230 (ранее — ГОСТ Р 56939-2016)
01.06.2024
приказ № 240 вступил в силу
30.09.2025
изменения по приказу № 230 вступили в силу
ЧТО ИЗМЕНИЛ ПРИКАЗ ФСТЭК РОССИИ ОТ 30.06.2025 № 230
  • актуализирована версия стандарта: оценка процессов — по ГОСТ Р 56939-2024 (приказ Росстандарта от 24.10.2024 № 1504-ст);
  • введён п. 5.1 — требования к содержанию руководства по безопасной разработке ПО (область действия, цели, процессы, роли, регламенты по пп. 5.1–5.25, внутренние проверки, улучшение процессов);
  • сертификация — на материально-технической базе изготовителя на территории Российской Федерации, с доступом органа по сертификации к среде сборки и разработки ПО (п. 18);
  • проверяется наличие средств композиционного, статического и динамического анализа ПО (пп. 5.8–5.12, 5.16, 5.18, 5.19 требований) (п. 19);
  • сертификат соответствия выдаётся на область действия, указанную в руководстве по безопасной разработке ПО, и на срок, указанный в заявке, но не более чем на 5 лет (п. 30).

ПРАКТИЧЕСКОЕ СЛЕДСТВИЕ СЕРТИФИКАЦИИ

Согласно п. 71.1 Положения о системе сертификации СЗИ, утверждённого приказом ФСТЭК России от 03.04.2018 № 55, заявитель — разработчик СЗИ, имеющий сертификат соответствия процедур безопасной разработки ПО требованиям национальных стандартов в области защиты информации, при внесении изменений в сертифицированное СЗИ проводит испытания

САМОСТОЯТЕЛЬНО ИЛИ С ПРИВЛЕЧЕНИЕМ ИСПЫТАТЕЛЬНОЙ ЛАБОРАТОРИИ
Слайд 05 · Серия РБПО

Требования ГОСТ Р 56939-2024

Национальный стандарт «Защита информации. Разработка безопасного программного обеспечения. Общие требования»

25 ПРОЦЕССОВ,
ОХВАТЫВАЮЩИХ ЖИЗНЕННЫЙ ЦИКЛ ПО
ОСОБЕННОСТИ СТАНДАРТА
  • содержит описание 25 процессов разработки безопасного ПО;
  • не привязывает процессы к одной модели жизненного цикла;
  • адресован разработчикам и производителям ПО, а также организациям, оценивающим соответствие процессов;
  • позволяет определить применимый набор процессов с учётом НПА, стандартов, ТЗ и иных документов;
  • учитывает специфику, масштаб и сложность ПО.

устанавливает требования к разработке ПО, включая ПО в составе программно-аппаратных комплексов (ПАК) и автоматизированных систем (АС); требований к разработке аппаратной части конечного изделия напрямую не устанавливает, но учитывает аппаратные и программно-аппаратные средства среды сборки и разработки.

Конкретная совокупность процессов определяется применимыми нормативными правовыми актами, стандартами, техническим заданием и иными документами. Если установлено требование соответствия ГОСТ Р 56939-2024, обязательны все требования стандарта, кроме сформулированных с использованием слов «рекомендуется» и «может» (пп. 4.7, 4.14–4.15).

Стандарт устанавливает общие требования к работам по созданию безопасного ПО и устранению выявленных недостатков, в том числе уязвимостей, и описывает 25 процессов (пп. 5.1–5.25); процессы соотносятся с этапами принятой модели жизненного цикла с учётом специфики, масштаба и сложности ПО. Названия процессов сокращены: ПО — программное обеспечение, РБПО — разработка безопасного программного обеспечения.

Слайд 06 · Серия РБПО

Можно ли сделать систему без уязвимостей?

ТРИ АКСИОМЫ, ПРИПИСЫВАЕМЫЕ М. Р. ШУРЕ-БУРЕ
1

В каждой программе есть ошибка.

2

Если в программе нет ошибок, значит, в исходном алгоритме есть ошибка.

3

Если ни в программе, ни в алгоритме ошибок нет, то такая программа никому не нужна.

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

ФАКТОРЫ, ВЛИЯЮЩИЕ НА НАЛИЧИЕ УЯЗВИМОСТЕЙ
ПРО СУТЬ, ПРО СМЫСЛЫ ИБ, ЗИ — все наши действия направлены на: Учебное обобщение; ср. цели разработки безопасного ПО — ГОСТ Р 56939-2024, п. 4.1

ИСКЛЮЧИТЬ

появление уязвимостей при создании систем, ПО
Меры: внедрение РБПО

УСТРАНИТЬ

уже имеющиеся уязвимости
Меры: внедрение РБПО у разработчиков; у эксплуатантов — организационные и технические меры управления уязвимостями (Vulnerability Management, VM) — см. справа

НЕ ДОПУСТИТЬ

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

Разработка безопасного ПО — это навык.

Авторская учебная серия посвящена направлению «Разработка безопасного программного обеспечения»: нормативная база ФСТЭК России, требования ГОСТ Р 56939-2024 и практика внедрения 25 процессов РБПО. Материал предназначен для разработчиков, специалистов по ИБ и руководителей команд.

АВТОРСКАЯ УЧЕБНАЯ СЕРИЯ · РБПО
Нормативные сведения проверены по состоянию на 26.07.2026.