О чём вы узнаете из этой статьи

• Почему безопасная разработка стала обязательной дисциплиной для бизнеса?
• Как западная модель SDL трансформировалась в российскую практику РБПО?
  • Международный стандарт безопасной разработки (SDL)
• Что такое Software Supply Chain Security - защита цепочки поставок ПО (SSCS)?
  • Почему это важно
  • Как защищают цепочку поставок
  • Как SSCS дополняет SDL
• Что такое РБПО - российский стандарт безопасной разработки
  • Основные принципы РБПО
  • Нормативная база
  • Практика внедрения
  • Особенности российского подхода
• Что влияет на развитие РБПО в России
  • Почему DevSecOps становится нормой и почему не все компании готовы?
  • Как растут кибератаки и почему это усложняет безопасность разработки?
• Какие стандарты и ГОСТы формируют нормативную базу РБПО в России?
  • Почему это важно
• Как начать: минимальный и оптимальный набор мер
  • Какие шаги нужны малому и среднему бизнесу, чтобы внедрить РБПО?
  • Как крупным компаниям и КИИ построить зрелый процесс безопасной разработки?
• Что важнее для РБПО — процессы или компоненты?
  • Традиционный подход vs. подход Axiom JDK
• Как международные компании модернизируют инфраструктуру безопасной разработки?

Почему безопасная разработка стала обязательной дисциплиной для бизнеса?

За последние три года тема безопасной разработки из узкой дисциплины превратилась в стратегический приоритет. В России этот тренд усилился под давлением регуляторных требований — ГОСТ Р 57580, приказов ФСТЭК, отраслевых стандартов безопасности для финансовых и государственных ИТ-систем.

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

В 2025 году безопасная разработка перестала быть темой для энтузиастов. После серии громких инцидентов (Аэрофлот, Винлаб и др) и усиления требований регуляторов тема РБПО разработка безопасного ПО, (Secure SDLC - Secure Software Development Life Cycle) стала обязательным пунктом повестки для IT-директоров, банков, интеграторов и госсектора. Но при этом — остаётся одной из самых «недофинансированных» областей: ряд компаний компании до сих пор внедряют безопасность (архитектра, политики, инструменты) в процесс разработки несистемно и иногда лишь ради прохождения аудита.

Почему так? И какие тренды определяют развитие безопасной разработки в России сегодня — разберём по шагам.

Как западная модель SDL трансформировалась в российскую практику РБПО?

Международный стандарт безопасной разработки (SDL)

Secure Development Lifecycle (SDL) — это подход, при котором безопасность внедряется во все этапы жизненного цикла разработки программного обеспечения.

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

Как отмечает PVS-Studio, Secure SDLC добавляет к стандартному циклу меры по обнаружению и устранению уязвимостей на ранних стадиях, снижая риски в эксплуатации.

