Безопасность Java в 2026 году: защита JVM, приложений и цепочки поставок программного обеспечения

Java исполнилось 30 лет в 2025 году, но это не значит, что её пора «списывать».

По данным Developer Ecosystem Survey 2025 от JetBrains, Java используют как основной язык 33% профессиональных разработчиков по всему миру: вместе с JavaScript и Python она входит в топ-3.

Согласно индексу TIOBE за август 2026, Java входит в топ-5 самых популярных языков программирования, занимая четвёртое место.

В корпоративной разработке Java ещё популярнее.

Сначала давайте определим основные термины, которые будут использоваться в статье:

• Java — язык программирования и одновременно основа большой программной экосистемы. Когда дальше мы говорим о свойствах самого языка, речь идёт, например, о статической типизации и правилах работы с объектами.
• JVM (Java Virtual Machine) — виртуальная машина, которая загружает и выполняет Java-байткод. Она управляет выполнением программы, памятью и загрузкой классов, проверяет байткод и выполняет ряд рантайм-проверок.
• JDK (Java Development Kit) — комплект для разработки и запуска Java-приложений. В него входят JVM, стандартные библиотеки и инструменты вроде java, javac, jdb, jcmd, jstack и других средств разработки и диагностики.
• РБПО (Разработка Безопасного Программного Обеспечения) — подход, при котором безопасность учитывается на всём жизненном цикле продукта: от требований и проектирования до сборки, выпуска обновлений и устранения найденных уязвимостей. В России требования к таким процессам закреплены в ГОСТ Р 56939-2024.

Области применения Java

Java используется в следующих сферах:

• мобильная разработка (приложения на Android),
• разработка игр (Minecraft),
• работа с Big Data,
• корпоративные приложения (банковские системы,  и пр.),
• облачные технологии и контейнеризация,
• программные средства (NetBeans, IntelliJ IDEA, Eclipse),
• трейдинговые приложения (Murex),
• АСУ ТП (Автоматизированные Системы Управления Технологическим Процессом),
• SCADA (англ. Supervisory Control and Data Acquisition — диспетчерское управление и сбор данных).

Особенно прочно Java закрепилась в энтерпрайзе. Многие корпоративные системы живут годами и даже десятилетиями: меняется инфраструктура, появляются новые сервисы и требования безопасности, а большой объём бизнес-логики продолжает работать на Java. Почему Java?

• Java — один из первых языков, который позволил упростить и ускорить создание приложений.
• В Java развитое API, библиотеки практически для любого типового сценария, инструменты тестирования, профилирования, мониторинга и диагностики, сборщик мусора.
• В Java регулярно выпускаются обновления безопасности. В этом году начался переход на ежемесячный цикл обновлений безопасности (CSPU, Critical Security Patch Update).

Java использует управляемую среду выполнения — виртуальную машину Java. JVM обеспечивает базовую целостность среды выполнения за счёт верификации байткода, типобезопасности, рантайм-проверок операций с данными, контроля доступа при компоновке (linking) и правил загрузки классов. Это позволяет JVM контролировать множество потенциально опасных операций и снижать вероятность появления определённых классов ошибок.

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

Особое внимание уделяется безопасности. Исторически основные обновления безопасности (CPU — Critical Patch Updates) для Java выходили поквартально. В 2026 году компания Oracle начала переход к более частой модели и объявила о движении Java в сторону ежемесячного цикла обновлений безопасности (CSPU — Critical Security Patch Updates).

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

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

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

Что защищает сама Java и JVM

У Java и JVM есть несколько свойств, которые действительно уменьшают вероятность определённых классов ошибок.

Статическая типизация

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

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

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

Управляемая работа с памятью

Java-разработчику обычно не нужно вручную выделять и освобождать память для объектов. Этим занимается JVM и сборщик мусора (GC, Garbage Collector).

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

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

Java-приложение может обращаться к нативной памяти вне кучи, например, при работе с JNI, нативными библиотеками и Foreign Function & Memory API. Такой код требует отдельного внимания, поскольку JVM не может контролировать его так же, как обычные Java-объекты.

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

Верификация байткода

