С оригиналом статьи можно познакомится, воспользовавшись Wayback Machine - Internet Archive: Static Code Analysis .
Поскольку все статьи на нашем сайте представлены на русском и английском языке, то мы выполнили перевод статьи Static Code Analysis на русский язык. А заодно решили опубликовать её на Хабре. Здесь уже публиковался пересказ этой статьи . Но уверен, многим будет интересно прочитать именно перевод.
Самым главным своим достижением в качестве программиста за последние годы я считаю знакомство с методикой статического анализа кода и ее активное применение. Дело даже не столько в сотнях серьезных багов, не допущенных в код благодаря ей, сколько в перемене, вызванной этим опытом в моем программистском мировоззрении в отношении вопросов надежности и качества программного обеспечения.
Сразу нужно заметить, что нельзя все сводить к качеству, и признаться в этом вовсе не означает предать какие-то свои моральные принципы. Ценность
имеет создаваемый вами продукт в целом, а качество кода - лишь один из ее компонентов наравне со стоимостью, функциональными возможностями и прочими характеристиками. Миру известно множество супер-успешных и уважаемых игровых проектов, напичканных багами и без конца падающих; да и глупо было бы подходить к написанию игры с той же серьезностью, с какой создают ПО для космических шаттлов. И все же качество - это, несомненно, важный компонент.
Я всегда старался писать хороший код. По своей натуре я похож на ремесленника, которым движет желание непрерывно что-то улучшать. Я прочел груды книг со скучными названиями глав типа «Стратегии, стандарты и планы качества», а работа в Armadillo Aerospace открыла мне дорогу в совершенно иной, отличный от предшествующего опыта мир разработки ПО с повышенными требованиями к безопасности.
Более десяти лет назад, когда мы занимались разработкой Quake 3, я купил лицензию на PC-Lint и пытался применять его в работе: привлекала идея автоматического обнаружения дефектов в коде. Однако необходимость запуска из командной строки и просмотра длинных списков диагностических сообщений отбили у меня охоту пользоваться этим инструментом, и я вскоре отказался от него.
С тех пор и количество программистов, и размер кодовой базы выросли на порядок, а акцент в программировании сместился с языка C на C++. Все это подготовило намного более благодатную почву для программных ошибок. Несколько лет назад, прочитав подборку научных статей о современном статическом анализе кода, я решил проверить, как изменилось положение дел в этой области за последние десять лет с тех пор, как я попробовал работать с PC-Lint.
На тот момент код у нас компилировался на 4-ом уровне предупреждений, при этом выключенными мы оставляли лишь несколько узкоспециальных диагностик. С таким подходом - заведомо рассматривать каждое предупреждение, как ошибку - программисты были вынуждены неукоснительно придерживаться данной политики. И хотя в нашем коде можно было отыскать несколько пыльных уголков, в которых с годами скопился всякий «мусор», в целом он был довольно современным. Мы считали, что у нас вполне неплохая кодовая база.
Coverity
Началось все с того, что я связался с Coverity и подписался на пробную диагностику нашего кода их инструментом. Это серьезная программа, стоимость лицензии зависит от общего количества строк кода, и мы остановились на цене, выраженной пятизначным числом. Показывая нам результаты анализа, эксперты из Coverity отметили, что наша база оказалась одной из самых чистых в своей «весовой категории» из всех, что им доводилось видеть (возможно, они говорят это всем клиентам, чтобы приободрить их), однако отчет, который они нам передали, содержал около сотни проблемных мест. Такой подход сильно отличался от моего предыдущего опыта работы с PC-Lint. Соотношение сигнал/шум в данном случае оказался чрезвычайно высок: большинство из выданных Coverity предупреждений действительно указывали на явно некорректные участки кода, которые могли иметь серьезные последствия.Этот случай буквально открыл мне глаза на статический анализ, но высокая цена всего удовольствия некоторое время удерживала от покупки инструмента. Мы подумали, что в оставшемся до релиза коде у нас будет не так много ошибок.
Microsoft /analyze
Не исключено, что я, в конце концов, решился бы купить Coverity, но пока я размышлял над этим, Microsoft пресекли мои сомнения, реализовав новую функцию /analyze в 360 SDK. /Analyze прежде был доступен в качестве компонента топовой, безумно дорогой версии Visual Studio, а потом вдруг достался бесплатно каждому разработчику под xbox 360. Я так понимаю, о качестве игр на 360-й платформе Microsoft печется больше, чем о качестве ПО под Windows. :-)С технической точки зрения анализатор Microsoft всего лишь проводит локальный анализ, т.е. он уступает глобальному анализу Coverity, однако когда мы его включили, он вывалил горы сообщений - намного больше, чем выдал Coverity. Да, там было много ложных срабатываний, но и без них нашлось немало всяких страшных, по-настоящему жутких бяк.
Я потихоньку приступил к правке кода - прежде всего, занялся своим собственным, затем системным, и, наконец, игровым. Работать приходилось урывками в свободное время, так что весь процесс затянулся на пару месяцев. Однако эта задержка имела и свой побочный полезный эффект: мы убедились, что /analyze действительно отлавливает важные дефекты. Дело в том, что одновременно с моими правками наши разработчики устроили большую многодневную охоту за багами, и выяснилось, что каждый раз они нападали на след какой-нибудь ошибки, уже помеченной /analyze, но еще не исправленной мной. Помимо этого, были и другие, менее драматичные, случаи, когда отладка приводила нас к коду, уже помеченному /analyze. Все это были настоящие ошибки.
В конце концов, я добился, чтобы весь использованный код скомпилировался в запускаемый файл под 360-ю платформу без единого предупреждения при включенном /analyze, и установил такой режим компиляции в качестве стандартного для 360-сборок. После этого код у каждого программиста, работающего на той же платформе, всякий раз при компиляции проверялся на наличие ошибок, так что он мог сразу править баги по мере их внесения в программу вместо того, чтобы потом ими занимался я. Конечно, из-за этого процесс компиляции несколько замедлился, но /analyze - однозначно самый быстрый инструмент из всех, с которыми мне доводилось иметь дело, и, поверьте мне, оно того стоит.
Однажды мы в каком-то проекте случайно выключили статический анализ. Прошло несколько месяцев, и когда я заметил это и снова включил его, инструмент выдал кучу новых предупреждений об ошибках, внесенных в код за это время. Подобным же образом программисты, работающие только под PC или PS3, вносят в репозиторий код с ошибками и пребывают в неведении, пока не получат письмо с отчетом о «неудачной 360-сборке». Эти примеры наглядно демонстрируют, что в процессе своей повседневной деятельности разработчики раз за разом совершают ошибки определенных видов, и /analyze надежно уберегал нас от большей их части.
PVS-Studio
Поскольку мы могли использовать /analyze только на 360-коде, большой объем нашей кодовой базы по-прежнему оставался не покрытым статическим анализом - это касалось кода под платформы PC и PS3, а также всех программ, работающих только на PC.Следующим инструментом, с которым я познакомился, был PVS-Studio . Он легко интегрируется в Visual Studio и предлагает удобный демо-режим (попробуйте сами!). В сравнении с /analyze PVS-Studio ужасно медлителен, но он сумел выловить некоторое количество новых критических багов, причем даже в том коде, который был уже полностью вычищен с точки зрения /analyze. Помимо очевидных ошибок PVS-Studio отлавливает множество других дефектов, которые представляют собой ошибочные программистские клише, пусть и кажущиеся на первый взгляд нормальным кодом. Из-за этого практически неизбежен некоторый процент ложных срабатываний, но, черт возьми, в нашем коде такие шаблоны нашлись, и мы их поправили.
На сайте PVS-Studio можно найти большое количество замечательных статей об инструменте, и многие из них содержат примеры из реальных open-source проектов, иллюстрирующие конкретно те виды ошибок, о которых идет речь в статье. Я думал, не вставить ли сюда несколько показательных диагностических сообщений, выдаваемых PVS-Studio, но на сайте уже появились намного более интересные примеры. Так что посетите страничку и посмотрите сами. И да - когда будете читать эти примеры, не надо ухмыляться и говорить, что вы бы так никогда не написали.
PC-Lint
В конце концов, я вернулся к варианту с использованием PC-Lint в связке с Visual Lint для интеграции в среду разработки. В соответствии с легендарной традицией мира Unix инструмент можно настроить на выполнение практически любой задачи, однако интерфейс его не очень дружественен и его нельзя просто так «взять и запустить». Я приобрел набор из пяти лицензий, но его освоение оказалось настолько трудоемким, что, насколько я знаю, все остальные разработчики от него в итоге отказались. Гибкость действительно имеет свои преимущества - так, например, мне удалось настроить его для проверки всего нашего кода под платформу PS3, хотя это и отняло у меня немало времени и усилий.И снова в том коде, который был уже чист с точки зрения /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 Написана на С++ Операционная система Кроссплатформенное Языки интерфейса английский … Википедия
Анализ бинарного кода, то есть кода, который выполняется непосредственно машиной, – нетривиальная задача. В большинстве случаев, если надо проанализировать бинарный код, его восстанавливают сначала посредством дизассемблирования, а потом декомпиляции в некоторое высокоуровневое представление, а дальше уже анализируют то, что получилось.
Здесь надо сказать, что код, который восстановили, по текстовому представлению имеет мало общего с тем кодом, который был изначально написан программистом и скомпилирован в исполняемый файл. Восстановить точно бинарный файл, полученный от компилируемых языков программирования типа C/C++, Fortran, нельзя, так как это алгоритмически неформализованная задача. В процессе преобразования исходного кода, который написал программист, в программу, которую выполняет машина, компилятор выполняет необратимые преобразования.
В 90-е годы прошлого века было распространено суждение о том, что компилятор как мясорубка перемалывает исходную программу, и задача восстановить ее схожа с задачей восстановления барана из сосиски.
Однако не так все плохо. В процессе получения сосиски баран утрачивает свою функциональность, тогда как бинарная программа ее сохраняет. Если бы полученная в результате сосиска могла бегать и прыгать, то задачи были бы схожие.
Итак, раз бинарная программа сохранила свою функциональность, можно говорить, что есть возможность восстановить исполняемый код в высокоуровневое представление так, чтобы функциональность бинарной программы, исходного представления которой нет, и программы, текстовое представление которой мы получили, были эквивалентными.
По определению две программы функционально эквивалентны, если на одних и тех же входных данных обе завершают или не завершают свое выполнение и, если выполнение завершается, выдают одинаковый результат.
Задача дизассемблирования обычно решается в полуавтоматическом режиме, то есть специалист делает восстановление вручную при помощи интерактивных инструментов, например, интерактивным дизассемблером IdaPro , radare или другим инструментом. Дальше также в полуавтоматическом режиме выполняется декомпиляция. В качестве инструментального средства декомпиляции в помощь специалисту используют HexRays , SmartDecompiler или другой декомпилятор, который подходит для решения данной задачи декомпиляции.
Восстановление исходного текстового представления программы из byte-кода можно сделать достаточно точным. Для интерпретируемых языков типа Java или языков семейства.NET, трансляция которых выполняется в byte-код, задача декомпиляции решается по-другому. Этот вопрос мы в данной статье не рассматриваем.
Итак, анализировать бинарные программы можно посредством декомпиляции. Обычно такой анализ выполняют, чтобы разобраться в поведении программы с целью ее замены или модификации.
Из практики работы с унаследованными программами
Некоторое программное обеспечение, написанное 40 лет назад на семействе низкоуровневых языков С и Fortran, управляет оборудованием по добыче нефти. Сбой этого оборудования может быть критичным для производства, поэтому менять ПО крайне нежелательно. Однако за давностью лет исходные коды были утрачены.Новый сотрудник отдела информационной безопасности, в обязанности которого входило понимать, как что работает, обнаружил, что программа контроля датчиков с некоторой регулярностью что-то пишет на диск, а что пишет и как эту информацию можно использовать, непонятно. Также у него возникла идея, что мониторинг работы оборудования можно вывести на один большой экран. Для этого надо было разобраться, как работает программа, что и в каком формате она пишет на диск, как эту информацию можно интерпретировать.
Для решения задачи была применена технология декомпиляции с последующим анализом восстановленного кода. Мы сначала дизассемблировали программные компоненты по одному, дальше сделали локализацию кода, который отвечал за ввод-вывод информации, и стали постепенно от этого кода выполнять восстановление, учитывая зависимости. Затем была восстановлена логика работы программы, что позволило ответить на все вопросы службы безопасности относительно анализируемого программного обеспечения.
Если требуется анализ бинарной программы с целью восстановления логики ее работы, частичного или полного восстановления логики преобразования входных данных в выходные и т.д., удобно делать это с помощью декомпилятора.
Помимо таких задач, на практике встречаются задачи анализа бинарных программ по требованиям информационной безопасности. При этом у заказчика не всегда есть понимание, что этот анализ очень трудоемкий. Казалось бы, сделай декомпиляцию и прогони получившийся код статическим анализатором. Но в результате качественного анализа практически никогда не получится.
Во-первых, найденные уязвимости надо уметь не только находить, но и объяснять. Если уязвимость была найдена в программе на языке высокого уровня, аналитик или инструментальное средство анализа кода показывают в ней, какие фрагменты кода содержат те или иные недостатки, наличие которых стало причиной появления уязвимости. Что делать, если исходного кода нет? Как показать, какой код стал причиной появления уязвимости?
Декомпилятор восстанавливает код, который «замусорен» артефактами восстановления, и делать отображение выявленной уязвимости на такой код бесполезно, все равно ничего не понятно. Более того, восстановленный код плохо структурирован и поэтому плохо поддается инструментальным средствам анализа кода. Объяснять уязвимость в терминах бинарной программы тоже сложно, ведь тот, для кого делается объяснение, должен хорошо разбираться в бинарном представлении программ.
Во-вторых, бинарный анализ по требованиям ИБ надо проводить с пониманием, что делать с получившимся результатом, так как поправить уязвимость в бинарном коде очень сложно, а исходного кода нет.
Несмотря на все особенности и сложности проведения статического анализа бинарных программ по требованиям ИБ, ситуаций, когда такой анализ выполнять нужно, много. Если исходного кода по каким-то причинам нет, а бинарная программа выполняет функционал, критичный по требованиям ИБ, ее надо проверять. Если уязвимости обнаружены, такое приложение надо оправлять на доработку, если это возможно, либо делать для него дополнительную «оболочку», которая позволит контролировать движение чувствительной информации.
Когда уязвимость спряталась в бинарном файле
Если код, который выполняет программа, имеет высокий уровень критичности, даже при наличии исходного текста программы на языке высокого уровня, полезно сделать аудит бинарного файла. Это поможет исключить особенности, которые может привнести компилятор, выполняя оптимизирующие преобразования. Так, в сентябре 2017 года широко обсуждали оптимизационное преобразование, выполненное компилятором Clang. Его результатом стал вызов функции , которая никогда не должна вызываться. #include
В результате оптимизационных преобразований компилятором будет получен вот такой ассемблерный код. Пример был скомпилирован под ОС Linux X86 c флагом -O2.
Text .globl NeverCalled .align 16, 0x90 .type NeverCalled,@function NeverCalled: # @NeverCalled retl .Lfunc_end0: .size NeverCalled, .Lfunc_end0-NeverCalled .globl main .align 16, 0x90 .type main,@function main: # @main subl $12, %esp movl $.L.str, (%esp) calll system addl $12, %esp retl .Lfunc_end1: .size main, .Lfunc_end1-main .type .L.str,@object # @.str .section .rodata.str1.1,"aMS",@progbits,1 .L.str: .asciz "rm -rf /" .size .L.str, 9
В исходном коде есть undefined behavior . Функция NeverCalled() вызывается из-за оптимизационных преобразований, которые выполняет компилятор. В процессе оптимизации он скорее всего выполняет анализ аллиасов , и в результате функция Do() получает адрес функции NeverCalled(). А так как в методе main() вызывается функция Do(), которая не определена, что и есть неопределенное стандартом поведение (undefined behavior), получается такой результат: вызывается функция EraseAll(), которая выполняет команду «rm -rf /».
Следующий пример: в результате оптимизационных преобразований компилятора мы лишились проверки указателя на NULL перед его разыменованием.
#include
Так как в строке 3 выполняется разыменование указателя, компилятор предполагает, что указатель ненулевой. Дальше строка 4 была удалена в результате выполнения оптимизации «удаление недостижимого кода» , так как сравнение считается избыточным, а после и строка 3 была удалена компилятором в результате оптимизации «удаление мертвого кода» (dead code elimination). Остается только строка 5. Ассемблерный код, полученный в результате компиляции gcc 7.3 под ОС Linux x86 с флагом -O2, приведен ниже.
Text .p2align 4,15 .globl _Z7CheckerPi .type _Z7CheckerPi, @function _Z7CheckerPi: movl 4(%esp), %eax movl $8, (%eax) ret
Приведенные выше примеры работы оптимизации компилятора – результат наличия в коде undefined behavior UB. Однако это вполне нормальный код, который большинство программистов примут за безопасный. Сегодня программисты уделяют время исключению неопределенного поведения в программе, тогда как еще 10 лет назад не обращали на это внимания. В результате унаследованный код может содержать уязвимости, связанные с наличием UB.
Большинство современных статических анализаторов исходного кода не обнаруживают ошибки, связанные с UB. Следовательно, если код выполняет критичный по требованиям информационной безопасности функционал, надо проверять и его исходники, и непосредственно тот код, который будет выполняться.
При написании кода на C и C++ люди допускают ошибки. Многие из этих ошибок находятся благодаря -Wall , ассертам, тестам, дотошному code review, предупреждениям со стороны IDE, сборкой проекта разными компиляторами под разные ОС, работающие на разном железе, и так далее. Но даже при использовании всех этих мер ошибки часто остаются незамеченными. Немного улучшить положение дел позволяет статический анализ кода. В этой заметке мы познакомимся с некоторыми инструментами для произведения этого самого статического анализа.
CppCheck
CppCheck является бесплатным кроссплатформенным статическим анализатором с открытым исходным кодом (GPLv3). Он доступен в пакетах многих *nix систем из коробки. Также CppCheck умеет интегрироваться со многими IDE. На момент написания этих строк CppCheck является живым, развивающимся проектом.
Пример использования:
cppcheck ./ src/
Пример вывода:
: (error) Common realloc mistake: "numarr" nulled but not
freed upon failure
: (error) Dangerous usage of "n" (strncpy doesn"t always
null-terminate it)
CppCheck хорош тем, что он довольно быстро работает. Нет повода не добавить его прогон в систему непрерывной интеграции , чтобы исправлять прямо все-все-все выводимые им предупреждения. Даже несмотря на то, что многие из них на практике оказываются ложно-положительными срабатываниями.
Clang Static Analyzer
Еще один бесплатный кроссплатформенный статический анализатор с открытыми исходным кодом. Является частью так называемого LLVM-стэка . В отличие от CppCheck работает существенно медленнее, но и ошибки находит куда более серьезные.
Пример построения отчета для PostgreSQL :
CC
=/
usr/
local/
bin/
clang38 CFLAGS
="-O0 -g"
\
./
configure --enable-cassert
--enable-debug
gmake
clean
mkdir
../
report-201604
/
/
usr/
local/
bin/
scan-build38 -o
../
report-201604
/
gmake
-j2
Пример построения отчета для ядра FreeBSD :
# использование своего MAKEOBJDIR позволяет собирать ядро не под рутом
mkdir
/
tmp/
freebsd-obj
# сама сборка
COMPILER_TYPE
=clang /
usr/
local/
bin/
scan-build38 -o
../
report-201604
/
\
make
buildkernel KERNCONF
=GENERIC MAKEOBJDIRPREFIX
=/
tmp/
freebsd-obj
Идея, как несложно догадаться, заключается в том, чтобы сделать clean, а затем запустить сборку под scan-build.
На выходе получается очень симпатичный HTML-отчет с подробнейшими пояснениями, возможностью фильтровать ошибки по их типу, и так далее. Обязательно посмотрите на офсайте как это примерно выглядит.
В данном контексте не могу не отметить, что в мире Clang/LLVM есть еще и средства динамического анализа, так называемые «санитайзеры». Их много, они находят очень крутые ошибки и работают быстрее, чем Valgrind (правда, только под Linux). К сожалению, обсуждение санитайзеров выходит за рамки настоящей заметки, поэтому ознакомьтесь с ними самостоятельно .
PVS-Studio
Закрытый статический анализатор, распространяемый за деньги. PVS-Studio работает только под Windows и только с Visual Studio. Есть многочисленные сведения о существовании Linux-версии, но на официальном сайте она не доступна. Насколько я понял, цена лицензии обсуждается индивидуально с каждым клиентом. Доступен триал.
Я протестировал PVS-Studio 6.02 на Windows 7 SP1 работающей под KVM с установленной Visual Studio 2013 Express Edition. Во время установки PVS-Studio также дополнительно скачался.NET Framework 4.6. Выглядит это примерно так. Вы открываете проект (я тестировал на PostgreSQL) в Visual Studio, в PVS-Studio жмете «сейчас я начну собирать проект», затем в Visual Studio нажимаете Build, по окончании сборки в PVS-Studio жмете «я закончил» и смотрите отчет.
PVS-Studio действительно находит очень крутые ошибки, которые Clang Static Analyzer не видит (например). Также очень понравился интерфейс, позволяющий сортировать и фильтровать ошибки по их типу, серьезности, файлу, в котором они были найдены, и так далее.
С одной стороны, печалит, что чтобы использовать PVS-Studio, проект должен уметь собираться под Windows. С другой стороны, использовать в проекте CMake и собирать-тестировать его под разными ОС, включая Windows, при любом раскладе является очень неплохой затеей. Так что, пожалуй, это не такой уж и большой недостаток. Кроме того, по следующим ссылкам можно найти кое-какие подсказки касательно того, как людям удавалось прогонять PVS-Studio на проектах, которые не собираются под Windows: раз , два , три , четыре .
Дополнение: Попробовал бета-версию PVS-Studio для Linux. Пользоваться ею оказалось очень просто . Создаем pvs.conf примерно такого содержания:
lic-file=/home/afiskon/PVS-Studio.lic
output-file=/home/afiskon/postgresql/pvs-output.log
Затем говорим:
make
clean
./
configure ...
pvs-studio-analyzer trace --
make
# будет создан большой (у меня ~40 Мб) файл strace_out
pvs-studio-analyzer analyze --cfg
./
pvs.conf
plog-converter -t
tasklist -o
result.task pvs-output.log
Дополнение: PVS-Studio для Linux вышел из беты и теперь доступен всем желающим .
Coverity Scan
Coverity считается одним из самых навороченных (а следовательно и дорогих) статических анализаторов. К сожалению, на официальном сайте невозможно скачать даже его триал-версию. Можно заполнить форму, и если вы какой-нибудь IBM, с вами может быть свяжутся. При очень сильном желании Coverity какой-нибудь доисторической версии можно найти через неофициальные каналы. Он бывает для Windows и Linux, работает примерно по тому же принципу, что и PVS-Studio. Но без серийника или лекарства отчеты Coverity вам не покажет. А чтобы найти серийник или лекарство, нужно иметь не просто очень сильное желание, а очень-очень-очень сильное.
К счастью, у Coverity есть SaaS версия — Coverity Scan. Мало того, что Coverity Scan доступен для простых смертных, он еще и совершенно бесплатен. Привязки к конкретной платформе нет. Однако анализировать с помощью Coverity Scan разрешается только открытые проекты.
Вот как это работает. Вы регистрируете свой проект через веб-интерфейс (или присоединяетесь к уже существующему, но это менее интересный кейс). Чтобы посмотреть отчеты, нужно пройти модерацию, которая занимает 1-2 рабочих дня.
Отчеты строятся таким образом. Сначала вы локально собираете свой проект под специальной утилитой Coverity Build Tool. Утилита эта аналогична scan-build из Clang Static Analyzer и доступна под все мыслимые платформы, включая всякую экзотику типа FreeBSD или даже NetBSD.
Установка Coverity Build Tool:
tar
-xvzf
cov-analysis-linux64-7.7.0.4.tar.gz
export
PATH
=/
home/
eax/
temp/
cov-analysis-linux64-7.7.0.4/
bin:$PATH
Готовим тестовый проект (я использовал код из заметки Продолжаем изучение OpenGL: простой вывод текста):
git clone
git
@
github.com:afiskon/
c-opengl-text.git
cd
c-opengl-text
git submodule
init
git submodule
update
mkdir
build
cd
build
cmake
..
Затем собираем проект под cov-build:
cov-build --dir cov-int make -j2 demo emdconv
Важно! Не меняйте название директории cov-int.
Архивируем директорию cov-int:
tar -cvzf c-opengl-text.tgz cov-int
Заливаем архив через форму Upload a Project Build. Также на сайте Coverity Scan есть инструкции по автоматизации этого шага при помощи curl. Ждем немного, и можно смотреть результаты анализа. Примите во внимание, что чтобы пройти модерацию, нужно отправить на анализ хотя бы один билд.
Ошибки Coverity Scan ищет очень хорошо. Уж точно лучше, чем Clang Static Analyzer. При этом ложно-положительные срабатывания есть, но их намного меньше. Что удобно, в веб-интерфейсе есть что-то вроде встроенного багтрекера, позволяющего присваивать ошибкам серьезность, ответственного за их исправление и подобные вещи. Видно, какие ошибки новые, а какие уже были в предыдущих билдах. Ложно-положительные срабатывания можно отметить как таковые и скрыть.
Заметьте, что чтобы проанализировать проект в Coverity Scan, не обязательно быть его владельцем. Мне лично вполне успешно удалось проанализировать код PostgreSQL без присоединения к уже существующему проекту. Думается также, что при сильном желании (например, используя сабмодули Git), можно подсунуть на проверку немного и не очень-то открытого кода.
Заключение
Вот еще несколько статических анализаторов, не попавших в обзор:
Каждый из рассмотренных анализаторов находят такие ошибки, которые не находят другие. Поэтому в идеале лучше использовать их сразу все. Делать это вот прямо постоянно, скорее всего, объективно не получится. Но делать хотя бы один прогон перед каждым релизом точно будет не лишним. При этом Clang Static Analyzer выглядит наиболее универсальным и при этом достаточно мощным. Если вас интересует один анализатор, который нужно обязательно использовать в любом проекте, используйте его. Но все же я бы рекомендовал дополнительно использовать как минимум PVS-Studio или Coverity Scan.
А какие статические анализаторы вы пробовали и/или регулярно использовали и каковы ваши впечатления от них?
Аннотация
Статический анализ - это способ проверки исходного кода программы на корректность. Процесс статического анализа состоит из трех этапов. Сначала анализируемый код разбивается на лексемы - константы, идентификаторы, и т. д. Эта операция выполняется лексером. Затем лексемы передаются синтаксическому анализатору, который выстраивает по этим лексемам дерево кода. Наконец, проводится статический анализ построенного дерева. В данной обзорной статье приведено описание трех методов статического анализа: анализ с обходом дерева кода, анализ потока данных и анализ потока данных с выбором путей.
Введение
Тестирование является важной частью процесса разработки приложений. Существует множество различных видов тестирования, в том числе и два вида, касающиеся программного кода: статический анализ и динамический анализ.
Динамический анализ проводится над исполняемым кодом скомпилированной программы. При этом проверяется только поведение, зависящее от пользователя, т.е. только тот код, который выполняется во время теста. Динамический анализатор может находить утечки памяти, измерять производительность программы, получать стек вызовов и т. п.
Статический анализ позволяет проверять исходный код программы до ее выполнения. В частности, любой компилятор проводит статический анализ при компиляции. Однако, в больших реальных проектах зачастую возникает необходимость проверить весь код на предмет соответствия некоторым дополнительным требованиям. Эти требования могут быть весьма разнообразны, начиная от правил именования переменных и заканчивая мобильностью (например, код должен благополучно выполняться на платформах х86 и х64). Наиболее распространенными требованиями являются:
- Надежность - меньшее количество ошибок в тестируемой программе.
- Удобство сопровождения - более понятный код, который легко изменять и усовершенствовать.
- Мобильность - гибкость тестируемой программы при запуске на различных платформах.
- Удобочитаемость - сокращение времени, необходимого для понимания кода.
Требования можно разбить на правила и рекомендации. Правила, в отличие от рекомендаций, обязательны для выполнения. Аналогом правил и рекомендаций являются ошибки и предупреждения, выдаваемые анализаторами кода, встроенными в стандартные компиляторы.
Правила и рекомендации, в свою очередь, формируют стандарт кодирования. Этот стандарт определяет то, как программист должен писать программный код. Стандарты кодирования применяются в организациях, занимающихся разработкой программного обеспечения.
Статический анализатор находит строки исходного кода, которые, предположительно, не соответствуют принятому стандарту кодирования и отображает диагностические сообщения, чтобы разработчик мог понять причину проблемы. Процесс статического анализа аналогичен компиляции, только при этом не генерируется ни объектный, ни исполняемый код. В данном обзоре приводится пошаговое описание процесса статического анализа.
Процесс анализа
Процесс статического анализа состоит из двух основных шагов: создания дерева кода (также называемого ) и анализа этого дерева.
Для того чтобы проанализировать исходный код, анализатор должен сначала "понять" этот код, т.е. разобрать его по составу и создать структуру, описывающую анализируемый код в удобной форме. Эта форма и называется деревом кода. Чтобы проверить, соответствует ли код стандарту кодирования, необходимо построить такое дерево.
В общем случае дерево строится только для анализируемого фрагмента кода (например, для какой-то конкретной функции). Для того чтобы создать дерево код обрабатывается сначала , а затем .
Лексер отвечает за разбиение входных данных на отдельные лексемы, а также за определение типа этих лексем и их последовательную передачу синтаксическому анализатору. Лексер считывает текст исходного кода строку за строкой, а затем разбивает полученные строки на зарезервированные слова, идентификаторы и константы, называемые лексемами. После получения лексемы лексер определяет ее тип.
Рассмотрим примерный алгоритм определения типа лексемы.
Если первый символ лексемы является цифрой, лексема считается числом, если этот символ является знаком "минус", то это - отрицательное число. Если лексема является числом, она может быть числом целым или дробным. Если в числе содержится буква E, определяющая экспоненциальное представление, или десятичная точка, число считается дробным, в противном случае - целым. Заметим, что при этом может возникнуть лексическая ошибка - если в анализируемом исходном коде содержится лексема "4xyz", лексер сочтет ее целым числом 4. Это породит синтаксическую ошибку, которую сможет выявить синтаксический анализатор. Однако подобные ошибки могут обнаруживаться и лексером.
Если лексема не является числом, она может быть строкой. Строковые константы могут распознаваться по одинарным кавычкам, двойным кавычкам, или каким-либо другим символам, в зависимости от синтаксиса анализируемого языка.
Наконец, если лексема не является строкой, она должна быть идентификатором, зарезервированным словом, или зарезервированным символом. Если лексема не подходит и под эти категории, возникает лексическая ошибка. Лексер не будет обрабатывать эту ошибку самостоятельно - он только сообщит синтаксическому анализатору, что обнаружена лексема неизвестного типа. Обработкой этой ошибки займется синтаксический анализатор.
Синтаксический анализатор понимает грамматику языка. Он отвечает за обнаружение синтаксических ошибок и за преобразование программы, в которой такие ошибки отсутствуют, в структуры данных, называемые деревьями кода. Эти структуры в свою очередь поступают на вход статического анализатора и обрабатываются им.
В то время как лексер понимает лишь синтаксис языка, синтаксический анализатор также распознает и контекст. Например, объявим функцию на языке Си:
Int Func(){return 0;}
Лексер обработает эту строку и разобьет ее на лексемы как показано в таблице 1:
Таблица 1 - Лексемы строки "int Func(){return 0};".
Строка будет распознана как 8 корректных лексем, и эти лексемы будут переданы синтаксическому анализатору.
Этот анализатор просмотрит контекст и выяснит, что данный набор лексем является объявлением функции, которая не принимает никаких параметров, возвращает целое число, и это число всегда равно 0.
Синтаксический анализатор выяснит это, когда создаст дерево кода из лексем, предоставленных лексером, и проанализирует это дерево. Если лексемы и построенное из них дерево будут сочтены правильными - это дерево будет использовано при статическом анализе. В противном случае синтаксический анализатор выдаст сообщение об ошибке.
Однако процесс построения дерева кода не сводится к простому представлению лексем в виде дерева. Рассмотрим этот процесс подробнее.
Дерево кода
Дерево кода представляет самую суть поданных на вход данных в форме дерева, опуская несущественные детали синтаксиса. Такие деревья отличаются от конкретных деревьев синтаксиса тем, что в них нет вершин, представляющих знаки препинания вроде точки с запятой, завершающей строку, или запятой, которая ставится между аргументами функции.
Синтаксические анализаторы, используемые для создания деревьев кода, могут быть написаны вручную, а могут и создаваться генераторами синтаксических анализаторов. Деревья кода обычно создаются снизу вверх.
При разработке вершин дерева в первую очередь обычно определяется уровень модульности. Иными словами, определяется, будут ли все конструкции языка представлены вершинами одного типа, различаемыми по значениям. В качестве примера рассмотрим представление бинарных арифметических операций. Один вариант - использовать для всех бинарных операций одинаковые вершины, одним из атрибутов которых будет тип операции, например, "+". Другой вариант - использовать для разных операций вершины различного типа. В объектно-ориентированном языке это могут быть классы вроде AddBinary, SubstractBinary, MultipleBinary, и т. п., наследуемые от абстрактного базового класса Binary.
В качестве примера разберем два выражения: 1 + 2 * 3 + 4 * 5 и 1+ 2 * (3 + 4) * 5 (см. рисунок 1).
Как видно из рисунка, оригинальный вид выражения может быть восстановлен при обходе дерева слева направо.
После того, как дерево кода создано и проверено, статический анализатор может определить, соответствует ли исходный код правилам и рекомендациям, указанным в стандарте кодирования.
Методы статического анализа
Существует множество различных методов , в частности, анализ с , анализ потока данных, анализ потока данных с выбором пути и т. д. Конкретные реализации этих методов различны в разных анализаторах. Тем не менее, статические анализаторы для различных языков программирования могут использовать один и тот же базовый код (инфраструктуру). Эти инфраструктуры содержат набор основных алгоритмов, которые могут использоваться в разных анализаторах кода вне зависимости от конкретных задач и анализируемого языка. Набор поддерживаемых методов и конкретная реализация этих методов, опять же, будет зависеть от конкретной инфраструктуры. Например, инфраструктура может позволять легко создавать анализатор, использующий обход дерева кода, но не поддерживать анализ потока данных .
Хотя все три перечисленные выше метода статического анализа используют дерево кода, построенное синтаксическим анализатором, эти методы различаются по своим задачам и алгоритмам.
Анализ с обходом дерева, как видно из названия, выполняется путем обхода дерева кода и проведения проверок на предмет соответствия кода принятому стандарту кодирования, указанному в виде набора правил и рекомендаций. Именно этот тип анализа проводят компиляторы.
Анализ потока данных можно описать как процесс сбора информации об использовании, определении и зависимостях данных в анализируемой программе. При анализе потока данных используется граф потока команд, генерируемый на основе дерева кода. Этот граф представляет все возможные пути выполнения данной программы: вершины обозначают "прямолинейные", без каких бы то ни было переходов, фрагменты кода, а ребра - возможную передачу управления между этими фрагментами. Поскольку анализ выполняется без запуска проверяемой программы, точно определить результат ее выполнения невозможно. Иными словами, невозможно выяснить, по какому именно пути будет передаваться управление. Поэтому алгоритмы анализа потока данных аппроксимируют возможное поведение, например, рассматривая обе ветви оператора if-then-else, или выполняя с определенной точностью тело цикла while. Ограничение точности существует всегда, поскольку уравнения потока данных записываются для некоторого набора переменных, и количество этих переменных должно быть ограничено, поскольку мы рассматриваем лишь программы с конечным набором операторов. Следовательно, для количества неизвестных всегда существует некий верхний предел, дающий ограничение точности. С точки зрения графа потока команд при статическом анализе все возможные пути выполнения программы считаются действительными. Из-за этого допущения при анализе потока данных можно получать лишь приблизительные решения для ограниченного набора задач .
Описанный выше алгоритм анализа потока данных не различает путей, поскольку все возможные пути, вне зависимости от того реальны они, или нет, будут ли они выполняться часто, или редко, все равно приводят к решению. На практике, однако, выполняется лишь малая часть потенциально возможных путей. Более того, самый часто выполняемый код, как правило, составляет еще меньшее подмножество всех возможных путей. Логично сократить анализируемый граф потока команд и уменьшить таким образом объем вычислений, анализируя лишь некоторое подмножество возможных путей. Анализ с выбором путей проводится по сокращенному графу потока команд, в котором нет невозможных путей и путей, не содержащих "опасного" кода. Критерии выбора путей различны в различных анализаторах. Например, анализатор может рассматривать лишь пути, содержащие объявления динамических массивов, считая такие объявления "опасными" согласно настройкам анализатора.
Заключение
Число методов статического анализа и самих анализаторов возрастает из года в год, и это означает, что интерес к статическим анализаторам кода растет. Причина заинтересованности заключается в том, что разрабатываемое программное обеспечение становится все более и более сложным и, следовательно, проверять код вручную становится невозможно.
В этой статье было приведено краткое описание процесса статического анализа и различных методов проведения такого анализа.
Библиографический список
- Dirk Giesen Philosophy and practical implementation of static analyzer tools . -Electronic data. -Dirk Giesen, cop. 1998.
- James Alan Farrell Compiler Basics . -Electronic data. -James Alan Farrell, cop 1995. -Access mode: http://www.cs.man.ac.uk/~pjj/farrell/compmain.html
- Joel Jones Abstract syntax tree implementation idioms . -Proceedings of the 10th Conference on Pattern Languages of Programs 2003, cop 2003.
- Ciera Nicole Christopher Evaluating Static Analysis Frameworks .- Ciera Nicole, cop. 2006.
- Leon Moonen A Generic Architecture for Data Flow Analysis to Support Reverse Engineering . - Proceedings of the 2nd International Workshop on the Theory and Practice of Algebraic Specifications, cop. 1997.