Анализ унаследованного кода, когда исходный код утрачен: делать или не делать? Использование статического и динамического анализа для повышения качества продукции и эффективности разработки Цели создания Системы

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

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

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

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

Большинство компиляторов (например, 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 и обнаруживать потенциальные проблемы, связанные с низким качеством кода.
  • АК-ВС

См. также

Примечания

Ссылки


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 Написана на С++ Операционная система Кроссплатформенное Языки интерфейса английский … Википедия

Введение

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

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

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

Существует методология защищенной разработки, предусматривающая встраивание процессов аудита и контроля кода на этапе создания программного продукта - SDL (Security Development Lifecycle, защищенный жизненный цикл разработки). Однако применить эту методологию может только разработчик программного обеспечения, если говорить о заказчиках, то SDL для них неприменим, так как процесс подразумевает перестройку алгоритмов создания кода и использовать его при приемке уже поздно. Кроме того, многие разработки затрагивают небольшую часть уже существующего кода, и в этом случае SDL также неприменим.

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

Классификация анализаторов исходного кода

Анализаторы исходного кода - класс программных продуктов, созданных для выявления и предотвращения эксплуатации программных ошибок в исходных кодах. Все продукты, направленные на анализ исходного кода, можно условно разделить на три типа:

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

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

Анализаторы могут содержать различные механизмы анализа, но наиболее распространенным и универсальным является статический анализ исходного кода - SAST (Static Application Security Testing), также существуют методы динамического анализа - DAST (Dynamic Application Security Testing), выполняющие проверки кода при его исполнении, и различные гибридные варианты, совмещающие разные типы анализов. Динамический анализ является самостоятельным методом проверки, который может расширять возможности статического анализа или применяться самостоятельно в тех случаях, когда доступ к исходным текстам отсутствует. В данном обзоре рассматриваются только статические анализаторы.

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

Принципы работы анализаторов исходного кода

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

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

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

Рисунок 1. Алгоритм работы анализатора исходных кодов

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

  • Собственная база уязвимостей и ошибок программирования - у каждого разработчика анализаторов исходных кодов есть свои отделы аналитики и исследований, которые готовят специализированные базы для анализа исходных текстов программ. Качество собственной базы - один из ключевых критериев, влияющий на общее качество работы продукта. Кроме того, собственная база должна быть динамической и постоянно обновляемой - новые векторы атак и эксплуатации уязвимостей, а также изменения в языках программирования и методах разработки требуют от разработчиков анализаторов выполнять постоянные обновления базы для сохранения высокого качества проверки. Продукты со статической необновляемой базой чаще всего проигрывают в сравнительных тестах.
  • Государственные базы ошибок программирования - существует ряд государственных баз уязвимостей, составлением и поддержкой которых занимаются регуляторы разных стран. К примеру, в США используется база CWE - Common Weakness Enumeration, обслуживанием которой занимается организация MITRE, поддерживаемая в том числе Министерством обороны США. В России пока отсутствует аналогичная база, но ФСТЭК России в будущем планирует дополнить свои базы уязвимостей и угроз базой по ошибкам программирования. Анализаторы уязвимостей реализуют поддержку базы CWE, встраивая ее в собственную базу уязвимостей или используя как отдельный механизм проверки.
  • Требования стандартов и рекомендации по защищенному программированию - существует как ряд государственных и отраслевых стандартов, описывающих требования к безопасной разработке приложений, так и ряд рекомендаций и «лучших практик» от мировых экспертов в области разработки и защиты программного обеспечения. Данные документы напрямую не описывают ошибки программирования, в отличие от CWE, но содержат перечень методов, которые могут быть преобразованы для использования в статическом анализаторе исходного кода.

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

Мировой рынок

На мировом рынке представлено множество различных анализаторов - как от известных вендоров в области безопасности, так и нишевых игроков, занимающихся только данным классом продуктов. Аналитический центр Gartner ведет классификацию и оценку анализаторов исходных кодов уже более пяти лет, при этом до 2011 года Gartner выделял отдельно статические анализаторы, о которых идет речь в данной статье, позднее объединив их в более высокий класс - средства проверки защищенности приложений (Application Security Testing).

В магическом квадранте Gartner в 2015 году лидерами рынка проверки защищенности являются компании HP, Veracode и IBM. При этом Veracode - единственная из компаний-лидеров, у которой отсутствует анализатор как программный продукт, а функциональность предоставляется только как услуга в облаке компании Veracode. Остальные компании-лидеры предлагают либо исключительно продукты, выполняющие проверки на компьютерах пользователей, либо возможность выбора между продуктом и облачной услугой. Лидерами мирового рынка в течение последних пяти лет остаются компании HP и IBM, обзор их продуктов приведен ниже. Наиболее близок к лидирующим позициям продукт компании Checkmarx, специализирующейся только на данном классе средств, поэтому он также включен в обзор.

Рисунок 2. Магический квадрант аналитиков Gartner по игрокам рынка анализа защищенности приложений в августе 2015 года

По данным отчета аналитиков ReportsnReports , в США объем рынка анализаторов исходных кодов в 2014 году составил $2,5 млрд, к 2019 году прогнозируется двукратный рост до $5 млрд с ежегодным ростом на 14,9%. Более 50% организаций, опрошенных в ходе составления отчета, планируют выделение и увеличение бюджетов на анализ исходного кода при заказной разработке, и только 3% негативно высказались о применении данных продуктов.

Большое число продуктов, находящихся в области претендентов (challengers), подтверждает популярность данного класса продуктов и стремительное развитие отрасли. За последние пять лет общее число производителей в этом квадранте увеличилось почти в три раза, а по сравнению с отчетом за 2014 год добавилось три продукта.

Российский рынок

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

Наиболее заметные игроки нового рынка - компании Positive Technologies, InfoWatch, а также Solar Security. Positive Technologies долгое время специализировались на поиске и анализе уязвимостей; в их портфолио есть продукт MaxPatrol - один из лидеров отечественного рынка по внешнему контролю защищенности, поэтому неудивительно, что в компании решили заняться и внутренним анализом и разрабатывать собственный анализатор исходных кодов. Компания InfoWatch развивалась как разработчик DLP-систем, со временем превратившись в группу компаний, находящуюся в поисках новых рыночных ниш. В 2012 году в состав InfoWatch вошла компания Appercut, добавив в портфель InfoWatch средство анализа исходного кода. Инвестиции и опыт InfoWatch позволили быстро развить продукт до высокого уровня. Solar Security официально представили свой продукт Solar inCode только в конце октября 2015 года, но уже на момент выхода имели четыре официальных внедрения в России.

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

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

Краткий обзор анализаторов

Первое средство анализа исходного кода в нашем обзоре - продукт компании Fortify, с 2010 года принадлежащей Hewlett-Packard. В линейке HP Fortify присутствуют различные продукты для анализа программных кодов: есть и SaaS-сервис Fortify On-Demand, предполагающий загрузку исходного кода в облако HP, и полноценное приложение HP Fortify Static Code Analyzer, устанавливаемое в инфраструктуре заказчика.

HP Fortify Static Code Analyzer поддерживает большое число языков программирования и платформ, включая веб-приложения, написанные на PHP, Python, Java/JSP, ASP.Net и JavaScript, и встраиваемый код на языках ABAP (SAP), Action Script и VBScript.

Рисунок 3. Интерфейс HP Fortify Static Code Analyzer

Из особенностей продукта стоит выделить наличие в HP Fortify Static Code Analyzer поддержки интеграции с различными системами управления разработкой и отслеживания ошибок. Если разработчик программного кода предоставляет заказчику доступ к прямой передаче сообщений об ошибках в Bugzilla, HP Quality Center или Microsoft TFS, анализатор может автоматически создавать сообщения об ошибках в этих системах без необходимости ручных действий.

Работа продукта основана на собственных базах знаний HP Fortify, сформированных адаптацией базы CWE. В продукте реализован анализ на выполнение требований DISA STIG, FISMA, PCI DSS и рекомендаций OWASP.

Из недостатков HP Fortify Static Code Analyzer следует отметить отсутствие локализации продукта для российского рынка - интерфейс и отчеты на английском языке, отсутствие материалов и документации на продукт на русском языке, не поддерживается анализ встраиваемого кода для 1С и других отечественных продуктов enterprise-уровня.

Преимущества HP Fortify Static Code Analyzer:

  • известный бренд, высокое качество решения;
  • большой перечень анализируемых языков программирования и поддерживаемых сред разработки;
  • наличие возможности интеграции с системами управления разработкой и другими продуктами HP Fortify;
  • поддержка международных стандартов, рекомендаций и «лучших практик».

Checkmarx CxSAST - средство американо-израильской компании Сheckmarx, специализирующейся на разработке анализаторов исходных кодов. Данный продукт предназначен в первую очередь для анализа обычного программного обеспечения, но за счет поддержки языков программирования PHP, Python, JavaScript, Perl и Ruby отлично подходит для анализа веб-приложений. Checkmarx CxSAST это универсальный анализатор, не имеющий ярко выраженной специфики и поэтому подходящий для применения на любых этапах жизненного цикла программного продукта - от разработки до применения.

Рисунок 4. Интерфейс Checkmarx CxSAST

В Checkmarx CxSAST реализована поддержка базы ошибок программного кода CWE, поддерживаются проверки на соответствие рекомендациям OWASP и SANS 25, стандартам PCI DSS, HIPAA, MISRA, FISMA и BSIMM. Все обнаруженные Checkmarx CxSAST проблемы разделяются по степени риска - от незначительного до критического. Из особенностей продукта - наличие функций по визуализации кода с построением блок-схем маршрутов выполнения и рекомендациями по исправлению проблем с привязкой к графической схеме.

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

Преимущества Checkmarx CxSAST:

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

Еще один продукт от известного вендора - анализатор исходных кодов IBM Security AppScan Source. Линейка AppScan включает множество продуктов, связанных с безопасной разработкой программного обеспечения, но для применения у заказчиков программного кода остальные продукты не подойдут, так как обладают большим количеством излишнего функционала. IBM Security AppScan Source, как и Checkmarx CxSAST, в первую очередь предназначен для организаций-разработчиков, при этом поддерживает даже меньшее число языков веб-разработки - только PHP, Perl и JavaScript. Языки программирования для встраиваемого в бизнес-приложения кода не поддерживаются.

Рисунок 5. Интерфейс IBM Security AppScan Source

IBM Security AppScan Source тесно интегрируется с платформой для разработки IBM Rational, поэтому продукт чаще всего используется на этапе разработки и тестирования программных продуктов и не очень хорошо подходит для выполнения приемки или проверки разработанного на заказ приложения.

Особенностью IBM Security AppScan Source является разве что поддержка анализа программ для IBM Worklight - платформы для мобильных бизнес-приложений. Перечень поддерживаемых стандартов и требований скуден - PCI DSS и рекомендации DISA и OWASP, база уязвимостей сопоставляет найденные проблемы с CWE.

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

AppChecker от отечественной компании ЗАО «НПО Эшелон» - решение, появившееся на рынке совсем недавно. Первая версия продукта вышла всего год назад, но при этом следует учитывать опыт компании «Эшелон» в анализе программного кода. «НПО Эшелон» является испытательной лабораторией ФСТЭК, ФСБ и Министерства обороны РФ и имеет большой опыт в области проведения статического и динамического анализа исходных текстов программ.

Рисунок 6. Интерфейс «Эшелон» AppChecker

AppChecker предназначен для анализа разнообразного программного обеспечения и веб-приложений, написанных на языках PHP, Java и C/C++. Полностью поддерживает классификацию уязвимостей CWE и учитывает рекомендации OWASP, CERT и NISP. Продукт можно использовать для выполнения аудита на соответствие требованиям PCI DSS и стандарта Банка России ИББС-2.6-2014.

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

Преимущества:

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

PT Application Inspector - продукт российского разработчика Positive Technologies, отличающийся своим подходом к решению проблемы анализа исходного кода. PT Application Inspector нацелен в первую очередь на поиск уязвимостей в коде, а не на выявление общих программных ошибок.

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

Рисунок 7. Интерфейс PT Application Inspector

PT Application Inspector поддерживает как языки разработки веб-приложений (PHP, JavaScript), так и встраиваемый код для бизнес-приложений - SAP ABAP, SAP Java, Oracle EBS Java, Oracle EBS PL/SQL. Также продукт PT Application Inspector поддерживает визуализацию маршрутов выполнения программ.

PT Application Inspector является универсальным решением как для разработчиков, так и для заказчиков, эксплуатирующих разработанные на заказ веб-приложения и встраиваемые модули для бизнес-приложений. База уязвимостей и ошибок в программном коде содержит собственные наработки компании Positive Technologies, базу CWE и WASC (база уязвимостей веб-консорциума, аналог CWE для веб-приложений).

Использование PT Application Inspector позволяет выполнить требования стандартов PCI DSS, СТО БР ИББС, а также 17 приказа ФСТЭК и требования по отсутствию недекларированных возможностей (актуально при сертификации кода).

Преимущества:

  • поддержка анализа веб-приложений и большого набора систем разработки для бизнес-приложений;
  • отечественный, локализованный продукт;
  • широкий набор поддерживаемых государственных стандартов;
  • использование базы уязвимостей веб-приложений WASC и классификатора CWE;
  • возможность визуализации программного кода и поиска программных закладок.

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

InfoWatch Appercut поддерживает практически все языки программирования, на которых создаются веб-приложения (JavaScript, Python, PHP, Ruby) и встраиваемые модули для бизнес-предложений - 1С, ABAP, X++ (ERP Microsoft Axapta), Java, Lotus Script. InfoWatch Appercut обладает способностью подстраиваться под специфику конкретного приложения и уникальность бизнес-процессов каждой компании.

Рисунок 8. Интерфейс InfoWatch Appercut

InfoWatch Appercut поддерживает многие требования по эффективному и безопасному программированию, включая общие требования PCI DSS и HIPPA, рекомендации и «лучшие практики» CERT и OWAST, а также рекомендации производителей платформ бизнес-процессов - 1С, SAP, Oracle, Microsoft.

Преимущества:

  • отечественный, локализованный продукт, сертифицированный ФСТЭК России;
  • единственный продукт, поддерживающий все популярные в России бизнес-платформы, включая 1С, SAP, Oracle EBS, IBM Collaboration Solutions (Lotus) и Microsoft Axapta;
  • быстрый сканер, выполняющий проверки за считанные секунды и способный проверять только измененный код и фрагменты кода.

Digital Security ERPScan - специализированный продукт для анализа и мониторинга защищенности бизнес-систем, построенных на продуктах SAP, первая версия выпущена в 2010 году. В состав ERPScan входит помимо модуля анализа конфигураций, уязвимостей и контроля доступа (SOD) модуль оценки безопасности исходного кода, реализующий функции поиска закладок, критичных вызовов, уязвимостей и ошибок программирования в коде на языках программирования ABAP и Java. При этом продукт учитывает специфику платформы SAP, проводит корреляцию обнаруженных уязвимостей в коде с настройками конфигурации и правами доступа и выполняет анализ лучше, чем неспециализированные продукты, работающие с теми же языками программирования.

Рисунок 9. Интерфейс Digital Security ERPScan

Из дополнительных функций ERPScan можно отметить возможность автоматической генерации исправлений для обнаруженных уязвимостей а также генерацию сигнатур для возможных атак и выгрузку этих сигнатур в системы обнаружения и предотвращений вторжений (в партнерстве с CISCO). Кроме того в системе присутствуют механизмы оценки производительности встраиваемого кода, что является критичным для бизнес-приложений, так как медленная работа дополнительных модулей может серьезно отразиться на бизнес-процессах в организации. Система также поддерживает анализ в соответствии со специфичными рекомендациями по анализу кода бизнес-приложений, такими, как EAS-SEC и BIZEC а также общими рекомендациями PCI DSS и OWASP.

Преимущества:

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

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

Solar inCode позволяет проводить анализ исходного кода, написанного на языках программирования Java, Scala, Java for Android, PHP и Objective C. В отличие от большинства конкурентов, в перечне поддерживаемых языков программирования присутствуют средства разработки для мобильных платформ Android и iOS.

Рисунок 10. Интерфейс

В случаях, когда исходный код не доступен, Solar inCode позволяет осуществить анализ готовых приложений, эта функциональность поддерживает веб-приложения и мобильные приложения. В частности, для мобильных приложений достаточно просто скопировать в сканер ссылку на приложение из Google Play или Apple Store, приложение будет автоматически загружено, декомпилировано и проверено.

Использование Solar inCode позволяет выполнить требования стандартов PCI DSS, СТО БР ИББС, а также 17 приказа ФСТЭК и требования по отсутствию недекларированных возможностей (актуально при сертификации кода).

Преимущества:

  • Поддержка анализа приложений для мобильных устройств под управлением Android и iOS;
  • поддерживает анализ веб-приложений и мобильных приложений без использования исходных текстов программ;
  • выдает результаты анализа в формате конкретных рекомендаций по устранению уязвимостей;
  • формирует детальные рекомендации по настройке средств защиты: SIEM, WAF, FW, NGFW;
  • легко интегрируется в процесс безопасной разработки ПО за счет поддержки работы с репозиториями исходных текстов.

Выводы

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

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

В данном обзоре явным лидером среди иностранных продуктов по поддержке языков программирования и качеству сканирования является решение HP Fortify Static Code Analyzer. Также хорошим продуктом является Checkmarx CxSAST, но он способен анализировать только обычные приложения и веб-приложения, поддержка встраиваемых модулей для бизнес-приложений в продукте отсутствует. Решение IBM Security AppScan Source на фоне конкурентов выглядит блекло и не отличается ни функциональностью, ни качеством проверок. Впрочем, этот продукт не предназначен для бизнес-пользователей и направлен на использование в компаниях-разработчиках, где он может показывать большую эффективность, чем конкуренты.

Среди российских продуктов сложно выделить однозначного лидера, рынок представляют три основных продукта – InfoWatch Appercut, PT Application Inspector и Solar inCode. При этом данные продукты существенно различаются технологически и предназначены для разных целевых аудиторий - первый поддерживает больше платформ бизнес-приложений и отличается большим быстродействием за счет поиска уязвимостей исключительно статическими методами анализа. Второй - сочетает в себе статический и динамический анализ, а также их комбинацию, что одновременно с улучшением качества сканирования приводит к увеличению времени проверки исходного кода. Третий же направлен на решение проблем бизнес-пользователей и специалистов по информационной безопасности, а также позволяет проверять приложения без доступа к исходному коду.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Александр Миноженко
Старший исследователь департамента анализа кода
в 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 категории:

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

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

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

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

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

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

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