Нефтегазовая отрасль постепенно переходит от отдельных цифровых проектов к общей инфраструктуре, в которой можно описывать используемые решения, сравнивать их, тиражировать между компаниями и проверять безопасность промышленного ПО. На byteoilgas_conf 2026 этот переход показали сразу на нескольких уровнях.
«Компьютерра» разобралась, как нефтегазовая отрасль описывает собственный ИТ-ландшафт, зачем промышленному ПО понадобился отдельный подход к безопасной разработке и что показал первый практический тест такого конвейера. Подробнее читайте на сайте.
От цифровой карты к общей инфраструктуре
Конференция byteoilgas_conf 2026 началась с анонса цифровой версии ИТ-ландшафта нефтегазовой отрасли. По представленным данным, зрелое отечественное ПО закрывает 92,8% из 125 функциональных процессов отрасли. В каталоге насчитывается 639 карточек решений, 336 из них доступны для внешнего тиражирования, а 77 уже используются как минимум двумя компаниями в отраслевых центрах компетенций.
Вместе с каталогом появляется единый способ описывать состояние программного обеспечения, видеть уже реализованные решения и отслеживать их дальнейшее распространение. Участники конференции отдельно говорили о необходимости постоянно обновлять данные, поскольку отраслевой набор технологий быстро меняется.
В представленном ландшафте отдельно выделены решения с использованием искусственного интеллекта. В каталоге таких продуктов 91. Следующий этап, о котором говорили на конференции, связан уже не только с расширением набора отечественного ПО, но и с цифровыми двойниками, ИИ, мультиагентными системами, автономизацией и общими требованиями к обмену данными.
Максут Шадаев, министр цифрового развития, связи и массовых коммуникаций Российской Федерации, связал эту работу с развитием российского рынка промышленного ПО. Он отметил, что показатель около 90% замещения зарубежных решений является хорошим результатом, но одновременно важна способность разработанных продуктов распространяться между компаниями.
«Делайте так, чтобы эти решения действительно тиражировались. Это очень правильная метрика».
Максут Шадаев, министр цифрового развития, связи и массовых коммуникаций Российской Федерации
Министр также говорил о цифровых двойниках как о фактически новом стандарте работы и о межотраслевой кооперации. По его словам, разработки нефтегазовых компаний уже используются как основа для решений в других секторах. При этом сам ИТ-ландшафт, по его оценке, будет быстро меняться.
Отдельно Шадаев остановился на барьерах для внедрения ИИ. Он сообщил, что подготовлен план внедрения искусственного интеллекта по отраслям и что государство готово корректировать регулирование там, где оно мешает развитию технологий. Безопасная разработка в этом контексте тоже должна стать частью общей инфраструктуры. Он сказал, что готов обсудить с регуляторами возможность обязательного применения отраслевого стандарта безопасной разработки.
В качестве следующего инструмента поддержки он назвал новый отбор проектов с использованием промышленного ИИ. По его словам, заявки принимаются до 19 октября, а объем государственного софинансирования может составлять до 80% стоимости таких проектов.
Еще одна важная особенность — желание использовать одно и то же решение сразу в нескольких компаниях. Поэтому важно понимать не только, как оно работает, но и насколько безопасно его разрабатывают. Именно этому была посвящена открытая сессия «Инфраструктура отраслевого доверия: от рекомендаций по безопасной разработке — к практике применения».
От рекомендаций к работающему конвейеру
Годом ранее участники Консорциума технологической независимости индустриального ПО подготовили рекомендации по безопасной разработке. Они охватывают весь жизненный цикл программного обеспечения — от проектирования до эксплуатации. На этот раз участники перешли от рекомендаций к практике и показали, как эти подходы можно встроить непосредственно в процесс разработки.
Максим Карзаев, директор программ по технологической реализации цифровой трансформации нефтегазовой отрасли «Газпром нефти», напомнил, что рекомендации разрабатывались совместно девятью нефтегазовыми компаниями, отраслевыми экспертами и технологическими партнерами. Одним из результатов этой работы стал конвейер для проверки программного кода. Для первого практического теста выбрали Prime — промышленную систему обработки сейсмических данных «Сейсмотек». Это большой программный комплекс, который развивается уже много лет. В него входят более десяти интерактивных приложений и сотни вычислительных модулей, поэтому здесь одновременно работают компоненты, созданные недавно, и код, которому уже 10–15 лет.
Такой код невозможно рассматривать как единый новый продукт, который можно один раз проверить перед выпуском. За время его существования меняются архитектура компьютеров, операционные системы, компиляторы и языки программирования. Поэтому безопасность приходится поддерживать вместе с самим продуктом.
Дмитрий Мосяков, генеральный директор «Сейсмотек», отмечал, что компания и до пилота регулярно проверяла свой код. Ценность проекта они увидели в дополнительной экспертизе со стороны участников консорциума и возможности посмотреть на систему с другой стороны.
Как работает конвейер
Пилотный конвейер объединил несколько инструментов. В его состав вошли статический анализатор кода Positive Technologies и единый центр безопасной разработки приложений. Система сначала выявляет потенциальные проблемы, после чего срабатывания проходят дополнительную проверку с использованием ML-триажа (приоритизация и маршрутизация входящего потока данных) или экспертами.
На пилоте было выявлено 172 срабатывания. Часть из них прошла автоматическую сортировку, после чего эксперты вручную проверили результаты и определили, какие проблемы действительно требуют дальнейшей работы. Важным результатом стало не само количество найденных срабатываний, а возможность сократить объем ручной работы специалистов по безопасности.
Для разработчика такой подход меняет саму точку входа в безопасную разработку. Ему не обязательно каждый раз привлекать большое количество экспертов для первичного анализа. Автоматизированный инструмент может убрать часть информационного шума, а специалисты подключаются там, где требуется более глубокая проверка.
При этом полностью автоматизировать процесс участники дискуссии не предлагали. Экспертная проверка остается необходимой, поскольку срабатывание анализатора еще не означает подтвержденную уязвимость. Важно установить, действительно ли проблему можно эксплуатировать и какое влияние она может оказать на конкретную систему.
Отдельно говорили о взаимодействии между разработчиками, внутренними командами безопасности и специалистами конвейера. Такой обмен позволяет не просто исправлять найденные ошибки, но и передавать разработчикам знания о том, почему конкретная конструкция оказалась небезопасной.
Для промышленного ПО это особенно важно. Проверять нужно не только сам исходный код, но и возможные последствия обнаруженной проблемы внутри реального технологического контура.
Почему одного финального аудита недостаточно
В дискуссии также обсудили, что конвейер должен становиться частью обычного цикла разработки, а не разовой процедурой перед выпуском продукта.
Такой подход отличается от классической проверки, когда безопасники подключаются в конце проекта. Если анализировать код регулярно, потенциальные проблемы можно обнаруживать раньше, пока их исправление не требует масштабной переделки уже работающей системы.
При этом участники рассматривали конвейер как дополнительный инструмент к существующим требованиям и регуляторным процедурам. Речь не идет о замене обязательных норм. Отраслевые рекомендации задают более широкий набор практик, которые разработчики и заказчики могут совместно применять при создании промышленного ПО.
В этом смысле сама дискуссия постепенно перешла от вопроса о конкретном анализаторе к вопросу о стандартизации. Участники обсуждали, что стандартом может быть не только документ с требованиями к конечному продукту, но и договоренность о том, как именно отрасль разрабатывает, тестирует и проверяет программное обеспечение.
Николай Кузнецов, генеральный директор ИНТИ, предложил рассматривать такие договоренности как своего рода общий уровень требований. Регуляторные нормы задают обязательный минимум, а отраслевые практики могут формировать более высокий уровень, который компании принимают совместно.
Максим Карзаев связал это с понятием отраслевого доверия. Если заказчики, разработчики и технологические компании договорились о единых правилах, проверках и подходах к совместимости, результаты такой работы проще использовать в разных проектах и организациях.
Следующий уровень — работа с масштабом
Вопрос масштабирования возник и в контексте самого конвейера. Объем программного кода растет, одновременно увеличивается количество потенциальных уязвимостей. В такой ситуации одной экспертной команды недостаточно, чтобы вручную разбирать все срабатывания.
Поэтому участники отдельно обсуждали использование ML для первичной обработки результатов анализа. В пилоте модель показала сопоставимый с экспертами результат на своей задаче. Это не отменяет участия специалистов, но позволяет направлять их время на те случаи, где действительно требуется дополнительная экспертиза.
Для промышленного ПО возникает и еще одна задача — оценка влияния уязвимости на конкретный объект. Потенциальная проблема в коде не всегда означает одинаковый риск для разных систем. Поэтому в будущем к анализу безопасности потребуется добавлять контекст эксплуатации и моделирование возможных последствий.
Тут также появляется связь с цифровыми двойниками. Они нужны не только для производственных расчетов и оптимизации процессов, но и потенциально могут помочь оценивать, как обнаруженная проблема влияет на реальный технологический контур.
Получается единая цепочка. Сначала отрасль описывает, какие решения и технологии уже существуют. Затем формирует общие требования к их разработке. После этого требования превращаются в инструменты, которые можно встроить в производственный процесс. Следующий шаг — сделать эти инструменты регулярными и распространить их на большее количество разработчиков и продуктов.
Что меняется вместе с ИИ
Отдельный блок обсуждения был связан с искусственным интеллектом. Увеличение объема кода и ускорение разработки с помощью больших языковых моделей и агентных инструментов одновременно создают новые возможности и увеличивают нагрузку на системы безопасности.
Если разработка ускоряется, прежний подход, при котором проверка выполняется вручную на отдельных этапах, становится менее удобным. Автоматизация анализа и ML-триаж в этом случае нужны не столько ради замены специалистов, сколько для того, чтобы скорость проверки соответствовала скорости разработки.
При этом для промышленного ПО сохраняется ограничение, которого нет в обычных корпоративных приложениях. Здесь недостаточно обнаружить техническую ошибку в коде. Необходимо понимать ее место в архитектуре и возможное влияние на технологический процесс.
Поэтому обсуждение безопасности постепенно выходит за пределы отдельных инструментов. Оно касается того, как связать разработку, проверку кода, экспертизу, требования заказчика и контекст эксплуатации в один процесс.
Выводы
По итогам конференции становится понятно, что отрасль постепенно переходит от отдельных ИТ-проектов к общим подходам. Компании хотят не только понимать, какие решения уже существуют и где их можно использовать, но и договариваться о том, как эти решения разрабатывать и проверять.
Пилот с Prime показал, что рекомендации по безопасной разработке можно встроить в реальный рабочий процесс. Автоматический анализ помогает находить потенциальные проблемы, ML-триаж отсекает часть лишних срабатываний, а эксперты разбирают случаи, где требуется более глубокая проверка.
Теперь предстоит проверить этот подход на других продуктах и сделать такие проверки регулярной частью разработки. Тогда отраслевой ИТ-ландшафт будет показывать не только, какие решения есть у компаний, но и насколько готова инфраструктура для их безопасного распространения.
Читайте также:
В Москве прошел первый российский хакатон по Enterprise Vibe Coding
НИУ ВШЭ разработает стандарт обучения по созданию и применению ИИ-агентов