В преддверии Дня безопасной разработки ПО, который АРПП «Отечественный софт» проводит 17 июня, Роман Карпов, глава комитета по информационной безопасности АРПП и генеральный директор Axiom JDK рассказал о влиянии массового применения ИИ на текущую модель угроз, специфических рисках LLM-приложений, трансформации регуляторной базы, эволюции подходов к безопасности Open source и главных подводных камнях при внедрении практик DevSecOps.
Кибер Медиа: Сегодня практически любая дискуссия о будущем кибербезопасности неизбежно сводится к теме искусственного интеллекта — и предстоящий День безопасной разработки ПО наверняка не станет исключением. Если говорить о текущих реалиях, как массовое применение ИИ меняет модель угроз и баланс сил: кто сейчас получает больше преимуществ от этих технологий — атакующие или защитники?
Роман Карпов: Сегодня мы наблюдаем не столько изменение самой природы угроз, сколько резкое снижение порога входа в отдельные классы атак. Генеративные модели позволяют автоматизировать подготовку вредоносного кода, фишинговых кампаний, анализ инфраструктуры и поиск потенциальных уязвимостей. В результате атакующие получают возможность масштабировать свою деятельность значительно быстрее, чем раньше.
Однако в долгосрочной перспективе преимущество будет находиться на стороне защитников. Организации обладают доступом к телеметрии, внутренним данным, процессам эксплуатации и жизненному циклу разработки. Именно эти данные позволяют применять ИИ не только для обнаружения угроз, но и для системного управления безопасностью.
На практике мы уже видим применение ИИ для анализа исходного кода, выявления дефектов безопасности, корреляции событий, приоритизации рисков и автоматизации расследований. Поэтому вопрос сегодня заключается не в том, кто получает преимущество, а в том, насколько быстро организации смогут встроить ИИ в управляемые процессы разработки и эксплуатации.
Кибер Медиа: Если говорить о самих нейросетях, то безопасность ИИ-систем и LLM-приложений сегодня выделяется в отдельный класс задач. Какие специфические риски несут такие продукты и как разработчикам выстраивать их защиту на фундаментальном уровне?
Роман Карпов: LLM-приложения формируют новую поверхность атаки, которая принципиально отличается от традиционных веб-приложений или корпоративных информационных систем. Если раньше объектом защиты были код, инфраструктура и данные, то теперь появляется необходимость защищать саму модель, контекст ее работы и механизмы взаимодействия с внешней средой.
Ключевые риски связаны с prompt injection, утечкой конфиденциальной информации через контекст модели, компрометацией внешних источников данных, атаками на механизмы RAG, а также злоупотреблением агентными функциями, когда модель получает возможность выполнять действия от имени пользователя.
Безопасность ИИ-систем нельзя обеспечить только средствами традиционной ИБ.
Важно понимать, что безопасность ИИ-систем нельзя обеспечить только средствами традиционной ИБ. Необходимо проектировать архитектуру с учетом модели угроз для LLM-приложений, вводить механизмы контроля доступа к контексту, обеспечивать изоляцию источников данных, аудит запросов и контроль жизненного цикла моделей. Фактически сегодня формируется отдельное направление инженерии безопасности ИИ.
Кибер Медиа: Регуляторная база в сфере безопасной разработки активно трансформируется — достаточно вспомнить 117-й приказ ФСТЭК и обновленный ГОСТ Р 56939-2024. Как эти и другие актуальные требования регуляторов меняют ландшафт рынка?
Роман Карпов: Последние изменения показывают важную тенденцию: регуляторы постепенно уходят от оценки отдельных средств защиты и переходят к оценке зрелости процессов разработки. Если раньше безопасность зачастую воспринималась как этап тестирования перед выпуском продукта, то сегодня она рассматривается как непрерывный процесс, охватывающий проектирование, разработку, тестирование, сопровождение и управление изменениями.
Для бизнеса главный риск заключается в формальном выполнении требований. Подготовка документов без реального изменения процессов создает иллюзию соответствия, но практически не влияет на уровень защищенности. Поэтому организациям важно строить процессы таким образом, чтобы требования регуляторов становились частью производственного контура, а не отдельной функцией комплаенса.
При этом регуляторная логика все больше смещается от контроля отдельных программных продуктов к контролю всей цепочки разработки и поставки программного обеспечения. В фокусе оказываются происхождение компонентов, управление зависимостями, наличие SBOM, процессы мониторинга уязвимостей и возможность подтверждения доверенности используемых библиотек.
Поэтому организациям необходимо выстраивать единый контур управления компонентной базой. Использование доверенных репозиториев с контролируемым обновлением библиотек, журналированием процессов сборки, результатами статического анализа и возможностью оперативного выпуска исправлений становится не только вопросом безопасности, но и элементом доказательной базы соответствия требованиям регуляторов.
Кибер Медиа: Финансовый сектор всегда остается приоритетной целью для хакеров и драйвером внедрения ИБ-практик. Какие специфические требования к безопасной разработке сегодня предъявляются к участникам финансового рынка и их ИТ-подрядчикам?
Роман Карпов: Финансовая отрасль традиционно находится в числе наиболее зрелых с точки зрения требований к безопасности разработки. Помимо общих практик Secure SDLC участники рынка должны учитывать требования Банка России, требования по обеспечению операционной надежности, а также требования к защите значимых объектов критической информационной инфраструктуры.
Особое внимание уделяется управлению уязвимостями, безопасности цепочек поставок программного обеспечения, контролю изменений и подтверждению безопасности программных продуктов на протяжении всего жизненного цикла.
Если говорить о ближайшей перспективе, регуляторная повестка будет двигаться в сторону повышения прозрачности процессов разработки. Речь идет о подтверждаемом происхождении компонентов, использовании SBOM, усилении контроля сторонних библиотек, а также повышении требований к защищенности поставщиков программного обеспечения.
Кибер Медиа: Ранее вы отмечали, что мир свободного ПО перестал быть по-настоящему свободным, а атаки через цепочки поставок вышли на первый план. Как сегодня эволюционируют подходы к безопасности open source и управлению зависимостями?
Роман Карпов: За последние несколько лет атаки через цепочки поставок превратились из редких инцидентов в один из наиболее значимых классов рисков. Современные приложения содержат тысячи сторонних компонентов, и каждая такая зависимость становится потенциальным каналом компрометации.
Именно поэтому рынок движется в сторону полной прозрачности состава программных продуктов. SBOM постепенно становится базовым инструментом управления зависимостями, позволяющим понимать, какие компоненты используются в продукте и какие риски они создают.
Одновременно меняется отношение к самому open source. Организации все чаще оценивают не только функциональность компонента, но и зрелость проекта, активность сообщества, скорость устранения уязвимостей, устойчивость сопровождения и предсказуемость жизненного цикла.
Для многих компаний проблема заключается уже не в поиске библиотеки, а в обеспечении контролируемого жизненного цикла ее эксплуатации.
Именно поэтому на рынке растет запрос на доверенные репозитории программных компонентов. Для многих компаний проблема заключается уже не в поиске библиотеки, а в обеспечении контролируемого жизненного цикла ее эксплуатации. Необходимо понимать происхождение компонента, своевременно получать обновления безопасности, иметь возможность оперативно анализировать уязвимости и получать подтвержденную информацию о составе поставки.
Например, использование доверенного репозитория Java-библиотек позволяет существенно повысить управляемость цепочки поставок. Организация получает не просто доступ к компонентам, а сервис сопровождения, включающий мониторинг критических уязвимостей, оперативную поставку обновлений, рекомендации по замене проблемных библиотек, дополнительную проверку компонентов средствами статического анализа, предоставление логов сборки и тестирования, а также поддержку совместимости с корпоративной платформой разработки.
Отдельно важно, что подобные репозитории позволяют обеспечить контролируемое сопровождение наиболее востребованных компонентов экосистемы, включая Spring Framework, Spring Boot и Spring Security, с возможностью оперативного выпуска исправлений безопасности и сопровождения изменений, необходимых заказчику. На практике это снижает зависимость от внешних источников, повышает доверенность программных компонентов и делает эксплуатацию программных продуктов более предсказуемой.
Кибер Медиа: Для построения действительно зрелого процесса безопасной разработки эксперты все чаще называют обязательной практикой использование систем класса ASOC. В чем их главная ценность для архитектуры безопасности и насколько российский рынок готов к их массовому использованию?
Роман Карпов: По мере роста количества инструментов безопасности организации сталкиваются с другой проблемой — избытком данных и недостатком управляемости.
ASOC-платформы позволяют объединить результаты SAST, DAST, SCA, контейнерного анализа и других средств в единый контур управления безопасностью приложений. Их основная ценность заключается не в обнаружении новых уязвимостей, а в возможности управлять процессом устранения рисков и интегрировать безопасность в жизненный цикл разработки.
Сегодня эффективность ASOC во многом зависит от качества входящих данных. Если организация не контролирует происхождение сторонних компонентов и не имеет достоверной информации о составе используемых библиотек, то даже самая развитая платформа оркестрации безопасности будет работать с неполными данными. Поэтому ASOC, SBOM и доверенные репозитории компонентов следует рассматривать как элементы единой системы управления рисками безопасной разработки.
Российский рынок постепенно подходит к этапу массового внедрения подобных решений. Сегодня многие крупные организации уже накопили значительный набор AppSec-инструментов, и следующим логичным шагом становится создание централизованной системы управления процессами безопасной разработки.
Кибер Медиа: Извечный страх любого бизнеса при внедрении проверок ИБ — это замедление выпуска продуктов. Как на практике грамотно интегрировать инструменты безопасности в процессы DevOps и конвейер CI/CD?
Роман Карпов: Наиболее распространенная ошибка заключается в том, что безопасность рассматривается как дополнительный этап контроля перед релизом. Такой подход действительно приводит к задержкам и конфликтам между командами разработки и ИБ.
Современная практика предполагает перенос проверок максимально рано в жизненный цикл разработки. Безопасность должна встраиваться непосредственно в конвейер CI/CD и выполняться автоматически по мере создания кода.
На практике это означает риск-ориентированный подход, при котором критические дефекты блокируют выпуск продукта, а менее значимые нарушения устраняются в рамках планового процесса. Такой механизм позволяет сохранить скорость поставки изменений и одновременно поддерживать необходимый уровень защищенности.
Кибер Медиа: Опираясь на ваш опыт руководства профильным комитетом и наблюдения за рынком, расскажите о главных подводных камнях внедрения практик безопасной разработки. Что чаще всего ломается или попросту не работает в реальных компаниях?
Роман Карпов: Большинство проблем связано не с технологиями, а с организационными вопросами. Компании приобретают инструменты, внедряют сканеры и формируют отчеты, однако не меняют процессы принятия решений и ответственности.
Часто отсутствует единая модель управления безопасностью приложений. Разработка, ИБ и эксплуатация работают в разных контурах, используют различные метрики и по-разному оценивают риски. В результате выявленные проблемы не устраняются своевременно, а безопасность начинает восприниматься как дополнительная бюрократическая нагрузка.
Еще одна распространенная проблема связана с отсутствием контроля над используемыми зависимостями. Многие организации продолжают получать компоненты напрямую из внешних репозиториев, не имея возможности гарантировать их происхождение, отслеживать изменения и оперативно реагировать на появление критических уязвимостей. В условиях роста атак на цепочки поставок такой подход создает дополнительные инфраструктурные риски.
Зрелый подход предполагает, что безопасная разработка рассматривается не как набор проверок, а как часть производственной системы организации. Только в этом случае появляются измеримые результаты: снижение количества уязвимостей, повышение качества программных продуктов, повышение управляемости цепочки поставок и более предсказуемая эксплуатация критически важных информационных систем.
Возврат к списку