Зачем Java-разработчику знать регуляторику. Часть 1

Среди российских разработчиков по-прежнему распространено такое мнение, что регуляторные требования — это дело начальства, юристов и безопасников. Кажется, что безопасность где-то там, на уровне политик, ГОСТов и страшных приказов ФСТЭК. А задача программистов — разрабатывать фичи, выбирать фреймворки, делать красиво и быстро. Несмотря на то, что это мнение не подтверждено исследованиями, на практике оно встречается достаточно часто.

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

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

Если вы, как разработчик, понимаете, какие требования действуют в вашей отрасли, чем доверенные компоненты отличаются от «качаемого с Maven Central», и умеете это объяснить — вы становитесь инженером, а не просто исполнителем. Вам проще договариваться с безопасниками, аргументировать выбор стека с архитектором и не бояться новых требований.

Содержание:

Зачем эта статья
Основные определения
Топ-6 нормативных документов, которые должен знать Java-разработчик
Сводная таблица нормативных документов
Заключение
Как мы помогаем соответствовать требованиям

Зачем эта статья

Это не запугивающий материал про штрафы и «проверку от ФСТЭК». Это практическая шпаргалка для разработчика:

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

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

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

Основные определения

1. ГИС — Государственные информационные системы

Нормативный документ: Приказ ФСТЭК России от 11 февраля 2013 г. № 17 (в ред. приказа от 28.08.2024 № 27)

Что регулирует:
Требования по защите информации, не составляющей государственную тайну, но содержащейся в государственных информационных системах (например, сайт Госуслуги, сайт системы документооборота и т. п.).

2. КИИ — Критическая информационная инфраструктура

Нормативный документ: Приказ ФСТЭК России от 25 декабря 2017 г. № 239 (ред 28.08.2024)

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

энергосистемы,
транспортные сети,
банки,
телеком,
промышленность и др.

3. ИСПДн — Информационные системы персональных данных

Нормативный документ: Приказ ФСТЭК России от 18 февраля 2013 г. № 21 (в ред. приказа от 23.03.2017 № 49)

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

Примеры:

CRM с данными клиентов,
онлайн-магазин с телефонами/адресами,
HR-системы с анкетами сотрудников.

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

Нормативный документ: ГОСТ Р 56939-2024 «Процессы безопасной разработки ПО»

Что это значит для разработчиков:

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

выбирать поддерживаемое ПО,
применять сертифицированные СЗИ (в нужных случаях),
вести учёт уязвимостей,
выполнять мероприятия по защите данных.

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

Топ-6 нормативных документов, которые должен знать Java-разработчик

Дисклеймер: законы и приказы напрямую не говорят: «Разработчик обязан использовать сертифицированный JDK и запрещено использовать Spring Boot без обновлений». Однако закон требует, чтобы всё программное обеспечение было контролируемым, обновляемым, безопасным и происходило из доверенных источников. Да, это про разработчиков и их pom.xml.

1. 152-ФЗ «О персональных данных»

152-ФЗ «О персональных данных»

Обязателен, если вы обрабатываете ПДн.

Что требует:

Применять технические и организационные меры защиты (ст. 19).
Использовать сертифицированные СЗИ при наличии ПДн.
Хранить ПДн на территории РФ (ст. 18.1).

Что это значит для разработчиков: Если ваше приложение работает с логинами, e-mail или телефоном, то вы уже внутри 152-ФЗ.

2. 187-ФЗ «О безопасности критической информационной инфраструктуры (КИИ)»

187-ФЗ «О безопасности критической информационной инфраструктуры (КИИ)»

Обязателен для госсектора, банков, телекома, транспорта, энергетики и других отраслей, относящихся к КИИ.

Что требует:

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

Запрет на иностранное ПО:

Согласно редакции закона и подзаконных актов (в т.ч. Указу № 250), с 1 января 2025 года запрещается использование иностранного ПО на объектах КИИ, если существует аналогичное решение российского происхождения (внесённое в реестр ПО Минцифры).

Что это значит для разработчиков:

