5 неудобных вопросов и честных ответов на них

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

Повод для разговора более чем серьёзный: по данным ФСТЭК, почти половина организаций, относящихся к критически важной информационной инфраструктуре, находятся в критическом состоянии по защите от киберугроз, а в 100 государственных ИТ-системах выявлено свыше 1 200 уязвимостей, большинство из которых известны много лет. В такой ситуации знание регуляторных требований становится не формальностью, а инструментом, который помогает приоритизировать риски, объяснять необходимость обновлений и защищать бизнес от серьёзных потерь.

Содержание

• 5 неудобных вопросов и честных ответов на них
• 1. Разве регуляторика — это не только про юристов и безопасников?
• 2. Я разработчик. Зачем мне знать про КИИ?
• 3. Что будет, если затащить в прод библиотеку или фреймворк без поддержки? Ведь в законе про это ничего не сказано
  • Почему это важно: аналогия с огнетушителем
• 4. У нас DevSecOps. Разве этого недостаточно?
  • DevSecOps эволюционирует и растёт вширь
• 5. Как вести диалог с безопасниками и не сойти с ума?
  • Как безопасники мыслят
• 6. А как объяснить бизнесу, что нужно потратить бюджет на ПО из реестра и заменить недоверенные средства разработки?
• Как донести это до бизнеса
• Что дальше?

1. Разве регуляторика — это не только про юристов и безопасников?

Нет. Современные требования к безопасности ИТ-систем также касаются архитекторов и разработчиков. Выбор JDK, библиотек, CI/CD, облаков, логгирования, способов хранения данных и управления секретами — всё это влияет на безопасность информационных систем, и прямо или косвенно на соответствие требованиям законодательства.

Если вы разрабатываете сервис, обрабатывающий персональные данные, на вашу команду распространяется Федеральный закон №152-ФЗ, согласно которому оператор обязан реализовать технические и организационные меры по защите ПДн (ст. 19). Это касается не только СЗИ, но и архитектуры, хранилищ, логирования, доступа к API.

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

• Федеральный закон № 187-ФЗ — обязывает планировать, разрабатывать и внедрять меры по обеспечению безопасности значимых объектов критической информационной инфраструктуры (ЗОКИИ). В частности — исключить неконтролируемое воздействие на технические средства, которое может нарушить или остановить работу объекта.
• Указ Президента № 250 — предписывает использовать только российское ПО, включённое в реестр российского ПО (Минцифры). С 1 января 2025 года запрещается применять средства защиты информации иностранного происхождения и сервисы ИБ из недружественных стран. Даже open-source считается иностранным, если его нет в реестре.
• Приказ ФСТЭК № 239 (п. 11.2 (з)) — устанавливает меры по защите при взаимодействии ЗОКИИ с другими объектами КИИ, ИС, АСУ или сетями связи. Если проектируется собственное ПО (включая СЗИ), его необходимо разрабатывать по стандартам безопасной разработки.
• ГОСТ Р 56939-2024 «Разработка безопасного программного обеспечения» — ориентирован на команды разработки. Регламентирует:
  • управление зависимостями (включая open-source),
  • использование статического анализа кода (SAST),
  • проектирование с учётом угроз (Threat Modeling),
  • работу с секретами, журналами и уязвимостями.
• ГОСТ Р 57580.1-2017 (для финансового сектора) — рекомендует использовать ПО из доверенных источников, с известным происхождением, а также применять методы безопасной разработки.

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

Зачем разработчику разбираться и понимать регуляторику?

Это:

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

2. Я разработчик. Зачем мне знать про КИИ?

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

• обрабатывает персональные или финансовые данные,
• логирует события безопасности,
• участвует в аутентификации,
• крутится в банке, госсекторе, промышленности, на транспорте или в телекоме,

то вы уже потенциально внутри объекта критической информационной инфраструктуры (КИИ).

Закон № 187-ФЗ (ст. 2, п. 1) определяет КИИ как ИС и АС, критичные для интересов государства. Даже если вы не видите свой сервис в этом определении, то регулятор может увидеть.

Что требуют законы и стандарты