Исходный Java-код компилируется в байткод, который затем выполняет JVM.

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

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

Контроль доступа и модульность

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

В Java для этого используются модификаторы доступа private, protected, public и default (без ключевого слова). JVM учитывает эти ограничения и при связывании классов проверяет, имеет ли вызывающий код право обращаться к соответствующим классам, методам и полям. Это помогает поддерживать границы, заданные структурой программы, и не позволяет произвольно обращаться к закрытым элементам.

Начиная с Java 9 эти возможности дополняет Java Platform Module System (JPMS). Модуль явно определяет зависимости от других модулей и указывает, какие пакеты экспортируются наружу. Пакеты, которые не экспортированы, могут оставаться внутренней частью реализации модуля.

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

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

Криптография и защищённые соединения

Java-платформа предоставляет криптографический фреймворк JCA (Java Cryptography Architecture) и криптографическое расширение — JCE (Java Cryptography Extension), средства работы с сертификатами и ключами, SecureRandom, цифровыми подписями, хешированием и TLS (Transport Layer Security).

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

И здесь мы подходим к важной границе.

Где заканчивается защита JVM

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

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

Ошибки в логике и коде приложения

• Некорректная проверка прав доступа. Приложение проверяет, что пользователь вошёл в систему, но не проверяет, имеет ли он право запрашивать конкретный объект — документ, заказ или профиль другого пользователя. В результате злоумышленник получит доступ к чужим данным или сможет выполнять атаки от имени другого пользователя.
• Небезопасное формирование SQL-запросов. Приложение вставляет данные, контролируемые пользователем, непосредственно в текст SQL-запроса вместо использования параметризованных запросов. Такие данные могут приходить из параметров URL, тела HTTP-запроса, формы или других внешних источников. Это создаёт риск SQL-инъекции: в зависимости от прав приложения к базе злоумышленник может прочитать, изменить или удалить данные либо выполнить другие не предусмотренные разработчиком запросы.
• Неконтролируемые серверные HTTP-запросы. Приложение принимает от пользователя URL для загрузки изображения, проверки ссылки или отправки вебхука и без достаточной проверки передаёт его HTTP-клиенту. Злоумышленник может заставить сервер обратиться не к внешнему ресурсу, а к внутреннему сервису, localhost или другому недоступному ему напрямую адресу. Такой класс уязвимостей называется SSRF (Server-Side Request Forgery). JVM не считает такой запрос ошибочным: с её точки зрения приложение выполняет допустимую сетевую операцию.
• Конфиденциальные данные хранятся непосредственно в исходном коде. Разработчик записал пароль от базы данных или API-токен в Java-класс или конфигурационный файл, который попал в репозиторий. Если пароль или токен станет доступен постороннему через утечку репозитория, опубликованный артефакт или другой канал, то его могут использовать для несанкционированного доступа к базе данных или внешнему сервису. Последствия зависят от прав, которыми обладает скомпрометированная учётная запись.
• Отключена проверка сертификата TLS. TLS защищает данные при передаче между приложением и удалённым сервисом. Если приложение принимает любой сертификат или не проверяет имя узла, то непонятно с каким сервером установлено соединение. В результате атакующий, способный перехватить трафик, может попытаться выдать себя за доверенный сервер, прочитать передаваемые данные или изменить ответ. Такая ситуация связана с риском атаки «человек посередине» (Man-in-the-Middle, MITM).

Риски сторонних зависимостей

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

Атаки на цепочку поставок ПО

• В проект попала подменённая или вредоносная зависимость. Например, злоумышленник скомпрометировал репозиторий или пакет и добился того, что система сборки загрузила изменённую версию библиотеки. Это один из сценариев атаки на цепочку поставок ПО (software supply chain attack). Код приложения при этом может оставаться неизменным, а вредоносный компонент попадёт в продукт во время сборки.
• Готовый артефакт изменили после сборки. Артефакт — это результат сборки, который затем распространяется или развёртывается. Например, JAR-, WAR-файл или контейнерный образ. Если злоумышленник получил возможность изменить его после проверки исходного кода или сборки, то в эксплуатацию может попасть код, которого не было в проверенной версии проекта. Поэтому важно контролировать целостность и происхождение не только исходников, но и готовых артефактов.

