Применение статического анализа при разработке программ. Использование статического и динамического анализа для повышения качества продукции и эффективности разработки Статический анализ

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

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

ЭЛВИС-ПЛЮС предлагает систему анализа исходных кодов на основе продуктов мирового лидера в этой области — HP Fortify Static Code Analyzer (SCA) , а также российских компаний — InfoWatch Appercut и Positive Technologies Application Inspector .

Цели создания Системы

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

Задачи, решаемые Системой

• Статистический анализ программного обеспечения на наличие ошибок/уязвимостей, производимый без выполнения приложений на уровне исходных кодов.
• Динамический анализ программного обеспечения на наличие ошибок/уязвимостей, производимый после сборки и запуска приложения.
• Реализация технологий безопасной разработки бизнес-приложений во время создания и на протяжении всего жизненного цикла приложения путем встраивания Системы в среду разработки приложений.

Архитектура и основные функции системы (на примере продукта HP Fortify SCA)

Статический анализ, также известный как статическое тестирование безопасности приложений (SAST - Static Application Security Testing):

• Определяет потенциальные уязвимости приложения непосредственно на уровне кода.
• Помогает идентифицировать проблемы ещё в процессе разработки.

Динамический анализ, также известный как динамическое тестирование безопасности приложений (DAST - Dynamic Application Security Testing):

• Обнаруживает уязвимости в запущенных веб-приложениях и веб-сервисах путём моделирования полноценных сценариев атак.
• Проверяет, можно ли на практике использовать конкретную уязвимость.
• Ускоряет реализацию корректирующих мер, позволяя понять, какие проблемы необходимо решить в первую очередь и почему.

Система на базе HP Fortify Software Security Center позволяет реализовать автоматизированные процессы обнаружения, приоритизации, устранения, отслеживания, проверки и управления уязвимостями в ПО бизнес-приложений. Инструменты HP Fortify могут встраиваться в интегрированные среды разработки (IDE - Integrated Development Environment), средства контроля качества (QA - Quality assurance) и системы отслеживания ошибок.

Основные функции Системы

• Внедрение и автоматизация процесса обнаружения уязвимостей прикладного ПО (ППО) на различных стадиях разработки (создание, отладка, тестирование, эксплуатация, модификация).
• Обнаружение уязвимостей в развернутых веб-приложениях на различных стадиях разработки ППО (создание, отладка, тестирование, эксплуатация, модификация).
• Настройка условий и критериев обнаружения уязвимостей в ППО.
• Поддержка современных языков программирования для определения угроз безопасности ППО (C/C++, Java, JSP, ASP, .NET, JavaScript, PHP, COBOL, PL/SQL, ABAP, VB6 и др.).
• Поддержка различных инструментов разработки для интеграции со средой разработки ППО.
• Формирование отчётов о проблемах безопасности проверяемого ППО с ранжированием найденных уязвимостей по степени риска.
• Отправка практических рекомендаций по устранению обнаруженных уязвимостей в коде в среду разработки ППО.
• Обновление базы уязвимостей для определения актуальных угроз безопасности ППО на основе предоставляемой вендором информации.

Преимущества от внедрения Системы

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

С оригиналом статьи можно познакомится, воспользовавшись Wayback Machine - Internet Archive: Static Code Analysis .

Поскольку все статьи на нашем сайте представлены на русском и английском языке, то мы выполнили перевод статьи Static Code Analysis на русский язык. А заодно решили опубликовать её на Хабре. Здесь уже публиковался пересказ этой статьи . Но уверен, многим будет интересно прочитать именно перевод.

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

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

Я всегда старался писать хороший код. По своей натуре я похож на ремесленника, которым движет желание непрерывно что-то улучшать. Я прочел груды книг со скучными названиями глав типа «Стратегии, стандарты и планы качества», а работа в Armadillo Aerospace открыла мне дорогу в совершенно иной, отличный от предшествующего опыта мир разработки ПО с повышенными требованиями к безопасности.

Более десяти лет назад, когда мы занимались разработкой Quake 3, я купил лицензию на PC-Lint и пытался применять его в работе: привлекала идея автоматического обнаружения дефектов в коде. Однако необходимость запуска из командной строки и просмотра длинных списков диагностических сообщений отбили у меня охоту пользоваться этим инструментом, и я вскоре отказался от него.

