Вскрытие статического анализа кода проектов 1с

Подготовительный этап

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

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

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

Поиск ошибок в программе без необходимости ее выполнения.
Улучшение качества кода в широком смысле этого слова. Качество исходного кода — это комплексное понятие, которое включает в себя, кроме прочего, количество ошибок на условные 100 строк кода. Но также в это понятие входят читаемость, поддерживаемость, сложность кода (cyclomatic complexity), уровень связанности и другие аспекты, которые прямо или косвенно влияют на количество ошибок, а также на общее время разработки.
Сбор метрик проекта, сбор статистики, построение графиков и диаграмм, отражающих общее «состояние здоровья» проекта. Пример анализаторов такого типа — NDepend. Также в Visual Studio присутствует встроенный инструмент сбора метрик кода.
Анализ кода как часть механизма quality gate в CI/CD. Анализаторы кода могут не только сообщать о наличии возможных ошибок в коде, но и служить защитным механизмом, предотвращающим доставку кода, если уровень его качества не соответствует заданным требованиям. Такую роль могут выполнять анализаторы кода, расширяющие поведение компилятора и блокирующие сборку, если были обнаружены ошибки или несоответствия кода принятым стандартам. Это, например, анализаторы на базе Roslyn, которые мы и будем рассматривать в рамках этой статьи.
Средство документации принятых в команде стандартов и code style. Конфигурация статических анализаторов, которая обычно хранится в системе контроля версий вместе с основным кодом, снабженная емкими комментариями, может помочь быстрее вводить в проект новых разработчиков. Изучая файл конфигурации, они смогут достаточно быстро понять основные требования к качеству кода в команде, а также специфические требования для конкретного проекта.

Обоснование

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

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

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

Медицинское программное обеспечениеУправление по санитарному надзору за качеством пищевых продуктов и медикаментов США (FDA) обнаружило использование статического анализа для медицинских устройств.
Ядерное программное обеспечение: В Великобритании Управление ядерного регулирования (ONR) рекомендует использовать статический анализ систем защиты реакторов .
Авиационное программное обеспечение (в сочетании с динамическим анализом )
Автомобилестроение и машиностроение (функции функциональной безопасности являются неотъемлемой частью каждого этапа разработки автомобильной продукции, ISO 26262 , раздел 8).

Исследование, проведенное VDC Research в 2012 году, показало, что 28,7% опрошенных инженеров по встроенному программному обеспечению в настоящее время используют инструменты статического анализа, а 39,7% планируют использовать их в течение 2 лет.
Исследование 2010 года показало, что 60% опрошенных разработчиков в европейских исследовательских проектах хотя бы использовали свои базовые встроенные статические анализаторы IDE. Однако только около 10% использовали дополнительный другой (и, возможно, более продвинутый) инструмент анализа.

В индустрии безопасности приложений также используется название « Статическое тестирование безопасности приложений» (SAST). SAST — важная часть жизненных циклов разработки безопасности (SDL), таких как SDL, определенная Microsoft и распространенная практика в компаниях-разработчиках программного обеспечения.

Основной функционал Visual Studio: часть 2

Поиск и замена по коду
Поиск и замена по файлам
Получение справки
Решения
Типы проектов
Свойства проекта: раздел Application
Свойства проекта: разделы Compile, Build и Build Events
Свойства проекта: раздел Debug
Свойства проекта: разделы References и Resources
Свойства проекта: разделы Services, Settings, Reference Paths и Signing
Свойства проекта: разделы My Extensions, Security, Publish и Code Analysis
Свойства проектов Web Application
Технология IntelliSense
IntelliSense для JavaScript и XAML
Настройки системы IntelliSense
Закладки и окно Bookmark
Сниппеты
Рефакторинг кода

Статическое тестирование

Статическое тестирование (static testing) — тестирование без запуска кода на исполнение.

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

Статическое тестирование начинается на ранних этапах жизненного цикла ПО и является, соответственно, частью процесса верификации.

