Максим Карзаев, «Газпром нефть»: Безопасность — это не очередной регламент, а инженерная практика

Рост требований регуляторов, атаки на цепочку поставок и новые риски, связанные с AI/ML — все это заставляют промышленные компании переходить от формальной отчетности к практическим мерам безопасности. Разработчики внедряют автоматические проверки кода, безопасные конвейеры сборки и осваивают принципы secure coding, чтобы реально повысить уровень защищенности своих продуктов. Максим Карзаев, директор программ развития цифровых решений «Газпром нефть», эксперт программного комитета конференции byteoilgas_conf, в интервью для Cyber Media рассказал, какие ошибки встречаются чаще всего, как встроить безопасность в процессы и с чего начать путь в Application Security.

Cyber Media: Какие основные ошибки в безопасности вы чаще всего наблюдаете при разработке промышленных и корпоративных приложений в коде, в архитектуре или в процессах?

Максим Карзаев: Одна из наиболее частых ошибок — использование компонентов вне согласованного технологического стека. Это происходит, когда при разработке выбираются фреймворки или библиотеки, не предусмотренные корпоративным стеком, без учета того, насколько они вписываются в общий технологический ландшафт компании и обеспечены ли средствами автоматизированной проверки.

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

В процессах заметен риск атак на цепочки поставщиков. Это серьезная угроза, с которой необходимо уметь работать системно.

Технический долг в области безопасности тоже распространен. Нередко обнаруженные уязвимости фиксируются, но их устранение откладывают «на будущее» или перекладывают на вендора без жестких сроков закрытия. Накопление таких долгов создает иллюзию защищенности — до того момента, когда одна из уязвимостей приводит к критическому инциденту.

Минимум в области безопасной разработки должен быть встроен не в каждый отдельный продукт, а в процессы разработки ПО в целом

Cyber Media: Как встроить безопасность в процесс разработки так, чтобы это не вызывало сопротивления со стороны Dev-команд и не тормозило релизы?

Максим Карзаев: Чтобы безопасность не мешала разработке и релизам, необходимо:

1. Реализовать практику кросс-функциональных команд с включением ролей application security и назначением security champions. Внедрять подходы security-by-design и shift-left, чтобы учитывать задачи ИБ с ранних этапов разработки.
2. Автоматизировать рутинные операции по оценке уровня защищенности, например, с помощью ASOC.
3. Повышать уровень осведомленности разработчиков о ключевых угрозах безопасности для разрабатываемого ПО.
4. Внедрять концепцию «зеленого коридора», автоматизированные quality gates и четко разделять объективные и субъективные проверки (code review, threat modeling, оценка архитектурных решений).

Cyber Media: Какие практики или инструменты вы считаете наиболее эффективными в условиях ограниченных ресурсов, например, если в команде нет выделенного AppSec-инженера?

Максим Карзаев: Даже при отсутствии выделенного AppSec-инженера команда может существенно повысить уровень защищенности кода и процессов, используя базовый набор инженерных практик и простые встраиваемые инструменты.

Рекомендую:

• назначать security champions из числа разработчиков;
• постоянно повышать их осведомленность;
• предоставлять им инструменты ASOC, ASPO, ASTO;
• развивать библиотеки «риск-мер» для типовых рисков — например, чек-листы и практики работы с источниками.

Cyber Media: Как изменился подход к безопасности разработки за последние 2–3 года в условиях роста требований регуляторов и развития атак на цепочку поставок? Вы видите, что команды стали реально менять подход или пока они только усилили отчетность?

Максим Карзаев: Во-первых, регуляторы значительно ужесточили требования к безопасной разработке — новые редакции стандартов ФСТЭК и ГОСТ Р 56939, методические рекомендации отраслевых центров компетенций, приказ Минэнерго о безопасности ПО для КИИ и т. д. Формально это приводит к росту объема документации, проверок и отчетности.

Однако по мере взросления инженерной зрелости все больше компаний переходят от декларативных SSDLC к практическим действиям. Громкие инциденты последних лет, когда в стороннем коде (а его в современном продукте до 90%) находили «трояны» и backdoor-ы, заставили разработчиков всерьез задуматься о безопасности внешних компонентов.

Сегодня отраслевой консорциум формирует единые «правила игры» — свод рекомендаций и требований по безопасной разработке, адаптированных под нужды промышленного ПО. В них описано не только «что делать», но и «как делать». Это позволяет компаниям снизить затраты на создание собственных методик и при этом повысить уровень защищенности — достаточно адаптировать готовые отраслевые фреймворки под свои проекты.

Кроме того, появились новые векторы атак, связанные с LLM: утечки конфиденциальности, data poisoning и prompt-инъекции в производственных чат-ботах и аналитических сервисах. Регуляторы уже включают управление жизненным циклом AI/ML-решений в требования к КИИ, и компании вынуждены расширять модель угроз, чтобы учитывать как классические риски, так и новые атаки на нейросети.

В итоге — да, объем отчетности вырос, но параллельно мы видим реальный сдвиг «от формальности к практике»: автоматизируются проверки кода и зависимостей, внедряются безопасные конвейеры сборки и выстраиваются процессы управления рисками на всем жизненном цикле ПО — от первых строк кода до эксплуатации.

Даже при отсутствии выделенного AppSec-инженера команда может существенно повысить уровень защищенности кода и процессов

Cyber Media: Какой минимум в области безопасной разработки должен быть внедрен в продукте, прежде чем его можно запускать в эксплуатацию в промышленной или энергетической отрасли? По secure coding, тестированию, правам доступа и т. д.

Максим Карзаев: Минимум в области безопасной разработки должен быть встроен не в каждый отдельный продукт, а в процессы разработки ПО в целом. Такой подход позволяет обеспечить требуемый уровень защищенности создаваемых решений.

Важно учитывать и требования регуляторов РФ к безопасности разработки и эксплуатации ПО в энергетической отрасли — они сформулированы достаточно понятно и обоснованно, поэтому игнорировать их нельзя.

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

Cyber Media: С чего бы вы посоветовали начать тем, кто только начинает путь в Application Security, с точки зрения процессов, культуры и технологий?

Максим Карзаев: Начинать стоит с практики и реальных кейсов — участвуйте в проектах, где можно внедрять простые проверки и сразу видеть результат. Не бойтесь «прощупывать» инфраструктуру, читать чужой код, настраивать CI-пайплайны. Ищите ментора внутри компании или в профессиональном сообществе, участвуйте в хакатонах и CTF — это быстрый способ прокачать навыки.

Важно помнить: безопасность — это не очередной регламент, а инженерная практика. Понимание и управление техническим долгом безопасности с первых дней позволит вырасти не просто в «исполнителя требований», а в архитектора устойчивых решений.

Что особенно полезно на старте:

• Получить образование в области ИБ и разработки ПО — качественную базу дают ведущие технические вузы России.
• Развиваться через интересные задачи, где можно работать с современными технологиями.
• Использовать поддержку команды и профессионального ментора, который поможет с траекторией развития.
• Присоединиться к профессиональному сообществу, чтобы быть в курсе актуальных практик и культуры безопасной разработки. Для такого обмена опытом, например, была создана площадка byteoilgas_conf.