С тех пор и количество программистов, и размер кодовой базы выросли на порядок, а акцент в программировании сместился с языка C на C++. Все это подготовило намного более благодатную почву для программных ошибок. Несколько лет назад, прочитав подборку научных статей о современном статическом анализе кода, я решил проверить, как изменилось положение дел в этой области за последние десять лет с тех пор, как я попробовал работать с PC-Lint.

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

Coverity

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

Microsoft /analyze

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

Я потихоньку приступил к правке кода - прежде всего, занялся своим собственным, затем системным, и, наконец, игровым. Работать приходилось урывками в свободное время, так что весь процесс затянулся на пару месяцев. Однако эта задержка имела и свой побочный полезный эффект: мы убедились, что /analyze действительно отлавливает важные дефекты. Дело в том, что одновременно с моими правками наши разработчики устроили большую многодневную охоту за багами, и выяснилось, что каждый раз они нападали на след какой-нибудь ошибки, уже помеченной /analyze, но еще не исправленной мной. Помимо этого, были и другие, менее драматичные, случаи, когда отладка приводила нас к коду, уже помеченному /analyze. Все это были настоящие ошибки.

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

Однажды мы в каком-то проекте случайно выключили статический анализ. Прошло несколько месяцев, и когда я заметил это и снова включил его, инструмент выдал кучу новых предупреждений об ошибках, внесенных в код за это время. Подобным же образом программисты, работающие только под PC или PS3, вносят в репозиторий код с ошибками и пребывают в неведении, пока не получат письмо с отчетом о «неудачной 360-сборке». Эти примеры наглядно демонстрируют, что в процессе своей повседневной деятельности разработчики раз за разом совершают ошибки определенных видов, и /analyze надежно уберегал нас от большей их части.

PVS-Studio

Следующим инструментом, с которым я познакомился, был PVS-Studio . Он легко интегрируется в Visual Studio и предлагает удобный демо-режим (попробуйте сами!). В сравнении с /analyze PVS-Studio ужасно медлителен, но он сумел выловить некоторое количество новых критических багов, причем даже в том коде, который был уже полностью вычищен с точки зрения /analyze. Помимо очевидных ошибок PVS-Studio отлавливает множество других дефектов, которые представляют собой ошибочные программистские клише, пусть и кажущиеся на первый взгляд нормальным кодом. Из-за этого практически неизбежен некоторый процент ложных срабатываний, но, черт возьми, в нашем коде такие шаблоны нашлись, и мы их поправили.

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

PC-Lint

И снова в том коде, который был уже чист с точки зрения /analyze и PVS-Studio, нашлись новые важные ошибки. Я честно старался вычистить его так, чтобы и lint не ругался, но не удалось. Я поправил весь системный код, но сдался, когда увидел, сколько предупреждений он выдал на игровой код. Я рассортировал ошибки по классам и занялся наиболее критичными из них, игнорируя массу других, относящихся больше к стилистических недоработкам или потенциальным проблемам.

Я полагаю, что попытка исправить громадный объем кода по максимуму с точки зрения PC-Lint заведомо обречена на провал. Я написал некоторое количество кода с нуля в тех местах, где послушно старался избавиться от каждого назойливого «линтовского» комментария, но для большинства опытных C/C++-программистов такой подход к работе над ошибками - уже чересчур. Мне до сих пор приходится возиться с настройками PC-Lint, чтобы подобрать наиболее подходящий набор предупреждений и выжать из инструмента максимум пользы.

Выводы

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

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

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

Инструменты статического анализа вынуждены работать «с одной рукой, связанной за спиной»: им приходится делать выводы на основе разбора языков, которые вовсе не обязательно предоставляют информацию для таких выводов, и в целом делать очень осторожные предположения. Поэтому вы должны помогать своему анализатору, насколько возможно - отдавать предпочтение индексации перед арифметикой с указателями, держать граф вызовов в едином исходном файле, использовать явные аннотации и т.п. Все, что может показаться статическому анализатору неочевидным, почти наверняка собьет с толку и ваших коллег-программистов. Характерное «хакерское» отвращение к языкам со строгой статической типизацией («bondage and discipline languages») на деле оказывается недальновидным: потребности крупных, долгоживущих проектов, в разработку которых вовлечены большие команды программистов, кардинально отличаются от мелких и быстрых задач, выполняемых для себя.

