Алексей Хорошилов, ИСП РАН: Не рассчитывайте, что ИИ сможет самостоятельно разрабатывать безопасный код без участия человека

Разработка безопасного программного обеспечения (РБПО) постепенно становится обязательной частью инженерных процессов. Однако внедрение статического анализа, сканеров и других инструментов еще не означает, что компания действительно достигла зрелости. На практике многое зависит от культуры разработки, вовлеченности команд, поддержки руководства и способности встроить требования безопасности в повседневную работу, а не превратить их в формальность.

Алексей Хорошилов, руководитель центра исследований безопасности системного ПО ИСП РАН, в интервью для Кибер Медиа рассказал, какие практики РБПО уже стали нормой для российских компаний, почему главные проблемы связаны не со стандартами, а с их применением, как выстроить безопасную работу с open source-компонентами и какую роль в ближайшие годы сыграют ИИ и автоматизация.

Кибер Медиа: Какие элементы РБПО российские компании за последние несколько лет действительно научились внедрять на практике, а где разрыв между декларируемыми процессами и реальной инженерной практикой остается самым большим?

Алексей Хорошилов: Если говорить о том, что российские компании действительно научились внедрять, то это, наверное, базовые процессы — композиционный и статический анализ. В общем-то, они внедряются уже достаточно хорошо. Но композиционный анализ предназначен для анализа всего кода продукта, в первую очередь заимствованного. Статический анализ зачастую ограничивается только собственными компонентами, которые разрабатываются внутри организации. Заимствованные остаются за бортом. Соответственно, эта часть кода продукта фактически остается не покрытой анализом и является источником угроз.

С точки зрения разрыва между декларируемыми процессами и реальной инженерной практикой сложно сказать, что компании что-то декларируют, но не делают. Скорее приходится сталкиваться с тем, что работа выполняется не в полном объеме. Декларируется, что проводится анализ всех срабатываний. На практике оказывается, что он идет только по верхушкам.

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

Если все процедуры безопасной разработки существуют где-то в стороне от основного процесса создания продукта, то зрелость близка к нулю

Кибер Медиа: Что сегодня является главным препятствием для зрелого внедрения РБПО в российских компаниях: нехватка специалистов, отсутствие культуры безопасности, давление сроков разработки или что-то другое? 

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

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

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

Если же такой культуры нет, то внедрение РБПО упирается еще и в необходимость сначала сформировать эту культуру.

Кибер Медиа: Способствуют ли действующие российские стандарты повышению реальной защищенности продуктов, или фокус индустрии пока остается смещенным в сторону «закрытия галочек» для прохождения сертификации? Можно ли говорить о формировании российских подходов к РБПО с учетом международного опыта? 

Алексей Хорошилов: Что касается стандартов, то здесь ситуация двоякая. Сами стандарты здравые, разумные и включают лучшие международные практики. Скорее все упирается в культуру их применения. Если организация действительно нацелена на внедрение лучших практик и повышение качества своих продуктов, а не только их защищенности, то работа по этим стандартам обеспечивает движение в этом направлении. То есть способствует повышению реальной защищенности продуктов.

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

Что касается российских подходов к РБПО, то я бы сказал, что они во многом построены на международном опыте. Лучшие практики, сформировавшиеся в международных стандартах, учитываются и применяются. Поэтому у меня нет ощущения, что российские подходы являются какими-то сильно уникальными. Они вполне следуют тому, что уже показало свою эффективность в международной практике.

При этом есть и собственные наработки. Например, подходы, связанные с анализом поверхности атаки и определением модулей или компонентов продукта, которые являются наиболее критичными с точки зрения безопасности. Это позволяет сфокусировать усилия именно на таких модулях, а не распылять их на все подряд. В этой части у нас сформировались собственные методики и инструментальные подходы, которые развиваются в рамках РБПО. При этом в международном сообществе они пока не получили такой широкой популярности.

Совместная работа позволяет применять лучшие практики РБПО и обеспечивать высокий уровень безопасности

Кибер Медиа: Насколько международные модели зрелости РБПО, такие как BSIMM, OWASP SAMM и Microsoft SDL, сохраняют актуальность для российских компаний? Есть ли области, где отечественная практика уже формирует собственные подходы?