Если вы разрабатываете или сопровождаете ПО для критических отраслей (Госуслуги, банки, телеком, промышленность), требования КИИ касаются и вашего кода. Даже ваш микросервис логирования или CRM-модуль может попасть в периметр.

Выбор фреймворка, брокера сообщений, СУБД или JDK — это не просто архитектура. Это вопрос соответствия закону. Использование неподдерживаемых библиотек, западных JDK, средств логирования или open-source инструментов без регистрации в реестре может привести к нарушению закона и проверкам со стороны ФСТЭК/ФСБ.

3. Указ Президента РФ № 250 от 01.05.2022

Указ Президента РФ № 250 от 01.05.2022

О дополнительных мерах по обеспечению информационной безопасности РФ

Обязателен для госорганов, операторов КИИ, госкомпаний и стратегических организаций.

Что требует:

Использовать только российское ПО, включённое в реестр российского ПО (единый реестр Минцифры).
С 1 января 2025 года запрещено использовать средства защиты информации (СЗИ) иностранного происхождения и сервисы ИБ из недружественных стран.
Даже свободно распространяемое ПО считается иностранным, если его нет в реестре.

Что считается российским ПО:

Внесено в реестр российского ПО.
Правообладатель — юрлицо, зарегистрированное в РФ.
Не подконтрольно иностранным юрисдикциям.

Что это значит для разработчиков:

Если вы работаете с КИИ, банками, ритейлом или инфраструктурными проектами, то любой стек, JDK, фреймворк, логгер, даже Maven-плагин, не входящий в реестр, считается иностранным. Чтобы соответствовать требованиям к средствам защиты информации, нужно мигрировать на российские сборки (например, Axiom JDK Certified, Libercat Certified). Даже привычные Java-библиотеки могут быть заблокированы проверкой, если они не контролируются или не поддерживаются. Это значит, что и использовать их будет нельзя по закону.

4. Приказ ФСТЭК № 239

Приказ ФСТЭК № 239 «Об утверждении Требований к обеспечению безопасности значимых объектов критической информационной инфраструктуры»

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

Что требует:

Все ПО, используемое в разработке и эксплуатации, должно быть контролируемым: сопровождаться, обновляться, проверяться на уязвимости.
В системе должны быть реализованы:
- логирование,
- управление доступом,
- резервное копирование,
- сопровождение и реагирование на инциденты.
В рамках значимых объектов КИИ объектами защиты считаются:
- программные средства, включая прикладное, системное и микропрограммное ПО;
- архитектура и конфигурация системы;
- информация, включая управляющие и измерительные данные (в АСУ ТП);
- средства защиты информации;
- инфраструктура: серверы, АРМ, линии связи, телеком-оборудование и др.

Что это значит для разработчиков:

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

OpenJDK без поддержки = неконтролируемое ПО. Вы должны уметь ответить на вопросы аудитора:

Кто поставил JDK?
Как давно были обновления?
Есть ли план сопровождения?
Проверялась ли уязвимость CVE-XXXX-YYYY?

Лучший путь — использовать JDK из реестра российского ПО или JDK, поставляемый доверенным российским вендором, с публичной дорожной картой, поддержкой и гарантией соответствия требованиям ФСТЭК.

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

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

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

5. Приказ ФСБ России №117 от 18.03.2025

Приказ ФСБ России №117 от 18.03.2025 «Об утверждении Требований к обеспечению безопасности информации в государственных информационных системах и иных информационных системах при использовании средств криптографической защиты информации (СКЗИ)»

Обязателен:

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

Что требует:

Применять только сертифицированные СКЗИ (п. 3). Отражать необходимость использования криптографии в модели угроз, ТЗ и проектной документации (п. 2).
Учитывать влияние окружения (библиотек, ОС, драйверов, виртуализации) на безопасность криптосредств (п. 5).
Выбирать класс СКЗИ (КС1/КС2/КС3/КВ/КА) в зависимости от уровня значимости информации (пп. 7–18, прил. 1).
Исключать недокументированные возможности и уязвимости прикладного ПО, которые могут использоваться для обхода СКЗИ (п. 15–16).