Нулевые указатели - это самая насущная проблема в языке C/C++, по крайней у нас. Возможность двойственного использования единого значения в качестве как флага, так и адреса приводит к невероятному числу критических ошибок. Поэтому всегда, когда для этого есть возможность, в C++ следует отдавать предпочтение ссылкам, а не указателям. Хотя ссылка «на самом деле» есть ни что иное как тот же указатель, она связана неявным обязательством о невозможности равенства нулю. Выполняйте проверки указателей на ноль, когда они превращаются в ссылки - это позволит вам впоследствии забыть о данной проблеме. В сфере игростроения существует множество глубоко укоренившихся программистских шаблонов, несущих потенциальную опасность, но я не знаю способа, как полностью и безболезненно перейти от проверок на ноль к ссылкам.

Второй по важности проблемой в нашей кодовой базе были ошибки с printf-функциями. Она дополнительно усугублялась тем, что передача idStr вместо idStr::c_str() практически каждый раз заканчивалась падением программы. Однако, когда мы стали использовать аннотации /analyze для функций с переменным количеством аргументов, чтобы поверки типов выполнялись корректно, проблема была решена раз и навсегда. В полезных предупреждениях анализатора мы встречали десятки таких дефектов, которые могли привести к падению, случись какому-нибудь ошибочному условию запустить соответствующую ветку кода - это, между прочим, говорит еще и том, как мал был процент покрытия нашего кода тестами.

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

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

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

Невозможно провести достоверные контрольные испытания при разработке ПО, но наш успех от использования анализа кода был настолько отчетливым, что я могу позволить себе просто заявить: не использовать анализ кода - безответственно! Автоматические консольные логи о падениях содержат объективные данные, которые ясно показывают, что Rage, даже будучи по многим показателям первопроходцем, оказался намного стабильнее и здоровее, чем большинство самых современных игр. Запуск Rage на PC, к сожалению, провалился - готов поспорить, что AMD не используют статический анализ при разработке своих графических драйверов.

Вот вам готовый рецепт: если в вашей версии Visual Studio есть встроенный /analyze, включите его и попробуйте поработать так. Если бы меня попросили выбрать из множества инструментов один, я бы остановился именно на этом решении от Microsoft. Всем остальным, кто работает в Visual Studio, я советую хотя бы попробовать PVS-Studio в демо-режиме. Если вы разрабатываете коммерческое ПО, приобретение инструментов статического анализа будет одним из лучших способов вложения средств.

И напоследок комментарий из твиттера.

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

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

Некоторые люди считают программные метрики и обратное проектирование формами статического анализа.

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

Большинство компиляторов (например, GNU C Compiler) выводят на экран «предупреждения» (англ. warnings ) - сообщения о том, что код, будучи синтаксически правильным, скорее всего, содержит ошибку. Например:

Int x; int y = x+ 2 ; // Переменная x не инициализирована!

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

Типы ошибок, обнаруживаемых статическими анализаторами

• Неопределённое поведение - неинициализированные переменные, обращение к NULL-указателям. О простейших случаях сигнализируют и компиляторы.
• Нарушение блок-схемы пользования библиотекой. Например, для каждого fopen нужен fclose . И если файловая переменная теряется раньше, чем файл закрывается, анализатор может сообщить об ошибке.
• Типичные сценарии, приводящие к недокументированному поведению. Стандартная библиотека языка Си известна большим количеством неудачных технических решений. Некоторые функции, например, gets , в принципе небезопасны. sprintf и strcpy безопасны лишь при определённых условиях.
• Переполнение буфера - когда компьютерная программа записывает данные за пределами выделенного в памяти буфера.

