Фото: пресс-служба
С 2022 года аэропортовая отрасль столкнулась с масштабной перестройкой ИТ-ландшафта. Уход иностранных поставщиков, прекращение технической поддержки, необходимость замены устаревающего программного обеспечения (ПО) сделали импортозамещение текущей производственной задачей. Так, в 2025 году российские аэропорты, по данным исследования компании Online Reservation System (ORS), сосредоточились на обновлении программного и аппаратного обеспечения, автоматизации производственных процессов и импортозамещении. В эти направления инвестировали 67, 61 и 53% респондентов опроса ORS.
Аэропорт для пассажира обычно выглядит как последовательность понятных действий: регистрация, досмотр, ожидание рейса, посадка, получение багажа. За этими привычными процессами стоит множество взаимосвязанных цифровых систем, от которых зависит работа всех служб. Сбой в одной из них может затронуть смежные процессы и потребовать оперативной перестройки работы аэропорта.
Инфраструктура аэропорта устроена так, чтобы пассажир по возможности не замечал возникающих локальных проблем. Но чем теснее связаны между собой цифровые сервисы, тем выше требования к надежности ПО, на котором они работают. Особенно в ситуации, когда часть программ приходится создавать и поддерживать самостоятельно.
На практике это непростая задача: аэропорты используют специализированные системы, а специалистов, которые разбираются как в авиационной специфике, так и в разработке соответствующего ПО, не так много. Внешняя разработка может занять много времени и стоить дорого, поэтому часть задач берут на себя внутренние ИТ-команды. Чем больше собственного программного кода появляется в инфраструктуре, тем важнее проверять его безопасность еще до запуска.
В нашем аэропорту команда разработки около трех лет использовала одно решение в рамках практики DevSecOps (от англ. Development, Security, Operations — подход, при котором требования безопасности учитываются на всех этапах создания ПО: разработки, безопасности и эксплуатации. — РБК Отрасли). По мере роста объема разработки и расширения ИТ‑команды возникла потребность в более функциональном инструменте для проверки кода методами как статистического, так и динамического анализа софта.
В качестве решения мы интегрировали в процесс разработки платформу для анализа безопасности приложений от компании «Солар»: статистические и динамические инструменты встроили прямо в рабочую среду программистов. Это позволяет разработчику выявлять потенциальные уязвимости и ошибки на раннем этапе — еще в момент написания кода, а не на стадии финального тестирования или перед выпуском системы.
Такой подход называется Shift-Left (в переводе с англ. «сдвиг влево». — РБК Отрасли). Он позволяет существенно экономить ресурсы. Уязвимости, найденные поздно, могут остановить проект или потребовать дорогой переработки. Удобнее, чтобы программисты сами исправляли ошибки в процессе написания кода, чем перерабатывать готовый продукт, особенно для инфраструктуры аэропорта.
Внедрение платформы Solar appScreener позволило сократить число дефектов, которые доходят до тестовой и промышленной среды, повысить качество выпускаемого ПО и снизить нагрузку на команду информационной безопасности (ИБ).
Отдельная задача в работе аэропорта — контроль за сторонними программными компонентами. Современные приложения редко создаются с нуля: разработчики используют готовые библиотеки с открытым исходным кодом (open source), чтобы не тратить время на реализацию стандартных функций. Это ускоряет работу, но увеличивает риски безопасности.
Для инфраструктуры аэропорта важно понимать, из каких именно компонентов состоит каждое приложение, насколько они актуальны и не содержат ли уязвимостей. Так, модуль OSA (от англ. Open Source Analysis — анализирует компоненты open source, используемые в ПО. — РБК Отрасли) в составе платформы наших партнеров автоматически формирует перечень таких зависимостей и сверяет их с базами известных уязвимостей, предотвращая инциденты еще на этапе написания кода. Кроме того, инструмент анализирует лицензионную чистоту библиотек и исключает юридические риски, которые могли бы привести к блокировке эксплуатации готового решения или судебным искам.
Такая практика соответствует требованиям стандарта ГОСТ Р 56939-2024, который с 2024 года обязывает бизнес внедрять инструменты композиционного анализа для проверки всех заимствованных компонентов перед их использованием в инфраструктуре.
Еще один вызов — дефицит специалистов в сфере AppSec (от англ. application security — безопасность приложений. — РБК Отрасли). По данным hh.ru, две трети российских работодателей ощущают нехватку ИБ-специалистов. На этом фоне DevSecOps- и AppSec-специалисты остаются среди наиболее востребованных: в первом полугодии 2026 года на них пришлось 9,3% профильных вакансий. В условиях растущего объема разработки небольшая команда ИБ физически не может вручную анализировать каждую строку кода и разбирать все типовые замечания. Автоматизация рутинных проверок силами разработчиков позволила снизить нагрузку профильных специалистов и освободить их для решения сложных архитектурных задач, требующих высокой квалификации.
Последнее обновление внедренной нами платформы умеет проверять несколько файлов одновременно, используя все доступные вычислительные ресурсы сервера. Администратор может регулировать количество задействованных процессорных ядер, чтобы оптимизировать нагрузку и ускорить проверку. Это позволяет ИТ-команде быстрее получать результаты анализа и обрабатывать несколько проектов параллельно.
Все заметнее в разработке влияние генеративного искусственного интеллекта (ИИ). Инструменты, которые помогают писать код по текстовому запросу, действительно могут ускорить создание отдельных фрагментов программы. При этом код, созданный с помощью ИИ, требует такой же, а в отдельных случаях и более внимательной проверки: модель может предложить неработающее решение, использовать небезопасный подход или не учесть особенности конкретной системы.
В Пулково мы внимательно проверяем такой код с точки зрения ИБ. Последнее слово в любом случае должно оставаться за человеком: остановка работы аэропорта из-за ошибки, допущенной или не замеченной ИИ, недопустима. Эта проблема становится все более острой, когда ИИ работает на стороне атакующих: он сокращает в десятки раз «окно» для реализации уязвимостей — с 63 дней в 2019 году до нескольких часов в 2025 году.
ИИ при этом может быть полезен в качестве инструмента поддержки. Результаты более глубокого анализа, разбор обнаруженных уязвимостей и подготовку вариантов исправлений можно передавать специализированному ИИ-плагину, развернутому в закрытом контуре компании. Это позволяет не передавать исходный код во внешние облачные сервисы и снизить риск утечки данных.
В ближайшие годы развитие ИТ в аэропортах будет во многом зависеть от того, насколько быстро российский рынок сможет предложить зрелые решения для узкоспециализированных задач и специалистов с необходимыми компетенциями. До этого момента собственная разработка останется для многих операторов практической необходимостью.