Алексей Хорошилов: Этот вопрос во многом перекликается с предыдущим. Сами модели зрелости, наверное, в чистом виде у нас не используются для оценки процессов. Но лучшие практики, которые в них заложены, остаются актуальными и применяются на практике.

Поэтому нельзя сказать, что российские компании пошли по какому-то собственному пути. Все эти подходы задают ориентиры и набор практик, которые целесообразно внедрять, и они у нас используются.

Если говорить о собственных подходах, то я уже упоминал анализ поверхности атаки. В этой области появляются новые практики инструментального анализа, которых в таком виде нет в международных моделях.

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

Кибер Медиа: Как вы рекомендуете оценивать зрелость безопасной разработки? Какие метрики действительно отражают состояние процессов, а какие создают лишь ложное ощущение контроля?

Алексей Хорошилов: Для меня главный показатель зрелости безопасной разработки — это вовлеченность команды разработки в эти процессы. Если все процедуры безопасной разработки существуют где-то в стороне от основного процесса создания продукта, то зрелость близка к нулю. Чем сильнее они встроены непосредственно в работу продуктовой команды, тем выше зрелость.

Кибер Медиа: Если у компании ограниченные ресурсы на развитие РБПО, какие практики стоит внедрять в первую очередь? Где чаще всего достигается максимальный эффект при минимальных затратах? 

Алексей Хорошилов: Если у компании пока ничего не внедрено, то в первую очередь стоит смотреть в сторону контролируемого репозитория и композиционного анализа. Это позволит хотя бы в части заимствованных компонентов организовать защиту от угроз, связанных с цепочками поставок и уязвимостями в open source-компонентах.

Если говорить о собственном коде, то, наверное, имеет смысл сосредоточиться на трех основных практиках: 

• статический анализ;
• функциональное тестирование;
• фаззинг-тестирование. 

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

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

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

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

Кибер Медиа: Риски компрометации цепочек поставок ПО сегодня остаются одной из ключевых проблем индустрии. Как выстроить контроль сторонних компонентов и open-source библиотек так, чтобы не потерять скорость разработки? 

Алексей Хорошилов: В первую очередь необходимо сформировать контролируемый репозиторий заимствованных компонентов и организовать замкнутую среду сборки. Это нужно для того, чтобы во время сборки в продукт не попадало ничего, кроме кода, который хранится и анализируется в контролируемом репозитории. Без этого первого шага обеспечить безопасность цепочки поставок достаточно проблематично.

При этом здесь возникает определенное противоречие. С одной стороны, заимствованные open source-компоненты необходимо регулярно обновлять, чтобы устранять выявленные в них уязвимости. Чем быстрее обновление, тем лучше. С другой стороны, именно самые свежие версии могут оказаться скомпрометированными, если злоумышленники получили доступ к репозиторию или инфраструктуре распространения компонентов.

Поэтому одной из действенных практик является не мгновенный переход на самые новые версии, а небольшая задержка обновления. За это время международное сообщество пользователей успевает выявить возможные зловредные закладки, если они появились. Поэтому важно сформировать понятную политику обновления компонентов. Она должна учитывать оба этих фактора и позволять поддерживать баланс между безопасностью и скоростью разработки.

Если говорить о техническом контроле, то его не стоит ограничивать только проверкой известных уязвимостей в заимствованных компонентах. По возможности имеет смысл проводить и собственный анализ входящего кода. Чем зрелее организация, тем более тщательно этот процесс обычно организован.

Наша практика показывает, что наиболее полезны три подхода: статический анализ, функциональное тестирование и фаззинг-тестирование. Если они настроены на автоматический входной контроль заимствованных компонентов, то позволяют выявлять проблемы без существенного влияния на скорость разработки.

Статический анализ целесообразно применять в инкрементальном режиме. То есть отслеживать новые срабатывания, появившиеся в очередной версии компонента по сравнению с предыдущей. Такая практика позволяет с высокой вероятностью выявлять ошибки, которые появились при обновлении. Например, проблемы, возникающие при бэкпортировании исправлений в стабильные ветки.

