Анализ программы - Program analysis

Разработка программного обеспечения
Активность ядер
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
инструменты
Стандарты и свод знаний
Глоссарии
Контуры

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

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

Статический анализ программы

В контексте корректности программы статический анализ может обнаруживать уязвимости на этапе разработки программы.[2]. Эти уязвимости легче исправить, чем обнаруженные на этапе тестирования, поскольку статический анализ позволяет определить корень уязвимости.

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

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

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

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

Поток управления

Целью анализа потока управления является получение информации о том, какие функции могут быть вызваны в различные моменты во время выполнения программы. Собранная информация представлена ​​значком граф потока управления (CFG), где узлы представляют собой инструкции программы, а края представляют собой поток управления. Идентификация блоков кода и циклов CFG становится отправной точкой для оптимизаций, выполненных компилятором.

Анализ потока данных

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

Абстрактная интерпретация

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

Системы типов

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

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

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

Системы эффектов

Системы эффектов - это формальные системы, предназначенные для представления эффектов, которые может иметь выполнение функции или метода. Эффект кодифицирует то, что делается, и то, что делается - обычно это называется типом эффекта и областью соответственно.[требуется разъяснение ]

Проверка модели

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

Динамический анализ программы

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

Тестирование

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

Мониторинг

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

Программа нарезки

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

Смотрите также

использованная литература

  1. ^ Нильсон, Ф., Нильсон, Х. Р., и Ханкин, К. (2015). Принципы анализа программ. Springer.
  2. ^ Йованович, Н., Крюгель, К., и Кирда, Э. (2006, май). Pixy: инструмент статического анализа для обнаружения уязвимостей веб-приложений. В разделе «Безопасность и конфиденциальность», Симпозиум IEEE 2006 г. (стр. 6– pp). IEEE.

дальнейшее чтение

  • Агравал, Хиралал; Хорган, Джозеф Р. Динамическая нарезка программы (PDF).
  • Чунлей, Ван; Ганг, Чжао; Ики, Дай (2009). «Эффективный подход к анализу безопасности потока управления для двоичных исполняемых файлов». 2009 2-я Международная конференция IEEE по компьютерным наукам и информационным технологиям. С. 272–276. Дои:10.1109 / ICCSIT.2009.5234950. ISBN  978-1-4244-4519-6.
  • Нильсон, Флемминг; Нильсон, Ханне Риис; Ханкин, Крис (2005). Принципы анализа программ. Springer Science + Business Media.

внешние ссылки