• Указ Президента № 250 — только ПО из реестра российского ПО Минцифры. С 1 января 2025 г. запрещено использовать средства защиты информации иностранного происхождения и сервисы ИБ из недружественных стран. Даже open-source считается иностранным, если его нет в реестре.
• 187-ФЗ (ст. 4.2, 4.3) — безопасность КИИ должна быть непрерывной и комплексной, приоритет — предотвращение атак.
• Приказ ФСТЭК № 239 (прил. 1, п. XIV) — ПО должно иметь регламенты и процедуры обновлений, получать их только из доверенных источников и устранять уязвимости в ходе сопровождения.
• ГОСТ Р 57580.1-2017 (п. 4.5) — для финансового сектора:
  • контроль целостности ПО и настроек,
  • проверка сигнатурных баз и источников обновлений,
  • защита на всех этапах жизненного цикла.
• ГОСТ Р 56939-2024 — для команд разработки:
  • управление уязвимостями не только в приложении, но и в инструментах разработки,
  • статический анализ (SAST, п. 3.18),
  • управление конфигурацией (п. 3.19),
  • учёт уязвимостей (п. 3.20),
  • функциональное тестирование (п. 3.21),
  • фаззинг (п. 3.22).

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

Разработчик — это архитектор доверия. Вы выбираете JDK, фреймворки, брокеры сообщений, БД и библиотеки. Если они:

• не сопровождаются (например, OpenJDK 8 без патчей),
• не проверяются (например, Log4j без SAST-аудита),
• тянут зависимости из интернета без контроля,

то вы строите КИИ на зыбком фундаменте.

Формально отвечает оператор КИИ (обычно замгендиректора по безопасности). Но если баг был в известной CVE, а уязвимая библиотека добавлена вами в pom.xml, и тикет «пофиксим позже» пылится в баг-трекере — ваша команда легко окажется в круге внутренних разбирательств.

Проверьте свою версию JDK
на известные уязвимости
в нашем CVE-сканере

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

Перейти в CVE-сканер

Вывод: КИИ — это не про «где-то там». Это может быть ваш обычный Java-сервис. Использование неподдерживаемой среды нарушает не только «дух» закона, но и его требования по сопровождению и доверию.

3. Что будет, если затащить в прод библиотеку или фреймворк без поддержки? Ведь в законе про это ничего не сказано

Формально вы будете правы, в законе не написано, что «нельзя использовать log4j 1.x» или «запрещено применять JDK без сопровождения», «вы больше не можете разрабатывать на SpringBoot 2.7»

Но закон формулирует требования не к конкретным библиотекам, а к обеспечению безопасности объекта.

Если ваш компонент (например, библиотека или JDK):

• не получает обновлений,
• содержит известные уязвимости,
• не сопровождается вендором,

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

Что говорят нормы:

• Приказ ФСТЭК № 239, ст. 4, п. 39: «Применяемые в значимом объекте программные и программно-аппаратные средства, в том числе средства защиты информации, должны быть обеспечены гарантийной и (или) технической поддержкой».

• Постановление Правительства № 21 (про импортозамещение): При выборе ПО для госорганов и значимых объектов КИИ в первую очередь использовать решения из реестра российского ПО. Если в реестре аналога нет — допускается открытое ПО, но при условии сопровождения и контроля.

• Приказ ФСТЭК № 117 (для ГИС) и Положение ЦБ РФ об операционной надёжности: Программные компоненты не должны иметь актуальных уязвимостей и должны поддерживаться в актуальном состоянии.

Это относится не только к JDK, но и ко всем зависимостям — логгерам, ORM, HTTP-клиентам, фреймворкам.

Почему это важно: аналогия с огнетушителем

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

Так же и с библиотекой без поддержки. Она может годами работать без проблем. А потом:
CVE → эксплойт → утечка → проверка → штраф.

Пример из практики: Log4Shell

📆 Декабрь 2021. В библиотеке Log4j 2 обнаружена критическая уязвимость (CVE-2021-44228). Она позволяет удалённо исполнять произвольный код на сервере.
Сотни российских компаний оказались под ударом — особенно те, кто использовал устаревшую Log4j 1.x, которая на тот момент не поддерживалась уже более 5 лет.

Что произошло:

• Сервисы останавливали вручную.
• Меняли логгеры в десятках микросервисов.
• Писали отчёты для регуляторов.
• Запускали аудит, закупали антивирусные шлюзы.
• В ряде случаев были дисциплинарные меры.

Регулятор у вас не будет спрашивать: «А почему вы выбрали log4j?». Он спросит:

• Где описание угроз?
• Где подтверждение сопровождения компонентов?
• Когда и кем была выявлена и закрыта уязвимость?