Можно поделить статическое тестирование на 2 типа:1. Обзоры (Review)2. Статический анализ (Static Analysis)

Обзоры

Обзоры (Review) – проверка обычно используется для поиска и устранения ошибок или неясностей в документах. Это могут быть требования, дизайн, тестовые случаи и так далее.

В свою очередь обзоры делятся на:

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

Статический анализ

Статический анализ (Static Analysis) – код, написанный разработчиками, анализируется на наличие структурных дефектов, которые могут привести к ошибкам.

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

Статический анализ состоит из 3-х частей:

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

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

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

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

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

В рамках этого подхода тестированию могут подвергаться:

Документы (требования, тест-кейсы, описания архитектуры приложения, схемы баз данных и т.д.).
Графические прототипы (например, эскизы пользовательского интерфейса).
Код приложения (что часто выполняется самими программистами в рамках аудита кода (code review), являющегося специфической вариацией взаимного просмотра в применении к исходному коду). Код приложения также можно проверять с использованием техник тестирования на основе структур кода.
Параметры (настройки) среды исполнения приложения.
Подготовленные тестовые данные.

Плюсы и минусы

Преимущества статического тестирования

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

Недостатки статического тестирования

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

Yasca

Сайт: www.yasca.org
Лицензия: Open Source
Платформа: Unix, Windows
Языки: С++, Java, .NET, ASP, Perl, PHP, Python и другие.

