Почему DevSecOps не приживается в АСУ ТП и MES – и как его адаптировать

Внедрение DevSecOps стало нормой для ИТ-разработки, однако в промышленных системах этот подход сталкивается с серьезными ограничениями. Приоритеты в этих средах – надежность, непрерывность работы и соблюдение отраслевых стандартов – изначально противоречат динамике CI/CD и гибкости DevOps. Дополнительные препятствия создают закрытые контуры, устаревшие технологии и фрагментированная структура ответственности.

Артем Пузанков, руководитель группы внедрения практик безопасной разработки Positive Technologies, эксперт программного комитета конференции byteoilgas_conf

DevSecOps не приживается в АСУ ТП и MES по классическим ИТ-лекалам, поскольку в этих системах действуют совсем иные приоритеты и ограничения. На первом месте здесь стоят надежность, непрерывность работы и соответствие отраслевым регламентам (например, ГОСТ/ISO 62443), что плохо сочетается с гибкими и динамичными DevOps-подходами.

Можно выделить несколько проблем:

1. Коробочные решения от вендоров. На предприятия часто поставляются готовые промышленные комплексы – с предустановленным ПО, операционной системой, конфигурацией и полным циклом поддержки. В такой модели у заказчика просто нет процесса разработки, а значит, и DevSecOps неприменим.
2. Конфликт между скоростью и стабильностью. MES и АСУ ТП обновляются редко – по строгому расписанию и только после обширного тестирования. Автоматические деплои и частые коммиты воспринимаются здесь как угроза стабильности.
3. Отсутствие CI/CD-инфраструктуры. Многие промышленные среды изолированы: без интернета, с ограничениями на установку агентов, сканеров и даже сборочных инструментов. Это делает невозможным полноценное внедрение CI/CD.
4. Разделение ответственности. В промышленной среде инженер по автоматизации, технолог, специалист по ИБ и IT-разработчик – это разные роли с разными приоритетами. DevSecOps требует объединения этих компетенций, чего на практике почти никогда не происходит.
5. Устаревшие технологии. ПО может быть написано на специфичных или не поддерживаемых языках, а также работать на операционных системах, несовместимых с современным инструментарием. Это серьезно ограничивает возможность использования DevSecOps-практик.

CI/CD в промышленности – лишний риск?

Мнение о том, что CI/CD в промышленности – это лишний риск, частично справедливо, но слишком однобоко. В традиционной АСУ ТП-среде любое изменение действительно может повлиять на безопасность, выпуск продукции или даже вызвать простой линии. Поэтому классическое понимание CI/CD здесь выглядит как угроза. Но проблема кроется не в самом подходе, а в его неприспособленности к специфическим требованиям OT-среды.

Как я уже отмечал, одна из ключевых причин – отсутствие полноценной CI/CD-инфраструктуры. Промышленные среды часто изолированы от интернета, работают на специфичном оборудовании и не позволяют устанавливать стандартные агенты, сканеры или сборочные инструменты. Даже при желании автоматизировать процессы это оказывается крайне сложно, а порой и вовсе невозможно из-за технических ограничений среды и требований регуляторов.

Тем не менее, адаптированные пайплайны все же возможны. Они должны быть изолированы, включать ручные контрольные точки, офлайн-сканирование и обязательную валидацию итогового артефакта. Такой CI/CD скорее напоминает автоматизированный контроль изменений, чем классическую DevOps-практику, но он позволяет сохранить контроль, прослеживаемость и безопасность изменений.

Shift Left в промышленности возможен и даже необходим, но проявляется иначе. Речь идет не о юнит-тестах и раннем сканировании кода, а о моделировании угроз, оценке рисков и анализе безопасности еще на стадии проектирования производственных линий, выборе архитектуры и компонентов. Уже при разработке технологических схем можно закладывать требования к изоляции сетей, сегментированию зон, резервированию и безопасным способам обновления.

Пайплайн, помимо прочего, можно и нужно использовать как инструмент согласования интересов ИТ, ИБ и АСУ, особенно в средах, где высока цена ошибки и важно формализовать процесс внедрения изменений. При правильной архитектуре CI/CD-пайплайн превращается не просто в средство доставки, а в механизм контроля, валидации и взаимодействия между командами.

Мне доводилось выстраивать процессы безопасной разработки в компании, создающей ПО для энергетического сектора. Однако внедрение GitOps в SCADA-системах или на уровне контроллеров ПЛК остается большой редкостью. Подобные кейсы возможны в организациях на стыке ИТ и OT, которые активно инвестируют в цифровизацию и готовы адаптировать современные практики под требования промышленной среды.

Какие технологические риски нужно выявить до продакшена?

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

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

1. Изменение бизнес-логики. Это один из наиболее опасных рисков, особенно если изменения вносятся через конфигурационные файлы, интерфейсы SCADA, или API, минуя основной код.
   Чем опасно: незаметные изменения могут изменить поведение системы – отработку аварий, алгоритмы дозирования, расписания запусков.
   Как предотвращать: фиксировать логику в виде кодируемых политик (Infrastructure-as-Code, Policy-as-Code), проводить анализ изменений конфигурации, вводить контроль на уровне pull request или CI-сборки.
2. Потери телеметрии. Если данные с датчиков теряются, не записываются или обрабатываются с ошибками, система может недостоверно отображать состояние, либо принимать ошибочные решения.
   Чем опасно: пропущенные аварии, ложные срабатывания, ошибки отчетности.
   Как предотвращать: тестировать систему на устойчивость к пропущенным пакетам, использовать буферизацию, резервирование каналов, настраивать мониторинг молчания сенсоров.
3. Нарушения SLA передачи данных. Речь о задержках или сбоях в обмене данными между компонентами (например, ГосСОПКА).
   Чем опасно: потеря актуальности данных, нарушение технологических маршрутов, сбой интеграций.
   Как предотвращать: проводить нагрузочное тестирование, моделировать сценарии деградации каналов, внедрять таймауты и Fallback-механизмы.

Дополнительно стоит учитывать:

• Совместимость версий ПО и библиотек, особенно в mixed-средах, где разные компоненты обновляются с разной скоростью.
• Цепочку доставки – например, изменения, внесенные в git, должны пройти проверку и утверждение перед попаданием в продуктив.
• Атаки через Supply Chain или конфигурации – важно контролировать, откуда берутся зависимости и кто вносит изменения.

Важность отраслевых площадок в развитии культуры безопасной разработки

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