То же самое относится и к методам динамического тестирования. Если автоматические прогоны выполняются для каждой новой версии, а затем сравниваются результаты с предыдущей, это становится эффективным способом выявления угроз. При этом участие человека требуется только на этапе анализа найденных проблем, поэтому такой подход практически не замедляет переход на новые версии компонентов.

Кибер Медиа: Безопасность часто воспринимается разработчиками как досадный тормоз. Как выстроить взаимодействие между командами, чтобы процессы РБПО воспринимались как часть инженерной культуры, а не как дополнительная бюрократия?

Алексей Хорошилов: Это, скорее, творческий вопрос. Здесь нужно найти ключ к конкретной команде разработки. Универсального рецепта нет — в каждом случае задача решается индивидуально.

Из действительно работающих практик я бы выделил две. Первая — это поиск секьюрити-чемпионов. То есть представителей команды разработки, которые понимают цели РБПО, сами заинтересованы в этих практиках и помогают внедрять соответствующую культуру внутри своей команды.

Вторая практика — демонстрация на реальных примерах из кода команды тех проблем и потенциальных угроз, которые позволяют выявить и предотвратить практики РБПО.

Это не всегда простой путь. Чтобы он сработал, нужно найти реальные примеры в коде, который разрабатывает именно эта продуктовая команда. Сделать это удается не всегда. Но если такие примеры находятся, они становятся хорошим рычагом для дальнейшего внедрения этих практик в повседневную работу.

Кибер Медиа: ИСП РАН исторически силен в математических методах верификации. Насколько оправдано применение формальных методов в коммерческой, промышленной разработке сегодня? Где проходит граница их практической и экономической применимости?Алексей Хорошилов: Формальных методов достаточно много. Есть тяжеловесные подходы, например, дедуктивная верификация, когда ставится задача доказать корректность кода. Такие методы действительно очень дороги, требуют участия высококвалифицированных специалистов и больших трудозатрат. Поэтому их обычно применяют только для самых критичных компонентов, в корректности которых необходимо быть уверенными практически на 100%. Да и далеко не в каждом продукте есть компоненты, критичность которых настолько высока.

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

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

Такие практики оказываются экономически эффективными в гораздо большем числе случаев. Они позволяют повысить эффективность тестирования за счет математических методов, но при этом требуют значительно меньших затрат, чем классическая формальная верификация.

Главное ограничение здесь, наверное, связано с нехваткой специалистов и знаний, которые позволяли бы применять эти методы шире, чем это происходит сегодня.

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

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

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

Дело не столько в самих стандартах, сколько в том, с какой целью организация их применяет

Кибер Медиа: Какую реальную роль в РБПО в ближайшие 3–5 лет будут играть ИИ и автоматизация? Какие процессы они действительно способны изменить, а где ожидания рынка пока завышены?

Алексей Хорошилов: Безусловно, технологии ИИ окажут большое влияние на процессы РБПО. Прежде всего хотелось бы ожидать, что они существенно помогут в выявлении ошибок. Уже существующие практики можно будет применять с меньшими затратами со стороны разработчиков. Кроме того, ИИ сможет взять на себя часть задач по фильтрации и первичному анализу результатов. Мне представляется, что это позволит повысить эффективность процессов за счет автоматизации тех задач, которые сегодня требуют значительного ручного труда.

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

Отдельно я бы отметил еще один аспект, связанный с заимствованными компонентами. Мы о нем не поговорили, но он тоже важен. Open source-компоненты разрабатываются под открытыми лицензиями, поэтому открывают дополнительные возможности для совместной работы над безопасностью. Выявлять и устранять уязвимости могут не только отдельные организации, но и все сообщество пользователей этих компонентов.

Опыт нашего центра показывает, что такой подход действительно работает. Даже если речь идет о таких масштабных проектах, как ядро Linux с десятками миллионов строк кода, совместная работа позволяет применять лучшие практики РБПО и обеспечивать высокий уровень безопасности. Сотрудничество вокруг open source-компонентов — еще один важный фактор повышения безопасности цепочки поставок.