Если у вас нет ответов, это трактуется как необеспечение защиты КИИ, а это уже нарушение закона.

Вывод:

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

Писать код — хорошо. Писать безопасный, сопровождаемый код — обязанность.

Что использовать в России

Чтобы снизить риски и упростить работу с зависимостями, используйте доверенные инструменты. Axiom Repo — это российский сервис доверенных Java-библиотек, соответствующий требованиям регуляторов.

Что умеет Axiom Repo:

• Проверяет JAR-файлы на известные уязвимости (CVE, включая критические).
• Уведомляет о новых уязвимостях в уже используемых зависимостях.
• Позволяет использовать только проверенные и сопровождаемые библиотеки.

С Axiom Repo вы знаете, что у вас в проде, и можете доказать это любому аудитору.

4. У нас DevSecOps. Разве этого недостаточно?

DevSecOps — это не лицензия на игнорирование регуляторов. Это методология. И она работает ровно настолько, насколько безопасны те инструменты, на которых вы её построили.

Пример:
Вы настроили Jenkins, но не обновляете плагины.
Вы используете устаревший alpine:3.10 в Docker.
Ваш JDK — без патчей и CVE-аудита.
Поздравляем: у вас DevInsecureOps.

DevSecOps эволюционирует и растёт вширь

Раньше DevSecOps сводился к встроенным в пайплайн проверкам: SAST, DAST, секретам, уязвимостям в Docker-образах. Но времена изменились. Классический “знак бесконечность” (CODE → RUN) больше не охватывает всех рисков.

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

• Требования регуляторов: 152-ФЗ, 187-ФЗ, ГОСТ 56939, ГОСТ 57580.1.
• Защиту цепочек поставок: контроль зависимостей, SBOM, подпись артефактов.
• Secure by Design: безопасность закладывается не в Fix, а уже в Design.
• Защищённые среды исполнения: доверенные JDK, сертифицированные компоненты, контролируемые сборки.
• Центры компетенций и стратегии внедрения РБПО: экспертиза, обучение, методологии.
  Безопасность ИИ и LLM-компонентов: от аудита сгенерированного кода до оценки поведенческих рисков.

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

DevSecOps ≠ защита, если ваши инструменты разработки уязвимы.
DevSecOps ≠ регуляторное соответствие, если вы не ведёте журнал инцидентов, как требует ФСТЭК.
DevSecOps — это только фундамент. А надстройка — это архитектура, процессы, сопровождение, документация и политика доверия.

Вывод:

DevSecOps — это уже не «галочка» в CI. Это объединяющее ядро архитектуры защищённой разработки, которое теперь включает требования регуляторов, ГОСТов и будущих стандартов доверенной среды исполнения.
И если ваш стек не поддерживается, не контролируется и не имеет документации, никакой DevSecOps не спасёт.

Безопасность по умолчанию начинается не с пайплайна, а с проектирования.

5. Как вести диалог с безопасниками и не сойти с ума?

Любой разработчик хотя бы раз сталкивался с ситуацией, когда всё готово к релизу, но появляется ИБ с фразой:

– А где модель угроз?

Или хуже:

– Почему в продакшене библиотека без проверки по SBOM?

Хочется сказать: “Мы тут код пишем, а вы мешаете!”.
Но правда в том, что безопасники не мешают. Они минимизируют риски. В том числе и вашей работы.

Как безопасники мыслят

Они не про «запретить всё», они про «минимизировать ущерб в случае проблемы». Они мыслят категориями:

• доказуемости (можете ли вы подтвердить, что компонент безопасен),
• контролируемости (можно ли его обновить, откуда он взят),
• предсказуемости (знаете ли вы, как он поведёт себя в бою).

Если вы думаете: «Это просто бюрократия», то на самом деле, это попытка сделать бизнес устойчивым и предсказуемым.

Когда можно договариваться

Есть ситуации, когда вы можете (и должны!) вести диалог:

Безопасники любят аргументы и прозрачность, а не: «На Stack Overflow все так делают».

Когда уступок не будет

Есть вещи, по которым диалога не будет. И это нормально:

• ❌ Продукт обрабатывает ПДн → должен соответствовать 152-ФЗ, независимо от удобства.
• ❌ Выход в прод в КИИ → только с сопровождаемым стеком (приказ ФСТЭК №235).
• ❌ Отсутствие журналирования, сертифицированных СЗИ, плана реагирования → нельзя.