На практике это включает формализацию требований безопасности, моделирование угроз, использование инструментов SAST (SAST (Static Application Security Testing — статическое тестирование безопасности приложений.) и SCA (Software Composition Analysis — композиционный анализ состава программного обеспечения.

Международная модель SDL (например, Microsoft SDL) задаёт обязательные проверки и инструменты для каждой фазы — от требований до выпуска.

Применение SDL снижает количество уязвимостей и стоимость их исправления благодаря «сдвигу влево» — интеграции безопасности на ранних этапах разработки.

Главная идея SDL проста:

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

Основные практики SDL:

• моделирование угроз (Threat Modeling);
• безопасное программирование (Secure Coding Guidelines);
• анализ уязвимостей (SAST/DAST);
• контроль зависимостей и стороннего кода;
• проверка безопасности перед релизом;
• управление патчами и обновлениями.

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

Что такое Software Supply Chain Security - защита цепочки поставок ПО (SSCS)?

Software Supply Chain Security (SSCS) — это подход к защите всей цепочки поставки программного обеспечения: кода, зависимостей и инфраструктуры сборки. Он отвечает на главный вопрос: Можно ли доверять тому, из чего и где собрано наше ПО?

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

Почему это важно

По данным Kaspersky, атаки на цепочку поставок происходят, когда злоумышленники скомпрометируют доверенного поставщика и внедрят вредоносный код в обновления. Известные примеры: SolarWinds Orion, 3CX Phone, XZ Utils. По прогнозу Microsoft, в этом году году почти половина компаний столкнётся с подобными атаками.

Как защищают цепочку поставок

SSCS включает контроль зависимостей, подпись артефактов и использование доверенных репозиториев. Рекомендации Microsoft: анализ рисков компонентов, внедрение модели угроз, безопасное программирование, своевременные патчи и ревью кода. Google дополняет подход фреймворком SLSA, который обеспечивает верификацию артефактов и ведение SBOM (Software Bill of Materials) - перечня всех используемых компонентов.

Как SSCS дополняет SDL

Если SDL защищает код, то SSCS — инфраструктуру и зависимости вокруг него. SSCS обеспечивает доверенную сборку (Trusted Build Infrastructure) и целостность поставок, предотвращая инъекции уязвимостей «снаружи».

Основные практики SSCS включают:

• контроль исходных кодов и зависимостей (SCA, доверенные репозитории);
• защиту CI/CD-процессов и агентов сборки;
• подпись и верификацию артефактов;
• формирование и хранение SBOM (Software Bill of Materials);
• использование платформ доверенной сборки (Trusted Build Infrastructure);
• контроль безопасности реестров и контейнеров.

Что такое РБПО - российский стандарт безопасной разработки

РБПО (Разработка безопасного программного обеспечения) - российский стандарт, объединяющий международные подходы SDL (Secure Development Lifecycle) и SSCS (Software Supply Chain Security), адаптированные к требованиям законодательства и инфраструктуры отечественных компаний.

Основные принципы РБПО

РБПО охватывает весь жизненный цикл ПО:

• безопасное проектирование и моделирование угроз - на основе принципов SDL;
• безопасные сборки, контроль зависимостей и артефактов - в духе SSCS;
• эксплуатацию и поддержку с устранением уязвимостей (LTS, CVE mitigation).

Нормативная база

Новый ГОСТ Р 56939-2024 (заменил ГОСТ Р 56939-2016) определяет 25 процессов безопасной разработки: от планирования и обучения до управления конфигурацией и инцидентами (ФСТЭК РФ).

ФСТЭК проводит сертификацию процессов разработки по этому стандарту, закрепляя РБПО как обязательный элемент защиты ИТ-инфраструктуры.

Практика внедрения

Согласно исследованию Positive Technologies, 42 % российских компаний уже используют SAST/DAST, аудит кода и обновление зависимостей.

На практике РБПО включает:

• анализ угроз и формализацию требований безопасности;
• использование статического и составного анализа кода (SAST, SCA);
• тестирование безопасности (пенетрационные тесты, fuzzing);
• Устранение уязвимостей и формирование SBOM.

Особенности российского подхода

Особенность РБПО — наличие регуляторной базы и требования применять сертифицированные инструменты и доверенные платформы (например, отечественные JDK, репозитории и СКЗИ). Таким образом, РБПО сочетает практики SDL и SSCS с обязательным подтверждением соответствия ГОСТ и ФСТЭК, превращая безопасность в формализованный элемент жизненного цикла разработки.

Что влияет на развитие РБПО в России

Почему DevSecOps становится нормой и почему не все компании готовы?

В крупных технологичных компаниях и банках в 2024–2025 годах активно внедряются практики DevSecOps - то есть интеграции безопасности в конвейеры CI/CD. Инструменты SAST, SCA, DAST, управление SBOM, контроль секретов, политика Infrastructure-as-Code - всё это постепенно становится стандартом для корпоративных SDLC.

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

Как растут кибератаки и почему это усложняет безопасность разработки?

Сложность атак на бизнес-системы за последний год выросла кратно. Киберпреступники начали использовать автоматизацию и искусственный интеллект: фишинговые кампании, подбор паролей, автоматический анализ уязвимостей в CI/CD и зависимостях теперь поставлены «на поток». Уровень профессионализма атакующих вырос, и это подталкивает к «сдвигу влево» (shift-left security), то есть внедрению защитных мер уже на этапе разработки, а не после релиза.

Российские компании находятся на разных уровнях зрелости безопасной разработки:

• Крупные банки и госкорпорации выстраивают контуры РБПО в связке с DevSecOps, создают доверенную инфраструктуру или “Фермы разработки” (Trusted Development Farms) с автоматизированными проверками зависимостей, CI/CD с политиками безопасности и централизованным управлением инцидентами.
• Средний бизнес чаще ограничивается точечными мерами: сканирование зависимостей и ручные code review.
• Малые команды нередко воспринимают безопасность как «вещь, которую делают после релиза», что делает внедрение РБПО формальным и запоздалым.

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

Какие стандарты и ГОСТы формируют нормативную базу РБПО в России?

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

Дополнительно к этому используются:

• ГОСТ Р 71452‑2024 «Требования к функциональной безопасности и защите системы контроля промышленной автоматизации (IACS) на протяжении жизненного цикла» охватывает вопросы функциональной безопасности и защиты информации на всех этапах цикла.
• Приказы ФСТЭК России, которые регламентируют сертификацию процессов разработки ПО, использование сертифицированных средств защиты информации и организацию внутреннего ИБ-контроля.
• Международные стандарты, адаптированные в России, например, ГОСТ Р ИСО/МЭК 27034‑1:2015 «Разработка безопасного приложений», используются как методологическая база для разработки безопасного ПО.
• Методические рекомендации банка или отраслевые методички, где разработчику предписано демонстрировать безопасность на всех этапах жизненного цикла.

Почему это важно

• ГОСТ R 56939-2024 вводит обязательную безопасность всего жизненного цикла разработки, не как опцию. (ksb-soft.ru)
• Стандарты задают единую основу, по которой проверяются процессы разработки (РБПО) и обеспечивается соответствие корпоративной и государственной ИБ-политике.
• Нормативная база трансформирует формальный подход «делаем, чтобы пройти аудит», и переводит фокус на системную, управляемую разработку безопасного ПО.

Как начать: минимальный и оптимальный набор мер

Безопасная разработка (РБПО, российский аналог Secure Development Lifecycle / SDL) — это не столько «проект по безопасности», сколько управляемый цикл, встроенный в ежедневные процессы команды. Ниже практические ориентиры, которые позволяют выстроить РБПО поэтапно и избежать хаотичных инвестиций.

Какие шаги нужны малому и среднему бизнесу, чтобы внедрить РБПО?

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

• Контроль зависимостей: внедрить SCA-анализ и использовать доверенные источники. Например, Axiom REPO гарантирует юридическую чистоту и прозрачность артефактов.
• Безопасная среда исполнения: использовать проверенный JDK без известных уязвимостей (например, последние версии Axiom JDK),
• Управление секретами и MFA: включить двухфакторную аутентификацию для CI/CD.
• Документирование состава продукта (SBOM): составлять Software Bill of Materials для каждого релиза, SBOM - это паспорт вашего ПО, который делает цепочку поставки прозрачной и управляемой.
• Минимальный план реагирования на инциденты: хотя бы раз в квартал проводить учения и обновлять план.

Как крупным компаниям и КИИ построить зрелый процесс безопасной разработки?

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

• Построить процесс РБПО (Secure SDLC), включающий моделирование угроз, код-ревью, SAST/DAST и ручное тестирование. На этапах проектирования и архитектуры надёжной базой служит Axiom REPO (доверенные компоненты) и Axiom JDK - безопасная среда разработки и исполнения Java-приложений
• Безопасный кодинг и фреймворки - использование Open IDE и Axiom Spring снижает вероятность уязвимостей в кодовой базе и поддерживает долгосрочную совместимость.
• Контроль безопасности сборки и развёртывания - Axiom Runtime Containers, благодаря своей легкости и сокращению поверхности атаки обеспечивают защищённую инфраструктуру CI/CD и изолированную среду исполнения.
• Патч-менеджмент и мониторинг - Axiom JDK/Axiom JDK Certified и Libercat/Libercat Certified обеспечивают регулярные обновления и CVE-патчи среды исполнения и серверов приложений без нарушения стабильности приложений.
• Обучение и аудит - проводить регулярные тренинги, bug bounty и документировать соответствие требованиям ГОСТ, ФСТЭК, OWASP

Безопасная разработка не возникает за один релиз - это стратегия, в которой компоненты платформы Axiom JDK и и целый комплекс мер позволяют поэтапно модернизировать инфраструктуру разработки, не нарушая работу бизнеса.

Что важнее для РБПО — процессы или компоненты?

Современная разработка опирается не на код «с нуля», а на готовые библиотеки, фреймворки и бинарные зависимости. Разработчики часто приносят эти компоненты в контур разработки, не задумываясь о том, что именно внутри. Между тем, именно бинарные артефакты становятся источником недокументированных возможностей, вредоносных вставок и уязвимостей.

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

Традиционный подход vs. подход Axiom JDK

Zero-day безопасность по умолчанию

В то время как большинство решений, которые уже применяются для реализации подхода РБПО на рынке сосредоточено на обнаружении уязвимостей (SAST, DAST, SBOM, SIEM, и др.), экосистема Axiom JDK создаётся вокруг предотвращения — чтобы уязвимые или непроверенные компоненты не попадали в разработку, а при обнаружении.

Безопасная разработка начинается с доверенных компонентов. Zero-day безопасность — это не реакция, а архитектурное свойство среды разработки.

Как международные компании модернизируют инфраструктуру безопасной разработки?

На глобальном рынке наблюдается тенденция: компании из финансового, телеком- и госсектора всё чаще переходят от реактивной политики безопасности к построению безопасных цепочек поставки - Trusted Build Infrastructure. Например, Red Hat анонсировала решение “Trusted Software Supply Chain”, включающее подпись артефактов, SBOM-интеграцию и проверку происхождения сборки. Google Cloud и Microsoft публикуют наборы инструментов и фреймворков для защиты цепочки поставки ПО. То, что в России называют “РБПО”, за рубежом чаще именуется «Software Supply Chain Security» - и становится обязательным элементом корпоративного комплаенса.

Почему безопасная разработка — это не мода, а долгосрочная стратегия бизнеса?

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

Хотите понять, как встроить РБПО в существующий процесс разработки без потери скорости?

Эксперты Axiom JDK помогут оценить зрелость вашего процесса разработки и предложат практические шаги по интеграции принципов РБПО в текущий цикл.

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

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