Void doSomething(const char * x) { char s[ 40 ] ; sprintf (s, "[%s]" , x) ; // sprintf в локальный буфер, возможно переполнение .... }

• Типичные сценарии, мешающие кроссплатформенности .

Object * p = getObject() ; int pNum = reinterpret_cast < int > (p) ; // на x86-32 верно, на x64 часть указателя будет потеряна; нужен size_t

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

Dest.x = src.x + dx; dest.y = src.y + dx; // Ошибка, надо dy!

Std:: wstring s; printf ("s is %s" , s) ;

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

Void doSomething(int n, bool flag) // flag всегда равен true { if (flag) { // какая-то логика } else { // код есть, но не задействован } } doSomething(n, true ) ; ... doSomething (10 , true ) ; ... doSomething (x.size () , true ) ;

Std:: string s; ... s .empty () ; // код ничего не делает; вероятно, вы хотели s.clear()?

Формальные методы

Инструменты статического анализа

• Coverity
• lint и lock_lint, входящие в состав Sun Studio
• T-SQL Analyzer - инструмент, который может просматривать программные модули в базах данных под управлением Microsoft SQL Server 2005 или 2008 и обнаруживать потенциальные проблемы, связанные с низким качеством кода.
• АК-ВС

См. также

• Формальная семантика ЯП
• Анализ программного обеспечения
• Постепенная деградация
• SPARK - ЯП

Примечания

Ссылки

Wikimedia Foundation . 2010 .

Смотреть что такое "Статический анализ кода" в других словарях:

- (англ. Dynamic program analysis) анализ программного обеспечения, выполняемый при помощи выполнения программ на реальном или виртуальном процессоре (анализ, выполняемый без запуска программ называется статический анализ кода). Утилиты… … Википедия

Анализ потока управления это статический анализ кода для определения порядка выполнения программы. Порядок выполнения выражается в виде графа потока управления. Для многих языков граф потока управления явно прослеживается в исходном коде… … Википедия

У этого термина существуют и другие значения, см. BLAST (значения). BLAST Тип Инструменты статического анализа Разработчик Dirk Beyer, Thomas Henzinger, Ranjit Jhala, Rupak Majumdar, Berkeley Операционная система Linux, Microsoft Windows… … Википедия

В следующие таблицы включены пакеты программ, которые являются интегрированными средствами разработки. Отдельные компиляторы и отладчики не упомянуты. Возможно, в английском разделе есть более свежая информация. Содержание 1 ActionScript 2 Ада 3 … Википедия

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

Тип Статический анализатор кода Разработчик лаборатория BiPro Написана на С++ Операционная система Кроссплатформенное Языки интерфейса английский … Википедия

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

Александр Миноженко
Старший исследователь департамента анализа кода
в ERPScan (дочерняя компания Digital Security)

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

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

Недостатков у такого метода немало. Основным является то, что множество "подозрительных" конструкций в коде не всегда являются дефектами. В большинстве случаев такой код может быть синтаксически правильным и работать корректно. Соотношение "шума" к реальным дефектам может достигать 100:1 на больших проектах. Таким образом, разработчику приходится тратить много времени на его отсеивание от реальных дефектов, что отменяет плюсы автоматизированного поиска.

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

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

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

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

Процесс поиска уязвимостей в действии

Для иллюстрации приведем процесс поиска уязвимостей инъекции кода и SQL-инъекции (рис. 1).

Для их обнаружения находятся места в программе, откуда поступают недоверенные данные (рис. 2), например, запрос протокола HTTP.

На листинге (рис. 1) 1 на строке 5 данные получаются из HTTP запроса, который поступает от пользователей при запросе Web-страницы. Например, при запросе страницы “http://example.com/main?name =‘ or 1=‘1”. Строка or 1=‘1 попадает в переменную data из объекта request, который содержит HTTP-запрос.

Дальше на строке 10 идет вызов функции Process с аргументом data, которая обрабатывает полученную строку. На строке 12 – конкатенация полученной строки data и запроса к базе данных, уже на строке 15 происходит вызов функции запроса к базе данных c результирующим запросом. В результате данных манипуляции получается запрос к базе данных вида: select * from users where name=‘’ or ‘1’=‘1’.

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

Статические анализаторы работают похожим образом: помечают данные, которые поступают из недоверенного источника, отслеживаются все манипуляции с данными и пытаются определить, попадают ли данные в критичные функции. Под критичными функциями обычно подразумеваются функции, которые исполняют код, делают запросы к БД, обрабатывают XML-документы, осуществляют доступ к файлам и др., в которых изменение параметра функции может нанести ущерб конфиденциальности, целостности и доступности.

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

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

Автоматизированный поиск уязвимостей

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

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

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

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

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

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

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

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

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

Колонка эксперта

Кибервойны: кибероружие

Петр
Ляпин

Начальник службы информационной безопасности, ООО “НИИ ТНН” (“Транснефть”)

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

Во-первых, война – международное явление, в котором участвуют два или более государства. Война подчиняется своим законам. Один из них гласит: "воюющие не пользуются неограниченным правом в выборе средств нанесения вреда неприятелю" 1 .

Во-вторых, давно канули в Лету те времена, когда вопросы войны и мира конфликтующие стороны могли решать самостоятельно. В условиях глобализации война становится делом всего международного сообщества. Более того, есть вполне действенный стабилизационный механизм – Совбез ООН. Однако в настоящий момент применять его к конфликтам в киберпространстве крайне затруднительно.

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

Удачным видится определение кибероружия, данное профессором МГЮА В.А. Батырем: технические и программные средства поражения (устройства, программные коды), созданные государственными структурами, которые конструктивно предназначены для воздействия на программируемые системы, эксплуатацию уязвимостей в системах передачи и обработки информации или программно-технических системах с целью уничтожения людей, нейтрализации технических средств, либо разрушения объектов инфраструктуры противника 2 . Это определение во многом соответствует объективной действительности – не всякий "удачный вирус" есть кибероружие.

Так, к кибероружию можно отнести: Stuxnet и Flame, ботнеты, используемые для распределенных атак, массово внедряемые на этапе производства элементной базы аппаратные и программные закладки. Последнее, к слову, серьезнейшая проблема, масштаб которой невозможно переоценить. Достаточно взглянуть на перечень закладок АНБ США (от коммутаторов до USB-кабелей), опубликованный немецким СМИ Spiegel в декабре 2013 г. Смартфоны, ТВ, холодильники и прочая бытовая техника, подключенная к Интернету, вообще стирает всякие границы прогнозов.

___________________________________________
1 Дополнительный протокол I 1977 г. к Женевским конвенциям о защите жертв войны 1949 г.
2 Статья В.А. Батыря в Евразийском юридическом журнале (2014, №2) “Новые вызовы XXI в. в сфере развития средств вооруженной борьбы".

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

Обзор кода (code review) – один из самых старых и надежных методов выявления дефектов. Он заключается в совместном внимательном чтении исходного кода и высказывании рекомендаций по его улучшению. В процессе чтения кода выявляются ошибки или участки кода, которые могут стать ошибочными в будущем. Также считается, что автор кода во время обзора не должен давать объяснений, как работает та или иная часть программы. Алгоритм работы должен быть понятен непосредственно из текста программы и комментариев. Если это условие не выполняется, то код должен быть доработан.

Как правило, обзор кода хорошо работает, так как программисты намного легче замечают ошибки в чужом коде. Более подробно с методикой обзора кода можно познакомиться в замечательной книге Стива Макконнелла "Совершенный код" (Steve McConnell, "Code Complete") .

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

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

Задачи, решаемые программами статического анализа кода можно разделить на 3 категории:

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

Другие преимущества статического анализа кода:

• Полное покрытие кода. Статические анализаторы проверяют даже те фрагменты кода, которые получают управление крайне редко. Такие участки кода, как правило, не удается протестировать другими методами. Это позволяет находить дефекты в обработчиках редких ситуаций, в обработчиках ошибок или в системе логирования.
• Статический анализ не зависит от используемого компилятора и среды, в которой будет выполняться скомпилированная программа. Это позволяет находить скрытые ошибки, которые могут проявить себя только через несколько лет. Например, это ошибки . Такие ошибки могут проявить себя при смене версии компилятора или при использовании других ключей для оптимизации кода. Другой интересный пример скрытых ошибок приводится в статье " ".
• Можно легко и быстро обнаруживать опечатки и . Как правило, нахождение этих ошибок другими способами является кране неэффективной тратой времени и усилий. Обидно после часа отладки обнаружить, что ошибка заключается в выражении вида "strcmp(A, A)". Обсуждая типовые ошибки, про такие ляпы, как правило, не вспоминают. Но на практике на их выявление тратится существенное время.

Недостатки статического анализа кода

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

Ошибки, обнаруживаемые статическими анализаторами весьма разнообразны. Вот, например, которые реализованы в инструменте PVS-Studio. Некоторые анализаторы специализируются на определенной области или типах дефектов. Другие, поддерживают определенные стандарты кодирование, например MISRA-C:1998, MISRA-C:2004, Sutter-Alexandrescu Rules, Meyers-Klaus Rules и так далее.