Чтобы снизить вероятность атак на цепочку поставок ПО, необходимо проверять все библиотеки и их зависимости. Таких зависимостей могут быть десятки и даже сотни. Проверенные артефакты для вашей цепочки поставок ПО вы можете найти в нашем доверенном репозитории Java-библиотек Axiom Repo.

Именно поэтому безопасность Java-системы нельзя сводить к безопасности самого языка. Следующий уровень защиты — это уже не отдельная функция JVM, а процесс разработки.

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

Для этого используются практики Secure SDLC (Software Development Life Cycle), а в российской нормативной системе — разработка безопасного программного обеспечения, или РБПО. 

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

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

На этапе проектирования

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

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

Описание архитектуры ПО должно включать хотя бы следующее:

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

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

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

Задача этого этапа — обнаружить опасные архитектурные решения до того, как они превратятся в код.

При разработке

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

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

1. Экспертиза исходного кода. В первую очередь для компонентов, составляющих поверхность атаки. Экспертиза нужна для проверки соответствия исходного кода ПО предъявляемым к нему требованиям.
2. Статический анализ, предназначенный для выявления потенциально опасных конструкций и ошибок без выполнения программы.
3. Динамический анализ, призванный обнаружить недостатки и уязвимости в коде в процессе его выполнения.

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

При работе с заимствованными компонентами

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

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

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

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

На практике автоматизировать такую работу помогают SCA-инструменты (Software Composition Analysis), а для описания состава продукта может использоваться SBoM (Software Bill of Materials, спецификация состава программного обеспечения).

При сборке и выпуске

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

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

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

Во время сопровождения

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

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

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

Именно этот последний этап особенно важен для JDK.

РБПО не гарантирует, что в программном обеспечении нет уязвимостей. Задача РБПО — системно уменьшать вероятность появления уязвимостей и дефектов и обеспечивать управляемое устранение проблем после выпуска продукта.

До этого мы рассматривали безопасность самого приложения: механизмы JVM, код, зависимости, сборку и сопровождение. Но у приложения есть ещё один компонент, который также приходится поддерживать на протяжении всего жизненного цикла — это сама JDK.

Разные компании выпускают собственные дистрибутивы JDK на основе проекта с открытым исходным кодом — OpenJDK.

Такие сборки могут регулярно получать исправления и обновления безопасности. Здесь важно разделять “доступность обновлений” и “договорные обязательства перед конкретным пользователем”.

Исходный код OpenJDK распространяется по лицензии GNU GPLv2 с Classpath Exception. Как и многие open source-лицензии, она прямо предусматривает отказ от гарантий, то есть программное обеспечение предоставляется «как есть» (as-is). Лицензия разрешает использовать и изменять код, но сама по себе не устанавливает SLA (Service Level Agreement или Соглашение об уровне предоставления услуги) на техническую поддержку, сроки разбора инцидентов или выпуск исправления для конкретной организации.

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

Если организация эксплуатирует JDK без технической поддержки, то ей необходимо самостоятельно:

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

Здесь иногда используют термин upstream. Так называют исходный проект и ветки разработки, из которых поставщики JDK получают изменения и переносят необходимые исправления в поддерживаемые уже ими версии. Для разработчика же важнее следить не столько за исходным репозиторием OpenJDK, сколько за обновлениями и релизами безопасности именно того дистрибутива JDK, который работает в его инфраструктуре.

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

Для части систем такая модель приемлема. Но требования меняются, если JDK используется в платёжной инфраструктуре, государственной информационной системе (ГИС) или другом критичном сервисе, где длительный простой, задержка с устранением уязвимости или невозможность быстро получить исправление создают существенный риск для организации.

Поэтому важно различать две ситуации: «мы используем JDK, для которой доступны обновления» и «мы используем JDK с определёнными обязательствами по поддержке».

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

