Как ORS выстраивает безопасную разработку в условиях требований ЗОКИИ

2026-10-02 18:03 Технологии

Автор Александр Лукашов, руководитель Департамента разработки продуктов ORS

Каждая строчка кода, которую использует ваша авиакомпания через продукты ORS, проходит через цепочку контроля — от источника библиотеки до финального сканирования на уязвимости. Это не абстрактная декларация о качестве, а конкретный технологический процесс, который ORS выстраивает в связи с переходом под требования ЗОКИИ. В этой статье Александр Лукашов, отвечающий за разработку продуктов в команде ORS, выделяет четыре взаимосвязанные цели, которые объединяет термин «безопасная разработка», и поясняет, какую пользу от нашего перехода на новые стандарты получат клиенты.

Почему это стало необходимостью именно сейчас

ORS переходит под требования ЗОКИИ — законодательства о защите объектов критической информационной инфраструктуры. Регламенты ФСТЭК в этом статусе обязывают нашу компанию выстроить формализованный процесс безопасной разработки и не полагаться на разрозненные практики отдельных команд. Ниже опишу четыре цели проекта.

Независимость и непрерывность процесса разработки. Разработка должна продолжаться независимо от доступности интернета, блокировок или сбоев доступа к внешним источникам и сторонним библиотекам. Для этого все необходимые артефакты консолидируются внутри организации — это узкий, но значимый элемент общей устойчивости бизнеса (business continuity).

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

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

Обеспечение качества кода. Четвёртая цель — менее декларируемая, но не менее важная: контроль качества собственной программной базы через регулярное сканирование на соответствие лучшим практикам разработки и поиск уязвимостей в коде, написанном командой ORS. Безопасность и качество кода здесь рассматриваются как два связанных, но отдельных направления работы.

Смотрите также: Главные направления развития авиационных технологий в России и компании ORS - интервью с генеральным директором ORS Александром Сизинцевым

Какими техническими средствами это реализовано

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

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

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

Проверка качества собственного кода. Здесь мы применяем комбинацию инструментов GitLab и двух методологий — SAST (static application security testing, статический анализ кода) и DAST (dynamic application security testing, динамический анализ приложений). Это позволяет постоянно контролировать, что код соответствует принятым стандартам безопасности и не содержит потенциально опасных участков.

Читайте также:

Что это даёт клиентам ORS

Реализация процесса безопасной разработки даёт три ключевых эффекта.

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

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

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

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

Постоянный мониторинг уязвимостей сторонних компонентов и собственного кода снижает риск взлома, утечек данных и простоев инфраструктуры, на которой строится обслуживание пассажиров. А формализованный процесс контроля качества кода означает, что каждый релиз продуктов ORS — будь то PSS, DCS или другие модули — проходит проверку на соответствие лучшим практикам безопасности, прежде чем попасть в рабочий контур клиента. Иными словами, безопасная разработка ORS работает на устойчивость бизнеса каждого клиента — так же, как резервные контуры, о которых мы рассказывали ранее.