Это не потому что «так решили безопасники». Это потому что:

• иначе прилетит штраф от регулятора,
• или прекратится аккредитация системы,
• или прилетит аудит от партнёров или заказчиков.

Почему разработчику важно в этом разбираться

Понимание требований ИБ и регуляторов — это:

• не “лишняя работа”, а защита от внезапных инцидентов;
• не “про регулятора”, а про предсказуемость в вашей практике;
• не “про таблички”, а про то, чтобы ваш код не стал точкой входа для атакующего.

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

Безопасность — это не то, что мешает писать код. Это то, что позволяет вашему коду жить в проде без страха.

Вывод

Если вы знаете, что именно хотят безопасники (ГОСТ, ФСТЭК, 152-ФЗ), и умеете предлагать компромиссы, а не просто ждать, пока “прокатит”, вы не просто разработчик, вы — инженер, который умеет строить прозрачные и устойчивые системы.

И такие инженеры ценятся. Даже безопасниками.

6. А как объяснить бизнесу, что нужно потратить бюджет на ПО из реестра и заменить недоверенные средства разработки?

Если вы когда-либо слышали от бизнеса: «А зачем платить, если всё и так работает?» или “Зачем платить за open-source с минимальными доработками, даже если он из реестра?”.

Вы не одиноки. Но у этой “экономии” есть цена. И нередко она измеряется десятками миллионов рублей, репутацией и остановкой бизнеса.

Это не просто «устарело». Это — неконтролируемо

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

• нет SLA и поддержки,
• нет обновлений по CVE (а значит, дыры могут жить в проде месяцами),
• нет возможности пройти аудит или согласование у регуляторов.

Такое ПО или компоненты называется недоверенным. И оно может “взорваться” в самый неприятный момент. Собственно об этом и тот ГОСТ, который сейчас в проекте.

Примеры из практики

Случай Аэрофлота и сбой летом 2025 года

По сообщениям СМИ, летом 2025 года у «Аэрофлота» произошёл масштабный сбой ИТ-систем: десятки рейсов были отменены, в аэропортах скопились пассажиры, были сорваны отпуски и командировки.

Позже некая хакерская группировка взяла на себя ответственность за инцидент и заявила, что получила доступ к нескольким виртуальным серверам, где использовалась система виртуализации с несертифицированным JDK. Формально основное ПО виртуализации было внесено в реестр, но в его составе использовались компоненты (в том числе среда исполнения), которые не были сертифицированы и не проходили должную проверку на доверенность.

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

• из чего это ПО состоит (состав SBOM),
• на чём оно исполняется (JDK, криптобиблиотеки, loggers),
• и какие компоненты могут быть уязвимы или не соответствуют требованиям регулятора.

Итог: отменённые рейсы, испорченные поездки, репутационный урон, материальные потери.

Как донести это до бизнеса

Говорите в терминах бизнеса:

• Не «версия JDK устарела», а: «У нас нет гарантий, что система запустится после следующего обновления ОС».
  • Не «уязвимость CVE», а: «Через логгер можно получить доступ к данным клиента. Как думаете, что скажет регулятор?»

Ссылайтесь на последствия:

• «Если мы не пройдём ИБ-аудит, то нас отключат от платёжной системы или не дадут участвовать в тендерах».
  • «Переход на ПО из реестра — это не “по желанию”, это требование госконтрактов и 719-ПП».

Покажите масштаб бездействия:

• Срыв релиза или инцидент в проде обходится дороже, чем годовая подписка на поддержку и гарантийное обновление JDK. (дать ссылку на ROI -калькулятор когда будет готов)
  • Если нет поддержки, то в случае сбоя придётся решать всё вручную. Кто будет отвечать ночью?

Вывод

«Работает 10 лет» — это не аргумент, если завтра оно сломается и никто не поможет.
«В реестре и с поддержкой» — это не каприз безопасников, а инструмент устойчивости бизнеса.

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

Что дальше?

• Проверьте, давно ли вы обновляли JDK. Сколько CVE в вашей сборке JDK.
• Скачайте поддерживаемую JDK от Axiom в личном кабинете для разработки или запросите на тест сертифицированную версию для проверки совместимости.
• Запросите комплект корпоративного разработчика, который включает все необходимые инструменты для доверенной разработки на Java, включая Axiom Repo, Axiom Spring.