Арутюн Аветисян, директор ИСП РАН, рассказал порталу Cyber Media об анализаторах исходного кода, формировании и тенденциях рынка такого рода решений, использовании нейросетей для поиска ошибок и роли анализаторов кода в процессе безопасной разработки ПО.

Cyber Media: Как появились анализаторы исходного кода и какую задачу решает этот инструмент?

Арутюн Аветисян: Исторически рынок анализаторов зародился в конце 90-х – начале 2000-х, когда американский регулятор ввел ряд требований, включающих в себя автоматизированный поиск ошибок в исходном коде. Необходимость в таких инструментах возникла в связи с тем, что программы стали большими и находить в них ошибки вручную оказалось невозможно. Кроме того, программы получили доступ в интернет, и как следствие, ошибки превратились в точки входа для злоумышленников. Последствия взломов стали серьёзнее: кража данных, физический ущерб. Классических методов защиты по периметру уже было недостаточно, поэтому понадобились инструменты для анализа кода.

Государственный регулятор и его требования к качеству кода стали точкой старта для развития рынка. Анализаторы, которые были разработаны к этому времени, давали до 99% ложных срабатываний. Как следствие, это приводило к росту нагрузки на программиста, который должен был отличить ложные срабатывания от реальных. Логично, что желающих пользоваться такими инструментами было немного, но требования регулятора это не отменяло. Поэтому появился запрос на качественные анализаторы исходного кода, которые выдают хотя бы 50%, а позднее – 70% и 80% реальных срабатываний.

При этом у всех участников рынка изначально было понимание, что нет и не будет никакого идеального анализатора, который найдет все ошибки в коде, сделает его абсолютно «чистым». Даже современные анализаторы находят не все ошибки, поэтому часто используется несколько инструментов. Но так как каждый из них по-своему выбирает, что пропустить, а что отметить как ошибку, в целом пересечение по найденным ошибкам выходит очень небольшим, менее 50%.  

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

Важно понимать, что если компания пишет «сырой», некачественный код, и затем его использует, то это приводит не только к гарантированному появлению точек входа для злоумышленника, но и к рискам отказа в обслуживании, как минимум. Чистый код – это не только безопасность, но и эффективность. А еще – прямая экономия ресурсов. Чем раньше исправляешь ошибку – тем дешевле это стоит, причем разница в стоимости может идти на порядки.

Cyber Media: В российском законодательстве тоже есть требования относительно применения анализаторов исходного кода?

Арутюн Аветисян: Разумеется. Соответствующий ГОСТ был принят еще в 2016 году. Мы не имели отношения к его написанию и увидели его уже в готовом варианте, в котором прописаны все этапы жизненного цикла безопасной разработки. При этом в ГОСТе нет конкретных требований к анализаторам и их характеристикам.

К настоящему моменту во ФСТЭК России создан подкомитет по разработке безопасного программного обеспечения, который ведет постоянную системную работу по стандартизации. Пишутся более детальные ГОСТы, нацеленные на требования к конкретным классам инструментов, причем не только анализаторов. Например, в ближайшее время должен появиться стандарт по безопасным компиляторам. Это очень важно, поскольку компилятор отвечает, условно говоря, за автоматизированный «перевод» с исходного высокоуровневого языка на машинный, нули и единицы.

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

Сейчас развивается и соответствующая область научного знания. В 2018 году на заседании Президиума РАН при поддержке ФСТЭК России, «Лаборатории Касперского», АО «НПО РусБИТех» и других компаний мы предложили ввести новую научную специальность, связанную с этим направлением. В 2021 году она была утверждена приказом Минобрнауки.

Cyber Media: А если говорить о бизнесе, как компании понять, что имеет смысл интегрировать анализаторы исходного кода в свою работу?

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

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

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

Это вполне адекватная практика. В других отраслях, например, в сельском хозяйстве, мы ведь требуем определенного уровня качества продукции. И никому не приходит в голову покупать плохой продукт, не соответствующий ГОСТам, который стоит дешевле. В случае с IT и кодом принцип тот же, на самом деле.

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

Cyber Media: В конце прошлого года огромный интерес исследователей привлекли нейросети, в частности – ChatGPT. С их помощью, в том числе, пробуют искать уязвимости и анализировать код на содержание других ошибок. На Ваш взгляд, может ли такое решение быть альтернативой классическому анализатору?

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

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

Для примера: попробуйте попросить ИИ не написать текст, а найти ошибки в уже написанном произведении. Затем – сообщить, в чем заключается каждая ошибка и объяснить причины ее появления. Я вовсе не говорю, что применять ИИ нельзя, и что эффективные решения не появятся в будущем. Более того, мы активно работаем в этом направлении и проводим исследования по использованию ИИ в безопасной разработке. Это очень перспективная тема, но в настоящее время нас больше интересует разработка инструментов, позволяющих анализировать сами технологии ИИ. В этих технологиях возникают ошибки совершенно нового типа, которые приводят, например, к атакам на модели машинного обучения, поэтому в дополнение к классическим анализаторам требуются принципиально новые инструменты анализа. Это необходимо для создания доверенных программных систем. В нашем Исследовательском центре доверенного ИИ мы уже получили результаты, признанные мировым сообществом, но основная работа ещё впереди.