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

в России, куда входят: аналитики, отве- чающие за аудит процессов безопасной разработки, формирование рекомендаций и выстраивание процессов у заказчиков; инженеры, внедряющие инструменты без- опасности и отвечающие за инфраструк- турный слой; специалисты по анализу защищенности приложений, которые зани- маются поиском уязвимостей в прикладном ПО, формируют рекомендации по их устра- нению и разрабатывают подходы, позво- ляющие изначально создавать программ- ное обеспечение с учетом требований без- опасности. – Как решаете кадровый вопрос? – Ядро команды мы формируем из опытных экспертов и параллельно выра- щиваем собственные кадры. Сотрудни- чаем с Уральским федеральным уни- верситетом: ведем годовой курс по без- опасной разработке, отбираем сильных студентов, затем через летнюю школу и стажировку принимаем лучших в свою команду. – С какими компромиссами сталкиваются разработчики про- мышленного ПО при внедрении защиты? – В промышленности внедрение прак- тик безопасной разработки сопровож- дается специфическими ограничениями, отсутствующими в Enterprise- и веб-сег- ментах. Классические механизмы повы- шения безопасности кода (динамическое управление памятью, дополнительные runtime-проверки) или безопасности про- граммного обеспечения. Например шиф- рование сетевого трафика и аутенти- фикация часто вступают в прямое про- тиворечие с ключевым требованием систем АСУ ТП и встраиваемых устройств – детерминированностью. Такие системы должны гарантированно выполнять свои функции в заданные временные интервалы. Любая задержка или сбой могут привести и к технологи- ческим нарушениям, и к серьезным последствиям вплоть до угрозы жизни. Современные практики DevSecOps предполагают активное инструментиро- вание кода – особенно в языках вроде C/C++: использование санитайзеров, защит стека, проверок границ буферов и других механизмов. Однако для финальных артефактов, например про- шивок ПЛК (программируемых логиче- ских контроллеров), систем релейной защиты или ЧПУ, такие подходы часто неприменимы. Первая причина заключается во влия- нии на временные характеристики. Любые дополнительные проверки уве- личивают время выполнения операций. Для систем реального времени даже превышение порога в несколько милли- секунд может быть критичным: контрол- лер может не успеть обработать сигнал, сработает watchdog, что приведет к ава- рийной остановке процесса. Вторая причина – ограничения по ресурсам. Встраиваемые устройства часто имеют жесткие лимиты по памяти. Механизмы безопасности увеличивают объем кода и потребление памяти, из- за чего итоговый образ может просто не поместиться в устройство. Поэтому ключевой компромисс здесь – между безопасностью и предсказуе- мостью/надежностью выполнения. На практике это решается смещением акцен- та: активное использование инструментов безопасности на этапах разработки и тестирования, но с минимальным влия- нием на финальный исполняемый код. – Где в промышленном ПО нахо- дятся точки роста, чтобы безопас- ность не тормозила систему? – Одной из основных точек роста в том, чтобы встраивать проверки не в финальный артефакт, который уходит в продакшен, а на этапах разработки, тестирования и интеграции. Фаззинг, статический анализ и другие инструмен- ты должны работать там, где они дей- ствительно приносят пользу: помогать находить дефекты и устранять их до релиза. А в промышленную среду должен поставляться уже чистый дистрибутив. Еще один вектор проблем с ПО в про- мышленности – это работа с легаси. Заводы и производственные системы автоматизировались в течение десяти- летий, поэтому сегодня почти всегда приходится иметь дело с гибридной кодовой базой: часть системы написана давно, а другая часть – на современном стеке. Главной ошибкой здесь будет попытка применения одинаковых под- ходов ко всему массиву кода. Поэтому для легаси мы обычно используем стра- тегию изоляции и контроля неизменно- сти, а для нового кода – полноценный набор современных практик безопасной разработки. Для современного стека подход понятен: используются актуаль- ные инструменты анализа, контроли- руются изменения, выстраиваются про- верки в пайплайне. Для легаси важнее другое – аккуратно ограничить риски. Один из ключевых архитектурных под- ходов здесь – Anti-Corruption Layer, или ACL. Это прослойка между новым и старым кодом, которая не позволяет современным компонентам обращаться к легаси напрямую. Отдельной пробле- мой являются устаревшие или про- приетарные библиотеки, которые часто уже не поддерживаются, но их замена может нарушить работу всей системы. В таких случаях возможны два пути. Если видно, что уязвимая функция дей- ствительно достижима и представляет риск, ее либо переносят в новый ком- понент на современном стеке, либо закрывают дополнительной прослойкой валидации. По сути, это внутренний мини-файрвол, который не пропускает в уязвимый участок непроверенные данные. В промышленном ПО безопасность становится органичной частью системы, когда мы грамотно распределяем меры защиты по этапам разработки и архи- тектурным слоям, а не пытаемся утяже- лить продакшен. – Какие риски возникают, если внедрять защиту постфактум? – В промышленном ПО внедрение защиты сверху , уже после разработки, сильно ограничено и зачастую не дает ожидаемого эффекта. Во-первых, не всегда технически воз- можно установить дополнительные сред- ства защиты. Во-вторых, такие решения почти всегда создают дополнительную нагрузку на систему, что критично для АСУ ТП и других систем реального вре- мени. Поэтому на практике применяется архитектурный подход: технологический сегмент изолируется от внешней среды – используются межсетевые экраны, сегментация, контроль трафика, анти- вирусная защита. Это обязательный уро- вень, в том числе с точки зрения требо- ваний регуляторов. Однако важно понимать, что такая защита не является панацеей. Она строится по принципу жесткого пери- метра: предполагается, что внутрь никто не проникнет. Но практика показывает, что этот периметр может быть обойден. И если это происходит, то вся система оказывается уязвимой, потому что внут- ри изначально не закладывались меха- низмы безопасности. Именно в этом главный риск: если на этапе проектиро- вания и разработки не внедрены прин- ципы Secure-by-Design, то последующее навешивание средств защиты уже не компенсирует уязвимости. В результате при компрометации периметра послед- ствия могут быть существенно тяжелее. – Что такое Apsafe и какую ценность он дает? Умеет ли нахо- дить не только типовые, но и логические уязвимости? – Apsafe – это сервис, который помо- гает внедрить процессы безопасной раз- работки на всех этапах жизненного цикла ПО. Его ключевая ценность для заказчиков заключается в том, что он быстро встраивается в существующий контур разработки и не требует развер- тывания собственной инфраструктуры или внедрения дополнительных инстру- ментов: вся технологическая часть оста- ется на нашей стороне. Сегодня многие компании уже столк- нулись с тем, что просто инструменты не дают ожидаемого эффекта: отчеты пере- гружены ложноположительными сраба- тываниями, а реальные уязвимости теряются в общем массиве. Поэтому ключевым становится не сам факт ска- нирования, а способность превратить его результаты в управляемый и проверенный список задач на исправление — именно этот подход реализован в Apsafe. • 11 ПЕРСОНЫ www.itsec.ru