Что это значит для разработчиков:

Если ваша система работает с криптографией (TLS, ЭЦП, VPN, базы с шифрованием), то используйте только сертифицированные библиотеки и модули.
Проектируйте систему так, чтобы она была совместима с сертифицированными СКЗИ (например, встроенный TLS не подойдёт, вам нужен сертифицированный модуль).
Следите, чтобы зависимости (JDK, драйверы, фреймворки) не вносили уязвимости, которые могут снизить класс защиты СКЗИ.
Любые криптобиблиотеки (OpenSSL, BouncyCastle и аналоги) должны иметь сертифицированные версии или российские аналоги (КриптоПро, VipNet и др.).

6. ГОСТ Р 56939-2024 «Процессы безопасной разработки ПО»

ГОСТ Р 56939-2024 «Процессы безопасной разработки ПО»

Рекомендателен, но часто становится обязательным в рамках сертификации и тендеров.

Что требует:

Управление уязвимостями не только в коде, но и в среде исполнения.
Наличие SBOM, контроль зависимостей, проверка исходного кода (SAST), документированная сборка.

Что это значит для разработчиков:
Фактически описывает весь процесс РБПО (SDL). Если вы используете неаудируемую библиотеку, рантайм без проверки или CI/CD без логов, ваша система не проходит по ГОСТу.

7. ГОСТ Р 57580.1-2017 «Безопасность финансовых организаций»

ГОСТ Р 57580.1-2017 «Безопасность финансовых организаций»

Рекомендателен, но в финтехе часто становится корпоративным стандартом.

Что требует (обобщённо):

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

Что это значит для разработчиков:
Это ГОСТ о «чистой» поставке и сопровождении. Библиотека, пришедшая из непроверенного репозитория, или из GitHub без анализа считается нарушением.

Сводная таблица нормативных документов

Для удобства мы свели всё в таблицу:

Документ	Обязателен?	Кому обязателен	Что требует от разработчика
152-ФЗ	Да	Все, кто обрабатывает ПДн	Безопасная архитектура, хранение в РФ, сертификация
187-ФЗ	Да	КИИ, банки, госы	Надёжный стек, устойчивость, отказоустойчивость
Указ № 250	Да	КИИ, госсектор, госкомпании	Использование только российского ПО
Приказ №239	Да	КИИ	Контролируемое ПО, обновления, уязвимости
Приказ №117	Да	ГИС и системы, где используется криптография	Применение только сертифицированных СКЗИ
ГОСТ 56939-2024	Рекомендован	КИИ, госсектор, критсистемы	Secure SDLC, управление зависимостями, SBOM
ГОСТ 57580.1-2017	Рекомендован	Финсектор, крупные компании	Доверенное ПО, контроль происхождения

Заключение

Мы рассмотрели 7 основных нормативных документов, которые напрямую или косвенно влияют на работу Java-разработчиков в России. Они задают рамки, в которых нужно проектировать, разрабатывать и сопровождать безопасное программное обеспечение: от хранения персональных данных и выбора компонентов (в том числе JDK или сервера приложений) до использования криптографии и контроля зависимостей.

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

Как мы помогаем соответствовать требованиям

Чтобы помочь разработчикам и компаниям выполнять эти требования на практике, мы в Axiom JDK предлагаем:

Сканер CVE — проверка вашей сборки JDK на известные уязвимости.
Axiom Repo — доверенный репозиторий Java-библиотек с проверкой происхождения и целостности.
Axiom JDK Certified — для проектов на Java, где нужен контроль и соответствие требованиям регулятора.
Libercat Certified — отечественная альтернатива популярным серверам-приложений, с поддержкой Jakarta EE и обновлениями. Для систем, которым необходимо соответствовать требованиям ЦБ или ГИС.

В следующей части статьи мы разберём, как эти законы и стандарты применяются на практике. Расскажем о топ-5 реальных вопросов разработчиков о регуляторике и что это значит для вашего кода, pom.xml и CI/CD.

Роман Карпов

Директор по стратегии и развитию технологий Axiom JDK