Yasca так же, как и RATS не нуждается в установке, при этом имеет не
только консольный интерфейс, но и простенький GUI. Разработчики рекомендуют
запускать утилиту через консоль — мол, так возможностей больше. Забавно, что
движок Yasca написан на PHP 5.2.5, причем интерпретатор (в самом урезанном
варианте) лежит в одной из подпапок архива с программой. Вся программа логически
состоит из фронт-енда, набора сканирующих плагинов, генератора отчета и
собственно движка, который заставляет все шестеренки вращаться вместе. Плагины
свалены в директорию plugins — туда же нужно устанавливать и дополнительные
аддоны. Важный момент! Трое из стандартных плагинов, которые входят в состав
Yasca, имеют неприятные зависимости. JLint, который сканирует Java’овские
.class-файлы, требует наличия jlint.exe в директории resource/utility. Второй
плагин — antiC, используемый для анализа сорцов Java и C/C++, требует antic.exe
в той же директории. А для работы PMD, который обрабатывает Java-код, необходима
установленная в системе Java JRE 1.4 или выше. Проверить правильность установки
можно, набрав команду «yasca ./resources/test/». Как выглядит сканирование?
Обработав скормленные программе сорцы, Yasca выдает результат в виде
специального отчета. Например, один из стандартных плагинов GREP позволяет с
помощью паттернов, описанных в .grep файлах, указать уязвимые конструкции и
легко выявлять целый ряд уязвимостей. Набор таких паттернов уже включен в
программу: для поиска слабого шифрования, авторизации по «пароль равен логину»,
возможные SQL-инъекции и много чего еще. Когда же в отчете захочется увидеть
более детальную информации, не поленись установить дополнительные плагины. Чего
стоит одно то, что с их помощью можно дополнительно просканировать код на на
.NET (VB.NET, C#, ASP.NET), PHP, ColdFusion, COBOL, HTML, JavaScript, CSS,
Visual Basic, ASP, Python, Perl.

AppChecker — инструмент статического анализа

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

Большинство методов анализа ПО, применяемого в аудите безопасности программных систем, можно разделить на две группы (рис. 1) — динамические методы (функциональное тестирование) и статические методы (структурное тестирование).

Рис. 1. Примерная классификация видов анализа программ (цветом выделены те виды анализа, о которых говорится в данной статье)

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

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

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

Создание нового проекта в Visual Studio Community 2020, и запуск первой программы

Теперь я предлагаю запустить Visual Studio Community 2020, и посмотреть, как она выглядит, и для примера давайте даже создадим проект программы, и запустим его на выполнение.

При первом запуске нам предлагают войти в учетную запись, если она есть, то входите, если нет, Вы можете ее создать прямо сейчас, также возможно отложить создание учетной записи, для этого просто нажимайте кнопку «Не сейчас! Возможно, позже.»

Затем выбирайте цветовую схему оформления среды Visual Studio и нажимайте «Запуск Visual Studio».

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

Для примера я сразу создам проект.

В качестве шаблона проекта я выберу «Мастер классических приложений Windows».

Нажимаем «Далее».

Затем указываем название проекта и расположение файлов этого проекта.

Нажимаем «Создать».

Потом выбираем тип приложения и дополнительные параметры, если требуется. Я выберу «Классическое приложение», параметры оставлю по умолчанию. Нажимаем «ОК».

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

В результате запустится программа, в которой даже будет меню.

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

Каким должен быть SAST-анализатор и на что обращать внимание при выборе

Технологии SAST уже более 10 лет. За это время сформировался понятный и достаточно полный перечень требований к анализаторам исходного кода, в соответствии с которыми она реализуется. Мы учитываем их при разработке SAST-анализатора Solar appScreener, а также исходим из пожеланий и потребностей пользователей подобных решений.

Поддержка большого количества языков программирования

Здесь без сомнений можно применять подход «чем больше, тем лучше». Неплохим показателем считается, когда анализатор уязвимостей приложений поддерживает больше 20 языков программирования. Например, в Solar appScreener реализована поддержка 36+ ЯП. Это количество регулярно увеличивается.

Анализ исходного кода, а также исполняемых файлов

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

Сравнение результатов проверок

Эта функция обеспечивает отслеживание динамики устранения и появления уязвимостей в программном обеспечении. Сравнение может выполняться разными способами. Часто используется подсветка фрагментов кода с комментариями «до» и «после». В дополнение к этому в SAST-анализаторе Solar appScreener мы реализовали графическое представление результатов тестирования, информативное и удобное для восприятия.

Формирование рекомендаций

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

Помимо этого, решение для статического анализа приложений должно иметь базу правил поиска уязвимостей с регулярными обновлениями и возможностью добавления собственных. Также должна быть обеспечена интеграция со средствами разработки, системами контроля версий и отслеживания ошибок и другими внешними решениями. Например, Solar appScreener интегрируется с Git и Subversion, VCS-хостингами GitLab, GitHub, Bitbucket, средами разработки Xcode, CMake, Microsoft Visual Studio, а также другими средствами сборки и IDE, серверами Azure DevOps Server, CI/CD Jenkins, а также TeamCity и проч.

Меры описательной статистики

Задача описательной статистики, как следует из названия, — дать хорошее описание данных. Она не для предсказаний, выводов или преобразований — только внешняя форма данных, измеренная в показателях.

Ключевые показатели, применяемые в описательной статистике (их ещё называют мерами или, если точнее, ), — это:

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

Посмотрите это небольшое видео о среднем, медиане и моде на сайте Академии Хана — образовательного ресурса, который славится доходчивыми объяснениями. Там всё просто, на понятном русском языке.

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

Русскоязычные видео

Статический анализ кода

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

Статический анализ, как гигиена кода

Видео с конференции DotNext 2015 Moscow. В докладе рассказывается о способах обнаружения ошибок, методологии статического анализа, правильном и неправильном использовании инструментов анализа кода. Автор также приводит мифы о статическом анализе, которые могут ввести в заблуждение разработчиков. Демонстрируются примеры ошибок в Open Source проектах, выявленных с помощью таких инструментов, как ReSharper, PVS-Studio, Visual Studio SCA.

Статический анализ в C++ и анализ производительности

Авторы: Александр Нежельский, Евгений Буштырёв, Никита Какуев, Николай Дьяконов.

Запись доклада, озвученного в рамках события CoLaboratory в штаб-квартире «Лаборатории Касперского». В видео обсуждается статический анализ C++ кода и анализ производительности программ. В числе прочего авторы рассказывают, как сделать код пригодным для статического анализа, как бороться с ложными срабатываниями и как расширять функциональность Clang Static Analyzer за счет собственных проверок.

Современный статический анализ кода: что умеет он, чего не умели линтеры

Видео с конференции C++ CoreHard Winter 2017. Автор показывает, чему со времени появления по сегодняшний день научились статические анализаторы. Рассматриваются различные методики анализа, как они появлялись и какие ошибки можно с их помощью найти. В видео проводится разбор ошибок, найденных в Open Source проектах и рассказывается, чем статический анализатор отличается от «линтеров» и некоторых других инструментов, а также какие проблемы, помимо анализа кода, он решает.

Сценарии использования статического анализатора

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

Сlang-Tidy путешествие внутрь C++ Abstract Syntax Tree

Видео с конференции CoreHard Summer Conf 2016. Семейство библиотек Clang предоставляет разработчикам широчайшие возможности по реализации различных инструментов, основанных на разборе и анализе абстрактного синтаксического дерева (AST). В частности, авторы Clang выпускают такой инструмент, как Clang-Tidy, который является мощным статическим анализатором кода. В видео рассматривается, как этот инструмент применяется в процессе разработки для С++ и как дополнить его собственными проверками. Попутно идет разбор некоторых занимательных особенностей AST для С++.

Не все статические анализаторы одинаково полезны

Видео с конференции DotNext 2016 Spb. В докладе речь пойдет о популярных инструментах, ищущих нарушения Guidelines, ошибки copy-paste и опечатки в исходном коде. Обсуждаются результаты работы этих инструментов на наборе Open Source проектов, а также об используемой при сравнении методике. Далее рассматриваются более сложные ошибки, такие как возникновение NullReferenceException или утечка ресурсов, и способы их обнаружения. Помочь обнаружить такие ошибки может как чисто статический анализ, например, Coverity Prevent, так и статико-динамический, такой как IntelliTest(Pex).

Статический анализ кода в контексте SSDL

Видео с форума PHDays VI. Ведущий фаст-трека рассказывает об опыте внедрения Static Analysis Security Tool в QIWI, о сложностях, с которыми сталкивались разработчики. Разбирает такие вопросы, как писать «костыли» или рефакторить код, а также что делать, когда мнения клиента и разработчика расходятся. Расскажет, сколько строк кода пришлось прочитать и написать до и после запуска сканера, и предложит краткий обзор найденных и упущенных уязвимостей.

Статический анализ кода JS

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

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

Одним из современных статических анализаторов является инструмент PVS-Studio. Этот инструмент позволяет выявлять ошибки и потенциальные уязвимости в исходном коде программ, написанных на языках С, C++, C# и Java. Работает в 64-битных системах на Windows, Linux и macOS и может анализировать код, предназначенный для 32-битных, 64-битных и встраиваемых ARM платформ. Кратко рассмотрим, какие технологии использует PVS-Studio при анализе исходного кода.

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

Начнем с анализа потока данных. Он позволяет вычислить возможные значения переменных в разных точках программы. Благодаря Data-Flow Analysis можно находить такие ошибки, как выход за границу массива, утечки памяти, разыменование нулевого указателя и т.д.

Аннотирование методов

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

Сопоставление с шаблоном

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

Символьное выполнение

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

   
   void Foo(int A, int B, int C)
    {
     if(A<B)
      {
       if(B<C)
        {
         if(A>C)
          {
           ....
          }
        }
     }
   }

Не зная ничего о значениях переменных A, B и C, анализатор PVS-Studio способен понять, что условие (A > C) всегда ложно, и сообщить об этом разработчику. Подробнее с этим и другими принципами, положенными в основу анализатора, можно познакомиться в статье Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей.

Я знаю, о чем подумали некоторые читатели этой статьи. Это все, конечно, классно, но зачем нам статический анализ? Приведу пример из своей жизни. У меня был маленький пет-проект – светодиодные костюмы, которые светятся и моргают под музыку (при нажатии кнопки «плей» в программе на компьютере запускается таймер, который и отправляет на светодиоды значение RGB). Однажды, внеся очередные правки в код, я включила костюм и поняла, что он сходит с ума. Костюм хаотично моргал и светился теми цветами, которые я видеть вообще не ожидала, и больше напоминал кошмар эпилептика, чем светодиодную шмотку. На поиск ошибки у меня ушло, наверное, около часа, я перечитывала свой код немыслимое количество раз, а причина оказалась в банальной опечатке в одной цифре… мда.

К слову, ошибку, которую я допустила, успешно находит статический анализ.

   
   private void saveip6_Click(object sender, RoutedEventArgs e)
    {
     saveIp(ip6.Text.ToString(), 6);
      ....
    }

   private void saveip7_Click(object sender, RoutedEventArgs e)
    {
     saveIp(ip6.Text.ToString(), 6);  // Должно быть 7
      ....
    }

Предупреждение PVS-Studio: V3013 It is odd that the body of ‘saveip6_Click’ function is fully equivalent to the body of ‘saveip7_Click’ function (5254, line 5260). MainWindow.xaml.cs 5254

Тут я методом копипасты писала код, сохраняющий ip-адрес контроллеров костюмов из текстбоксов. И, дабы быть честной, признаюсь, что цифра 6 тут из головы. Я не помню, в каком конкретно обработчике событий так неудачно накопипастила

Ну и не важно, самое главное – передать суть

Однако у меня была довольно небольшая кодовая база и, следовательно, маленький объем всевозможных ошибок и опечаток. Цифры, взятые из книги Стива Макконнелла «Совершенный код», гласят, что с ростом размера проекта растёт и плотность ошибок.

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

Примеры дефектов кода

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

К наиболее известным и опасным уязвимостям нужно отнести уязвимости следующих видов:

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

Заключение

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

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

Вы можете попробовать статический анализатор PVS-Studio, запросив бесплатную пробную лицензию.

Семантическая модель (semantic model) кода и вывод типов (type inference)

Все анализаторы PVS-Studio на основе построенного на предыдущем этапе представления кода в виде абстрактного синтаксического дерева проводят семантический анализ — построение полной семантической модели проверяемого кода.

Обобщённая семантическая модель представляет собой словарь соответствий семантических (смысловых) символов и элементов синтаксического представления этого же кода.

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

Не зная, что собой представляет B, невозможно сказать, какая перед нами конструкция языка. Это может быть как вызов функции, так и явное приведение типа (functional cast expression).

Семантическая модель, таким образом, позволяет анализировать семантику кода. Без неё пришлось бы постоянно совершать обход синтаксического представления этого кода, чтобы разрешить невыводимые из локального контекста семантические факты. Семантическая модель «запоминает» семантику по ходу разбора кода для дальнейшего её использования. Поясним на примере:

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

На основе семантической модели анализаторы PVS-Studio получают возможность проводить вывод типов (type inference) у любой встречаемой синтаксической конструкции. Такими конструкциями могут быть идентификаторы переменных, выражения и так далее.

Информация о типах требуется большинству диагностик. На её основе делается предположение о потенциальных ошибках или наоборот — срабатывают исключения из правил.

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

Рассмотрим в качестве примера очень простую диагностику V772 для кода на языке C++:

Вызов оператора delete для указателя типа (void *) приводит к неопределённому поведению. Сам по себе шаблон для поиска крайне прост: это любой вызов оператора delete. Можно сказать, это вырожденный случай шаблонной диагностики :). Однако, чтобы понять, найдена ошибка или нет, нужно знать тип операнда ptr.

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