Axiom JDK — свободно распространяемая JDK для разработки, обучения, экспериментов и собственных проектов. Для промышленной эксплуатации предназначена Axiom JDK Pro — корпоративный дистрибутив на базе OpenJDK с коммерческой технической поддержкой и SLA. Axiom JDK и Axiom JDK Pro проходят тестирование на соответствие спецификациям Java SE.

Axiom JDK Pro поддерживает LTS-версии Java 8, 11, 17, 21 и 25, текущую версию, а также legacy-версии Java 6 и 7. Для LTS-версий есть долгосрочная поддержка минимум восемь лет, а конкретные сроки закреплены в дорожной карте продукта. Например, коммерческая поддержка Java 17 запланирована до марта 2030 года, Java 21 — до марта 2032-го, Java 25 — до марта 2034-го.

Обновления безопасности выходят регулярно. Основой остаётся квартальный цикл CPU/PSU, синхронизированный с основным циклом обновлений Java. В 2026 году к нему добавились промежуточные CSPU-релизы для более быстрой доставки приоритетных исправлений безопасности.

Для корпоративной эксплуатации важна не только периодичность обновлений, но и ответственность за разбор проблемы. Коммерческая поддержка Axiom JDK предусматривает работу напрямую с инженерами, поддержку 24/7, выпуск обновлений и патчей безопасности и работу с обращениями в рамках SLA.

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

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

Для российского инфраструктурного контура в Axiom JDK Pro также предусмотрена совместимость с отечественными ОС и готовые конфигурации российских TLS-сертификатов Минцифры.

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

В КИИ, ГИС и ИСПДн может быть важно не только то, что JDK регулярно обновляется и сопровождается поставщиком, но и какие механизмы безопасности в ней реализованы и подтверждены ли они в установленном порядке.

Для таких сценариев предназначена Axiom JDK Certified. Сертификат соответствия ФСТЭК России № 4531 удостоверяет, что программное изделие «Среда разработки и исполнения Java Axiom JDK Certified» является программным средством со встроенными средствами защиты от несанкционированного доступа к информации и соответствует требованиям ФСТЭК России по 4 уровню доверия.

Сейчас в сертифицированной линии доступны Java 8, 11, 17 и 21. Для неё также предусмотрены регулярные обновления безопасности и долгосрочное сопровождение. Конкретные сроки для каждой версии указаны в дорожной карте.

Axiom JDK Certified отличается от Axiom JDK Pro не только наличием сертификата. В сертифицированной версии реализованы дополнительные функции и настройки защиты, среди которых:

• Очистка освобождаемой памяти. Сборщики мусора гарантированно очищают память, занимаемую объектом.
• Принудительная верификация class-файлов. Возможность отключить такую проверку исключена.
• Обеспечение независимости экземпляров виртуальных машин.
• Безопасное выполнение интерпретируемого кода.
• Управление доступом к ресурсам, внешним по отношению к виртуальной машине, специальным функциям и классам, доступ к которым регламентируется списком разрешений.
• Контроль целостности исполняемого кода (замкнутая программная среда).
• Регистрация событий безопасности.

Разработка продуктов семейства Axiom JDK ведётся с применением процесса безопасной разработки. Для версии Certified появляется дополнительный контур: изменения в сертифицированном продукте должны проходить предусмотренные процедурой сертификации проверки.

Поэтому эти три варианта решают разные задачи:

• Axiom JDK подходит для разработки, обучения, экспериментов и других сценариев, для которых не требуется корпоративная модель сопровождения.
• Axiom JDK Pro предназначена для промышленной эксплуатации, когда нужны долгосрочный жизненный цикл, регулярные обновления, инженерная поддержка и SLA.
• Axiom JDK Certified применяется, когда требования к конкретной информационной системе предполагают использование сертифицированного средства защиты с подтверждённым уровнем доверия. Продукт может использоваться в том числе при построении ГИС, объектов КИИ, ИСПДн и АСУ ТП.

Выводы

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

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

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

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

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

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

Именно поэтому безопасность Java нельзя свести к вопросу «безопасен ли сам язык». Защищать приходится всю систему: архитектуру и код приложения, сторонние компоненты, процесс сборки и поставки, среду выполнения и последующее сопровождение ПО в эксплуатации.