Журнал "Information Security/ Информационная безопасность" #5, 2025

CI/CD и Shift Left в про- мышленности применимы, но только тогда, когда они встраиваются в существую- щую культуру надежности, изоляции и регламентов, а не пытаются ее заменить. Внедрение GitOps в SCADA-системах или на уровне контроллеров ПЛК остается большой ред- костью. Подобные кейсы возможны в организациях на стыке ИТ и OT, которые активно инвестируют в циф- ровизацию. агенты, сканеры или сборочные инструменты. Даже при жела- нии автоматизировать процессы это оказывается крайне сложно, а порой и вовсе невозможно из-за технических ограничений среды и требований регулято- ров. Тем не менее адаптирован- ные пайплайны все же воз- можны. Они должны быть изо- лированы (Air-Gapped), вклю- чать ручные контрольные точки, цифровую верифика- цию, офлайн-сканирование и обязательную валидацию ито- гового артефакта. Такой CI/CD больше напоминает автомати- зированный Change Control, чем классическую DevOps- практику, но он позволяет сохранить контроль, просле- живаемость и безопасность изменений. Что касается Shift Left, то он в промышленности возможен и даже необходим, но про- является иначе. Речь идет не о юнит-тестах и раннем скани- ровании кода, а о моделирова- нии угроз, оценке рисков и ана- лизе безопасности еще на ста- дии проектирования производ- ственных линий, выборе архи- тектуры и компонентов. Уже при разработке технологиче- ских схем можно закладывать требования к изоляции сетей, сегментированию зон, резерви- рованию и безопасным спосо- бам обновления. Подводя промежуточный итог, можно сказать, что CI/CD и Shift Left в промышленности применимы, но только тогда, когда они встраиваются в суще- ствующую культуру надежности, изоляции и регламентов, а не пытаются ее заменить. Пайплайн можно и нужно использовать как инструмент согласования интересов ИТ, ИБ и АСУ, особенно в средах, где высока цена ошибки и важно формализовать процесс внед- рения изменений. При правиль- ной архитектуре CI/CD-пай- плайн превращается не просто в средство доставки, а в меха- низм контроля, валидации и взаимодействия между коман- дами. Мне доводилось выстраивать процессы безопасной разра- ботки в компании, создающей ПО для энергетического сек- тора. Однако внедрение GitOps в SCADA-системах или на уровне контроллеров ПЛК остается большой редкостью. Подобные кейсы возможны в организациях на стыке ИТ и OT, которые активно инвести- руют в цифровизацию и готовы адаптировать современные практики под требования про- мышленной среды. Какие технологические риски нужно выявить до продакшена? До выхода системы в про- дакшен важно обнаружить тех- нологические риски, которые могут повлиять на ее стабиль- ность, безопасность и предска- зуемость. В критичных и про- мышленных системах речь идет не только о багax, а о факторах, способных нарушить производ- ственный процесс. На мой взгляд, ключевые группы рисков, которые стоит закладывать в предпроизвод- ственную проверку: 1. Изменение бизнес-логики. Это один из наиболее опасных рисков, особенно если измене- ния вносятся через конфигура- ционные файлы, интерфейсы SCADA, или API, минуя основ- ной код. Чем опасно: незаметные изменения могут изменить пове- дение системы – отработку ава- рий, алгоритмы дозирования, расписания запусков. Как предотвращать: фикси- ровать логику в виде кодируе- мых политик (Infrastructure-as- Code, Policy-as-Code), проводить анализ изменений конфигура- ции, вводить контроль на уровне pull request или CI-сборки. 2. Потери телеметрии. Если данные с датчиков теряются, не записываются или обраба- тываются с ошибками, система может недостоверно отобра- жать состояние, либо принимать ошибочные решения. Чем опасно: пропущенные аварии, ложные срабатывания, ошибки отчетности. Как предотвращать: тести- ровать систему на устойчивость к пропущенным пакетам, использовать буферизацию, резервирование каналов, настраивать мониторинг мол- чания сенсоров. 3. Нарушения SLA передачи данных. Речь о задержках или сбоях в обмене данными между компонентами (например, Гос- СОПКА). Чем опасно: потеря актуаль- ности данных, нарушение тех- нологических маршрутов, сбой интеграций. Как предотвращать: прово- дить нагрузочное тестирование, моделировать сценарии дегра- дации каналов, внедрять тай- мауты и Fallback-механизмы. Дополнительно стоит учиты- вать: l Совместимость версий ПО и библиотек, особенно в Mixed- средах, где разные компоненты обновляются с разной скоро- стью. l Цепочку доставки – напри- мер, изменения, внесенные в git, должны пройти проверку и утверждение перед попада- нием в продуктив. l Атаки через Supply Chain или конфигурации – важно контро- лировать, откуда берутся зави- симости и кто вносит измене- ния. Влияние отраслевых площадок на развитие культуры безопасной разработки Как эксперт программного комитета byteoilgas_conf, я вижу, что отраслевые площад- ки заметно укрепляют культуру безопасной разработки в круп- ных организациях, создавая пространство для обмена опы- том и внедрения передовых практик. В нефтегазовой отрас- ли этот процесс идет более размеренно: здесь ценят надежность и проверенные вре- менем технологии, поэтому новые подходы проходят этап адаптации осторожно и вдум- чиво. Тем не менее влияние конференции ощутимо: она задает ориентиры и вдохнов- ляет на постепенные, но устой- чивые изменения. l • 53 БЕЗОПАСНАЯ РАЗРАБОТКА ДЛЯ АСУ ТП И IOT www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru Рисунок: ГРОТЕК