О статическом анализе кода в теории и на практике | — IT-блог для начинающих
О статическом анализе кода в теории и на практике
Есть много способов, которые помогут повысить качество программы. В этой статье предлагаю взглянуть на один из них – статический анализ кода.
Кратко о статическом анализе кода
Как вы, наверное, уже знаете, статические анализаторы позволяют проверять код без запуска самой программы. Последнее время популярность статического анализа при разработке набирает обороты, а рынок статического анализа с каждым годом становится больше. Отчасти это связано с тем, что прошла эра линтеров, которые были основаны только на регулярных выражениях.
Сейчас статический анализ поражает своим разнообразием и возможностями. Даже хайп с AI и машинным обучением не прошел мимо анализаторов, и швейцарцы выпустили продукт, обучающийся на открытых репозиториях. Однако надо понимать, что AI в обозримом будущем не заменит классические технологии, применяемые в статических анализаторах, а пополнит их.
Инструменты и технологии для статического анализа кода
Одним из современных статических анализаторов является инструмент PVS-Studio. Этот инструмент позволяет выявлять ошибки и потенциальные уязвимости в исходном коде программ, написанных на языках С, C++, C# и Java. Работает в 64-битных системах на Windows, Linux и macOS и может анализировать код, предназначенный для 32-битных, 64-битных и встраиваемых ARM платформ. Кратко рассмотрим, какие технологии использует PVS-Studio при анализе исходного кода.
Анализ потока данных
Начнем с Анализа потока данных. Он позволяет вычислить возможные значения переменных в разных точках программы. Благодаря Data-Flow Analysis можно находить такие ошибки, как выход за границу массива, утечки памяти, разыменование нулевого указателя и т. д.
Аннотирование методов
Ручное и автоматическое Аннотирование методов. Оно предоставляет больше информации об используемых методах, чем может быть получено путём анализа только их сигнатуры.
Сопоставление с шаблоном
Сопоставление с шаблоном. Анализатор, проверяя код, может находить заданные заранее паттерны, типичные для какой-либо ошибки. В простейшем варианте этот поиск похож на поиск ошибок с помощью регулярных выражений, однако всё обстоит несколько сложнее. Для поиска ошибок используется обход и анализ дерева разбора. Почему для этих задач неприемлемо использовать регулярные выражения, можно узнать из статьи «Статический анализ и регулярные выражения».
Символьное выполнение
Символьное выполнение. Оно позволяет находить недочеты в коде, даже не зная, какое значение переменных будет в строке с ошибкой. Небольшой пример, чтобы было нагляднее:
Не зная ничего о значениях переменных A, B и C, анализатор PVS-Studio способен понять, что условие (A > C) всегда ложно, и сообщить об этом разработчику. Подробнее с этим и другими принципами, положенными в основу анализатора, можно познакомиться в статье «Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей».
Я знаю, о чем подумали некоторые читатели этой статьи. Это все, конечно, классно, но зачем нам статический анализ? Приведу пример из своей жизни. У меня был маленький пет-проект – светодиодные костюмы, которые светятся и моргают под музыку (При нажатии кнопки «плей» в программе на компьютере запускается таймер, который и отправляет на светодиоды значение RGB). Однажды, внеся очередные правки в код, я включила костюм и поняла, что он сходит с ума. Костюм хаотично моргал и светился теми цветами, которые я видеть вообще не ожидала, и больше напоминал кошмар эпилептика, чем светодиодную шмотку. На поиск ошибки у меня ушло, наверное, около часа, я перечитывала свой код немыслимое количество раз, а причина оказалась в банальной опечатке в одной цифре… мда.
К слову, ошибку, которую я допустила, успешно находит статический анализ.
Предупреждение 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 тут из головы. Я не помню, в каком конкретно обработчике событий так неудачно накопипастила. Ну и не важно, самое главное – передать суть.
Однако у меня была довольно небольшая кодовая база и, следовательно, маленький объем всевозможных ошибок и опечаток. Цифры, взятые из книги Стива Макконнелла «Совершенный код», гласят, что с ростом размера проекта растёт и плотность ошибок.
Именно поэтому инструменты статического анализа все больше набирают популярность среди крупных компаний, занимающихся разработкой.
Статический анализ кода на практике
Давайте теперь перейдём от теории к практике и на примере посмотрим, какие ошибки можно выявлять с помощью статического анализа кода. Для этого возьмём небольшой реальный открытый проект Extended WPF Toolkit и проверим его с помощью PVS-Studio.
Extended WPF Toolkit – это коллекция элементов управления и компонентов для WPF приложений. Проект включает в себя около 600 файлов исходного кода на языке C# и около 112 тысяч строк. Этот бесплатный набор инструментов имеет открытый исходный код и предоставляется в рамках лицензии Microsoft Public License. Также разработчики уже на платной основе предлагают воспользоваться Toolkit Plus Edition и Business Suite, в которых еще больше разнообразных компонентов и элементов управления, несколько тем под Metro и Windows 10 и многое другое.
Впрочем, все эти подробности нам не очень важны. Главное, что это обыкновенный типовой проект, написанный на языке C#. Давайте рассмотрим некоторые из ошибок, который в нём были найдены. Надеюсь, приведённых примеров будет достаточно для получения общего представления о технологии анализа кода. Более полное впечатление вы сможете составить самостоятельно, скачав и запустив анализатор на своих проектах. См. также «Как быстро посмотреть интересные предупреждения, которые выдает анализатор PVS-Studio для C и C++ кода?».
Примеры найденных ошибок
Предупреждение PVS-Studio: V3006 The object was created but it is not being used. The ‘throw’ keyword could be missing: throw new InvalidOperationException(FOO). DockingManager. cs 1129
Это предупреждение анализатора сообщает о том, что был создан экземпляр класса InvalidOperationException, который в коде не используется. Видимо, программист хотел, чтобы при выполнении условия генерировалось исключение, но забыл написать оператор Throw, который бы это исключение вызывал.
Предупреждение PVS-Studio: V3083 Unsafe invocation of event ‘PropertyChanged’, NullReferenceException is possible. Consider assigning event to a local variable before invoking it. CheckListsView. xaml. cs 124
Анализатор предупреждает о том, что был создан потенциально небезопасный вызов обработчика события. Проблема этого кода заключается в том, что одной проверки на Null в этом случае недостаточно. В многопоточном приложении между проверкой на Null и кодом в Then-ветви оператора If может выполниться код в другом потоке, выполняющий отписку от данного события. Если это произойдет, и подписчиков у события не останется, то такой случай приведет к возникновению исключения NullReferenceException.
Для того, чтобы гарантированно произошло безошибочное выполнение вызова события, есть несколько способов переписать этот код. Я приведу один пример, а разработчики сами решат – воспользоваться моим способом, найти другой, и стоит ли вообще с этим кодом что-то делать.
В этом примере мы сохраняем ссылку на обработчик события в переменную EventHandler. Теперь, даже если произойдет отписка от события и подписчиков не останется, переменная EventHandler всё равно будет содержать ссылку на первоначальный обработчик и код выполнится корректно.
Подобные проблемы в коде встретились более 30 раз. Все подобные предупреждения в рамках этой статьи смотреть будет скучно, поэтому предлагаю автору проекта самостоятельно попробовать их найти и исправить.
Предупреждение PVS-Studio: V3117 Constructor parameter ‘ignore’ is not used. AnimationRate. cs 59
Это предупреждение говорит о том, что параметр Ignore не используется в этом коде. Судя по названию параметра, это ложное срабатывание и вскоре ‘ignore’ уберут из этого кода. Если это так, то предлагаю использовать атрибут ‘Obsolete’, который используется как раз в таких случаях.
Предупреждение PVS-Studio: V3114 IDisposable object ‘reader’ is not disposed before method returns. CSharpFormat. cs 211
Анализатор указывает на то, что объект Reader класса StringReader реализует интерфейс ‘IDisposable’, но метод Dispose() для этого объекта в коде не был вызван. Тут, на самом деле, возникла двоякая ситуация. Класс StringReader и правда реализует данный интерфейс, но он его унаследовал от базового класса и никакими ресурсами он не владеет, поэтому вызывать Dispose() в этом случае не обязательно.
Анализатор обращает внимание на то, что в двух условиях подряд проверяется одно и то же значение на Null. Возможно, проверка избыточна, но так же есть и вероятность, что второе условие должно выглядеть иначе. Сложилось впечатление, что этот код просто не дописан.
Предупреждение PVS—Studio:
V3084 Anonymous function is used to unsubscribe from ‘HeaderDragDelta’ event. No handlers will be unsubscribed, as a separate delegate instance is created for each anonymous function declaration. ChildWindow. cs 355
V3084 Anonymous function is used to unsubscribe from ‘HeaderIconDoubleClicked’ event. No handlers will be unsubscribed, as a separate delegate instance is created for each anonymous function declaration. ChildWindow. cs 356
V3084 Anonymous function is used to unsubscribe from ‘CloseButtonClicked’ event. No handlers will be unsubscribed, as a separate delegate instance is created for each anonymous function declaration. ChildWindow. cs 357
В этом коде _WindowControl отписывается от события, а потом подписывается обратно. Проблема кроется в том, каким образом происходят манипуляции с событиями при помощи лямбда-выражений. Дело в том, что каждое объявление анонимной функции приводит к созданию отдельного экземпляра делегата. Корректный вариант использования анонимных функций при подписке с дальнейшей отпиской на события представляет собой создание и использование переменной, в которую сохранен обработчик-лямбда, например, так:
Предупреждение PVS-Studio: V3013 It is odd that the body of ‘OnMaxScaleChanged’ function is fully equivalent to the body of ‘OnMinScaleChanged’ function (656, line 695). Zoombox. cs 656
В этом коде анализатор нашел две функции OnMinScaleChanged и OnMaxScaleChanged, реализованные идентичным образом. При этом в коде было создано свойство зависимости с именем MaxScaleProperty. Есть подозрения, что во втором случае код должен выглядеть так:
Подобные ошибки, найденные анализатором:
Предупреждение PVS-Studio: V3051 An excessive type cast. The object is already of the ‘Magnifier’ type. MagnifierManager. cs 62
Анализатор указывает на то, что программист привел объект к своему же типу. Данная проверка является избыточной. Это не является ошибкой и можно оставить ключевое слово Var в объявлении Magnifier, но нагляднее будет явно указать тип переменной.
Обычно после описания ошибки идет перечисление всех мест, где попадался подобный ошибочный код, но в этом случае выписать все предупреждения не получится. В коде попалось более 50 (!) подобных предупреждений анализатора (не считая того, что могло попасть на уровень Low, который я смотрела не так внимательно, как остальные), что на мой взгляд чересчур много.
Предупреждение PVS-Studio: V3116 Consider inspecting the ‘for’ operator. It’s possible that the loop will be executed incorrectly or won’t be executed at all. CollectionControl. cs 642
Код в цикле For не выполнится ни разу по следующим причинам: сначала программа очищает List, потом сравнивает размер SourceList и List (генерируя исключение, если количество элементов в SourceList больше чем в пустом List), а далее пытается заполнить список List значениями из SourceList через цикл.
Предупреждение PVS-Studio: V3020 An unconditional ‘break’ within a loop. LayoutRoot. cs 542
Вне зависимости от значения SingleChild. ChildrenCount, из-за оператора Break выполняется ровно одна итерация цикла Foreach. Да и вообще код очень странный, непонятно, стоит ли это расценивать как ошибку, вдруг это так и было задумано…
Заключение
На примере проекта Extended WPF Toolkit мы убедились в значимости статического анализа при создании программного продукта. WPF Toolkit представляет собой совсем небольшой проект, однако на 112 тысяч строк кода попалось довольно много однотипных ошибок, вроде идентично реализованных методов, приведения объектов к своему же типу и т. д. Все эти ошибки легко находятся при помощи статического анализатора кода PVS-Studio, которым можно воспользоваться, скачав пробную версию по ссылке. Если ввести промокод #Infocomp в поле «Сообщение», то можно получить лицензию на один месяц вместо 7 дней.
AppChecker — инструмент статического анализа
В настоящее время информационные технологии проникли практически во все сферы ведения бизнеса. Для решения бизнес-задач создаются крупные, распределенные, постоянно модифицируемые информационные системы с тенденцией к усложнению. Они могут иметь в своем составе как готовые решения, так и внешние IT-сервисы (SaaS), собственные и заказные разработки, бесплатные продукты с открытым исходным кодом (open source). Проблемы в их работе приводят к нарушению информационной безопасности, а как следствие, к финансовым и репутационным потерям бизнеса. По данным исследования [9], последние четыре года финансовые потери бизнеса растут из-за кибератак. Повышение сложности используемых программных комплексов, их включение в контур систем управления государством и производством промышленной продукции требуют постоянного совершенствования методов тестирования, испытаний и контроля программного обеспечения.
Большинство методов анализа ПО, применяемого в аудите безопасности программных систем, можно разделить на две группы (рис. 1) — динамические методы (функциональное тестирование) и статические методы (структурное тестирование).
Рис. 1. Примерная классификация видов анализа программ (цветом выделены те виды анализа, о которых говорится в данной статье)
Динамический анализ представляет собой совокупность всех методов анализа программного обеспечения, реализуемых с помощью программ на реальном или виртуальном процессоре. Такие способы наиболее востребованы при исследовании программ методом «черного ящика» (black box), когда имеется доступ лишь к внешним интерфейсам программного обеспечения без учета их структуры, внутренних интерфейсов и состояния [5]. Этот подход не всегда эффективен при поиске ошибок, связанных с комбинациями редко используемых входных данных, а также при выявлении скрытого программного функционала (программных закладок), внесенного туда преднамеренно.
Для своей работы статический анализ не требует реализации программного кода и допускает полную или частичную автоматизацию процесса, но предполагает доступ не только к загрузочным и объектным модулям, но и к исходным текстам программной системы, к информации, связанной со средой компиляции и выполнением программных компонентов [3–5].
В соответствии с вышеизложенным для одновременного решения задач выявления случайных дефектов кода и программных закладок предлагается использовать методы статического анализа.
Методы статического анализа кода
Статический анализ исходных текстов программного обеспечения тесно связан с принципами работы компиляторов. Многие подходы такого анализа основаны на некоторых элементах компиляции, в частности, промежуточное представление исходных текстов в статических анализаторах эволюционирует совместно с развитием теории компиляторов. Современные методы анализа в целях унификации алгоритмов используют различные модели представления кода, например лексический разбор, синтаксическое дерево, дерево Канторовича, графы потока данных и управления и т. д. [1].
Подход, получивший название сигнатурного анализа, подразумевает поиск дефектов в программном коде путем сопоставления фрагментов кода с образцами из базы данных шаблонов (сигнатур) дефектов безопасности. В зависимости от технологии, применяемой при сопоставлении фрагмента кода и шаблона, а также от промежуточного представления, могут использоваться как обычные алгоритмы поиска подстроки в строке, так и регулярные выражения, специальные языки запросов по структурированной информации, в частности XQuery для XML, или специально разработанные для этой задачи способы сопоставления. В [2] приведены примеры правил формирования сигнатур ошибок, соответствующих стандарту CWE. Признакам потенциально опасных конструкций в программных системах и методам оценки их безопасности посвящены статьи 6, 7].
Самый простой способ поиска потенциально опасных конструкций — применение регулярных выражений. Этот вариант достаточно прост в реализации (легко добавляются новые шаблоны уязвимостей), однако имеет несколько критических недостатков. В первую очередь к ним относится невозможность создать шаблоны для сложных дефектов, причем даже для простых дефектов кода регулярное выражение может занимать очень много места, а также очень низкая скорость поиска.
Более эффективным считается построение промежуточного представления кода и его анализ. Именно такой способ используется почти во всех современных анализаторах кода. Общее представление структуры статического анализатора показано на рис. 2.
Рис. 2. Структура статического анализатора
На начальном этапе решение задачи анализа исходного кода напоминает действия компилятора либо интерпретатора (в случае динамического языка). Исходные тексты разбиваются на лексемы, на основании которых впоследствии строится абстрактное синтаксическое дерево (Abstract syntax tree — AST) и в дальнейшем семантический граф (Abstract semantic graph — ASG). Далее AST и ASG анализируются механизмом, подобным поиску регулярных выражений в тексте, либо используются скрипты для анализа. Помимо этого, анализ графов выполнения и потоков данных (Data Flow analysis) может дать полезную информацию.
Примеры дефектов кода
Самые распространенные виды дефектов кода — ошибки программирования и злонамеренно внесенный код. Следует заметить, что не всякая ошибка программирования приводит к возникновению уязвимости, а только те, в результате эксплуатации которых страдают защищенность, целостность и доступность данных. Злонамеренно внесенный код, как правило, позволяет получить несанкционированный доступ к системе, но бывают и другие типы дефектов, приводящие, например, к удаленному выполнению кода, сбору и отправке конфиденциальной информации либо к реализации несанкционированных действий при наступлении определенного момента времени (time bomb).
К наиболее известным и опасным уязвимостям нужно отнести уязвимости следующих видов:
Отсутствие проверки вводимых данных
Уязвимость появляется, если не производится проверка данных, поступивших из поля ручного ввода данных; от пользователя ожидается простая информация, например имя, email, текст короткого сообщения. Если при этом в поле ввода дописать код специально сформированной команды SQL или Javascript, то данный код будет выполнен. Например:
$stmt = prepare_query(«SELECT * FROM users WHERE username =?»);
В данном примере каждый параметр передается через отдельный метод bind_param, который и осуществляет фильтрацию специальных символов и ключевых слов.
Ошибки работы с памятью
Чаще всего встречаются ошибки, приводящие к переполнению буфера. Они, как правило, возникают в программах на языках C и C++. Если программа получает данные извне и копирует их во внутренний буфер без проверки размера копируемой области памяти, то при получении достаточно большого объема сведений происходит запись передаваемых данных на место адреса возврата и данных других процедур в области памяти стека. Эта ошибка может быть использована злоумышленником, который подставит нужное значение на место адреса возврата таким образом, чтобы в процессе возврата из подпрограммы переход осуществлялся вовнутрь той же перезаписанной области данных, где можно разместить вредоносный код. Пример уязвимого кода:
Int main(int argc, char *argv[]) <
Strcpy(buf, argv[1]);
// копирование
// без проверки длины
Пример безопасного кода:
Int main(int argc, char *argv[]) <
Strncpy(buf, argv[1], sizeof(buf));
// копируется не больше
Ошибки реализации
При проектировании и разработке решений для безопасности информационной системы не следует допускать появления в программном коде уязвимостей, которые в дальнейшем могут создать прецеденты нарушения информационной безопасности. К таким уязвимостям относятся:
Вредоносный код
Один из распространенных примеров вредоносного кода — внедрение разработчиком-злоумышленником возможностей несанкционированного доступа: доступа не только на основании допустимых аутентификационных сведений из базы данных, но и тех данных, о которых знает только разработчик-злоумышленник. Чаще всего к подобной информации относятся пароли-константы, но возможны и пароли, зависящие от даты и времени либо внешних поступающих данных.
Распространены и так называемые логические бомбы, действующие следующим образом: при наступлении определенного момента или при поступлении определенных входных данных программа меняет логику работы на вредоносную.
Эффективность статического анализа
Сегодня использование статических анализаторов становится объективной потребностью для обеспечения защищенности современных программных систем с высоким уровнем доверия. Введение новых стандартов разработки безопасного ПО подтверждает необходимость эффективных инструментов, поддерживающих качество программного кода.
Использование AppСhecker [8] позволяет существенно упростить и сократить затраты на ревизию кода при разработке программ, а также повысить качество кода и сократить количество ошибок и уязвимостей еще на этапе проектирования, что также позитивно скажется на затратах на доработку и поддержку выпускаемого ПО.
Помимо основного функционала в любом программном обеспечении, взаимодействующем с пользователем, очень важно удобство его применения. Удобный и понятный интерфейс (рис. 3), интеграция в процесс разработки, простота установки, обновления и поддержки становятся важными характеристиками анализаторов кода. Тем не менее сделать анализатор полностью автоматическим, действующим по «нажатию одной кнопки», невозможно.
Рис. 3. Общий вид рабочего экрана AppChecker
Как уже упоминалось, работа анализатора во многом близка работе компилятора. И для того чтобы провести качественный анализ, требуются те же действия, которые выполняет система сборки: проанализировать зависимости в проекте, распознать и «подключить» библиотечные функции и т. д., что может потребовать дополнительных настроек процесса анализа. В сравнении с другими статическими анализаторами, AppСhecker предоставляет пользователям бо? льшую гибкость в настройке: он понятен простым пользователям, а опытные разработчики смогут интегрировать его в процесс сборки любой сложности.
Важной составляющей безопасности кода является применение проверенных сторонних компонентов — библиотек или готовых программ с открытым исходным кодом. Их можно проверить, сообщая авторам о найденных уязвимостях и создавая базу уязвимостей open-source библиотек. Это особенно актуально для поддерживаемых анализатором AppСhecker интерпретируемых языков PHP, Javascript, в которых программы хранятся в виде исходных текстов.
Заключение
В статье рассмотрен метод статического анализа исходных кодов программного обеспечения, а также основные задачи и проблемы реализации автоматизированной проверки кода на примере статического анализатора AppChecker. Авторы данного продукта разработали эту технологию для удовлетворения потребностей рынка средств управления качеством исходного кода программ.
Источники:
Https://info-comp. ru/static-code-analysis
Https://controlengrussia. com/programmnye-sredstva/bezopasnost-programmnye-sredstva/appchecker/
1.
Кафедра КБ-4 «Автоматизированные системы управления»
Исследование программного кода
Для курса 3 группы УУБВ-01-16
По направлению подготовки
09.03.02 «Информационные системы и технологии»
Москва, 2018
1
2.
Кафедра КБ-4 «Автоматизированные системы управления»
Содержание:
1. Базовые понятия и определения (Лекция 1)…………….4
2. Статический анализ (Лекция 2-3)……….………..……….34
3. Обнаружение нефункциональных ошибок в
последовательных программах (Лекция 3)…………….88
4. Анализ отказоустойчивости программного кода(Лекция
5-6)..……………….………………………..142
Москва, 2018
2
3.
Кафедра КБ-4 «Автоматизированные системы управления»
Кашкин
Евгений
Владимирович
кандидат технических наук,
доцент кафедры «Информатика»,
доцент кафедры КБ-4
«Автоматизированные системы
управления»
[email protected]
Москва, 2018
3
4.
Базовые понятия и определения
Тема №1
«Базовые понятия и определения »
Цели занятия
• Качество ПО;
• Функциональность, надежность, удобство использования,
переносимость, удобство сопровождения, эффективность;
• Задачи обеспечения качества;
• Методы анализа ПО: ручные, динамические, статические,
гибридные;
• Надежность ПО;
• Ошибки в ПО;
Москва, 2018
4
5.
Базовые понятия и определения
5
6.
Базовые понятия и определения
6
7.
Базовые понятия и определения
7
8.
Базовые понятия и определения
8
9.
Базовые понятия и определения
9
10.
Базовые понятия и определения
10
11.
Базовые понятия и определения
11
12.
Базовые понятия и определения
12
13.
Базовые понятия и определения
13
14.
Базовые понятия и определения
14
15.
Базовые понятия и определения
15
16.
Базовые понятия и определения
16
17.
Базовые понятия и определения
17
18.
Базовые понятия и определения
18
19.
Базовые понятия и определения
19
20.
Базовые понятия и определения
20
21.
Базовые понятия и определения
21
22.
Базовые понятия и определения
22
23.
Базовые понятия и определения
23
24.
Базовые понятия и определения
24
25.
Базовые понятия и определения
25
26.
Базовые понятия и определения
26
27.
Базовые понятия и определения
27
28.
Базовые понятия и определения
28
29.
Базовые понятия и определения
29
30.
Базовые понятия и определения
30
31.
Базовые понятия и определения
31
32.
Базовые понятия и определения
Выводы по теме 1
В рамках данной темы были получены
знания в области надежности ПО.
Рассмотрены составляющие качества ПО, а
именно функциональность, надежность,
удобство использования, переносимость,
удобство сопровождения, эффективность.
Выявлены методы анализа ПО: ручной,
статический, динамический.
32
33.
Базовые понятия и определения
Вопросы для
самостоятельного изучения:
1. Требования к надежности программного обеспечения№
2. Эффективность программного обеспечения№
3. Причины ненадежности исполняемого кода.
33
34.
Статический анализ
Тема №2
«Статический анализ»
Цели занятия
Основные задачи и принципы статического анализа;
Классификация программных ошибок;
Виды статического анализа;
RD, AE, VBE, LV, CP, UD – анализ кода;
Алгоритмы анализа потока данных;
Эффективность статического анализа;
34
35.
Статический анализ
35
36.
Статический анализ
36
37.
Статический анализ
37
38.
Статический анализ
38
39.
Статический анализ
39
40.
Статический анализ
40
41.
Статический анализ
41
42.
Статический анализ
42
43.
Статический анализ
43
44.
Статический анализ
44
45.
Статический анализ
45
46.
Статический анализ
46
47.
Статический анализ
47
48.
Статический анализ
48
49.
Статический анализ
49
50.
Статический анализ
50
51.
Статический анализ
51
52.
Статический анализ
52
53.
Статический анализ
53
54.
Статический анализ
54
55.
Статический анализ
55
56.
Статический анализ
56
57.
Статический анализ
57
58.
Статический анализ
58
59.
Статический анализ
59
60.
Статический анализ
60
61.
Статический анализ
61
62.
Статический анализ
62
63.
Статический анализ
63
64.
Статический анализ
64
65.
Статический анализ
65
66.
Статический анализ
66
67.
Статический анализ
67
68.
Статический анализ
68
69.
Статический анализ
69
70.
Статический анализ
70
71.
Статический анализ
71
72.
Статический анализ
72
73.
Статический анализ
73
74.
Статический анализ
74
75.
Статический анализ
75
76.
Статический анализ
76
77.
Статический анализ
77
78.
Статический анализ
78
79.
Статический анализ
79
80.
Статический анализ
80
81.
Статический анализ
81
82.
Статический анализ
82
83.
Статический анализ
83
84.
Статический анализ
84
85.
Статический анализ
85
86.
Статический анализ
Выводы по теме 2
В рамках данной темы были получены
знания в области статического анализа
программного кода. Рассмотрены вопросы
различных подходов при анализе
последовательного кода. Даны примеры
решения системы дискретных уравнений в
рамках RD-анализа
86
87.
Статический анализ
Вопросы для
самостоятельного изучения:
1. Обнаружение функциональных и нефункциональных
ошибок;
2. Теория решеток;
3. Алгоритмы вычисления LFP;
4. Определение недостижимых переходов.
87
88.
Обнаружение нефункциональных ошибок в последовательных
программах
Тема №3
«Обнаружение нефункциональных ошибок в последовательных
программах»
Классификация программных дефектов (RES, LEAK, BUF, INI, IO);
Абстрактное синтаксическое дерево;
Абстрактный семантический граф;
Граф зависимостей по данным;
Граф потока управления;
Анализ программ на основе состояний;
Интервальный анализ;
Анализ указателей;
Ресурсный анализ.
88
89.
Обнаружение нефункциональных ошибок в последовательных
программах
89
90.
Обнаружение нефункциональных ошибок в последовательных
программах
90
91.
Обнаружение нефункциональных ошибок в последовательных
программах
91
92.
Обнаружение нефункциональных ошибок в последовательных
программах
92
93.
Обнаружение нефункциональных ошибок в последовательных
программах
93
94.
Обнаружение нефункциональных ошибок в последовательных
программах
94
95.
Обнаружение нефункциональных ошибок в последовательных
программах
95
96.
Обнаружение нефункциональных ошибок в последовательных
программах
96
97.
Обнаружение нефункциональных ошибок в последовательных
программах
97
98.
Обнаружение нефункциональных ошибок в последовательных
программах
98
99.
Обнаружение нефункциональных ошибок в последовательных
программах
99
100.
Обнаружение нефункциональных ошибок в последовательных
программах
10
101.
Обнаружение нефункциональных ошибок в последовательных
программах
10
102.
Обнаружение нефункциональных ошибок в последовательных
программах
10
103.
Обнаружение нефункциональных ошибок в последовательных
программах
10
104.
Обнаружение нефункциональных ошибок в последовательных
программах
10
105.
Обнаружение нефункциональных ошибок в последовательных
программах
10
106.
Обнаружение нефункциональных ошибок в последовательных
программах
10
107.
Обнаружение нефункциональных ошибок в последовательных
программах
10
108.
Обнаружение нефункциональных ошибок в последовательных
программах
10
109.
Обнаружение нефункциональных ошибок в последовательных
программах
10
110.
Обнаружение нефункциональных ошибок в последовательных
программах
11
111.
Обнаружение нефункциональных ошибок в последовательных
программах
11
112.
Обнаружение нефункциональных ошибок в последовательных
программах
11
113.
Обнаружение нефункциональных ошибок в последовательных
программах
11
114.
Обнаружение нефункциональных ошибок в последовательных
программах
11
115.
Обнаружение нефункциональных ошибок в последовательных
программах
11
116.
Обнаружение нефункциональных ошибок в последовательных
программах
11
117.
Обнаружение нефункциональных ошибок в последовательных
программах
11
118.
Обнаружение нефункциональных ошибок в последовательных
программах
11
119.
Обнаружение нефункциональных ошибок в последовательных
программах
11
120.
Обнаружение нефункциональных ошибок в последовательных
программах
12
121.
Обнаружение нефункциональных ошибок в последовательных
программах
12
122.
Обнаружение нефункциональных ошибок в последовательных
программах
12
123.
Обнаружение нефункциональных ошибок в последовательных
программах
12
124.
Обнаружение нефункциональных ошибок в последовательных
программах
12
125.
Обнаружение нефункциональных ошибок в последовательных
программах
12
126.
Обнаружение нефункциональных ошибок в последовательных
программах
12
127.
Обнаружение нефункциональных ошибок в последовательных
программах
12
128.
Обнаружение нефункциональных ошибок в последовательных
программах
12
129.
Обнаружение нефункциональных ошибок в последовательных
программах
12
130.
Обнаружение нефункциональных ошибок в последовательных
программах
13
131.
Обнаружение нефункциональных ошибок в последовательных
программах
13
132.
Обнаружение нефункциональных ошибок в последовательных
программах
13
133.
Обнаружение нефункциональных ошибок в последовательных
программах
13
134.
Обнаружение нефункциональных ошибок в последовательных
программах
13
135.
Обнаружение нефункциональных ошибок в последовательных
программах
13
136.
Обнаружение нефункциональных ошибок в последовательных
программах
13
137.
Обнаружение нефункциональных ошибок в последовательных
программах
13
138.
Обнаружение нефункциональных ошибок в последовательных
программах
13
139.
Обнаружение нефункциональных ошибок в последовательных
программах
13
140.
Обнаружение нефункциональных ошибок в последовательных
программах
Выводы по теме 3
В рамках данной темы были получены
знания в области обнаружения
программных дефектов различными
методами. Приведены примеры работы с
абстрактным синтаксическим деревом,
абстрактным семантическим графом и др.
Рассмотрены ключевые вопросы анализа
программ на основе состояний.
14
141.
Обнаружение нефункциональных ошибок в последовательных
программах
Вопросы для
самостоятельного изучения:
1.
2.
3.
4.
Программные средства для статического анализа;
Способы снижения ресурсоемкости;
Использование абстрактной интерпретации;
Анализ программ на основе шаблонов.
14
142.
Анализ отказоустойчивости программного кода
Тема №4
«Анализ отказоустойчивости программного кода»
Показатели надежности;
Жизненный цикл программной ошибки;
Модель Бернулли;
Модель Миллса;
Модель Шумана;
Модель Джелинского-Моранды;
Ошибки на путях выполнения программы.
14
143.
Анализ отказоустойчивости программного кода
14
144.
Анализ отказоустойчивости программного кода
14
145.
Анализ отказоустойчивости программного кода
14
146.
Анализ отказоустойчивости программного кода
14
147.
Анализ отказоустойчивости программного кода
14
148.
Анализ отказоустойчивости программного кода
14
149.
Анализ отказоустойчивости программного кода
14
150.
Анализ отказоустойчивости программного кода
15
151.
Анализ отказоустойчивости программного кода
15
152.
Анализ отказоустойчивости программного кода
15
153.
Анализ отказоустойчивости программного кода
15
154.
Анализ отказоустойчивости программного кода
15
155.
Анализ отказоустойчивости программного кода
15
156.
Анализ отказоустойчивости программного кода
15
157.
Анализ отказоустойчивости программного кода
15
158.
Анализ отказоустойчивости программного кода
15
159.
Анализ отказоустойчивости программного кода
15
160.
Анализ отказоустойчивости программного кода
16
161.
Анализ отказоустойчивости программного кода
16
162.
Анализ отказоустойчивости программного кода
16
163.
Анализ отказоустойчивости программного кода
16
164.
Анализ отказоустойчивости программного кода
16
165.
Анализ отказоустойчивости программного кода
16
166.
Анализ отказоустойчивости программного кода
16
167.
Анализ отказоустойчивости программного кода
16
168.
Анализ отказоустойчивости программного кода
16
169.
Анализ отказоустойчивости программного кода
16
170.
Анализ отказоустойчивости программного кода
17
171.
Анализ отказоустойчивости программного кода
17
172.
Анализ отказоустойчивости программного кода
17
173.
Анализ отказоустойчивости программного кода
17
174.
Анализ отказоустойчивости программного кода
17
175.
Анализ отказоустойчивости программного кода
17
176.
Анализ отказоустойчивости программного кода
17
177.
Анализ отказоустойчивости программного кода
17
178.
Анализ отказоустойчивости программного кода
17
179.
Анализ отказоустойчивости программного кода
17
180.
Анализ отказоустойчивости программного кода
18
181.
Анализ отказоустойчивости программного кода
18
182.
Анализ отказоустойчивости программного кода
18
183.
Анализ отказоустойчивости программного кода
18
184.
Анализ отказоустойчивости программного кода
18
185.
Анализ отказоустойчивости программного кода
18
186.
Анализ отказоустойчивости программного кода
18
187.
Анализ отказоустойчивости программного кода
Выводы по теме 4
В рамках данной темы были получены знания в
области оценки показателей надежности работы
программного кода. Рассмотрен жизненный цикл
программной ошибки и особенности каждого этапа
этого жизненного цикла. Даны базовые знания в
области различный моделей оценки надежности
программного кода.
187
188.
Анализ отказоустойчивости программного кода
Вопросы для
самостоятельного изучения:
1.
2.
3.
4.
5.
6.
Методы оценки на основе моделей сложности;
Архитектурные методы анализа;
Свойства динамических методов анализа кода;
Цепи Маркова;
Римская модель;
Эмпирические методы динамического анализа кода.
18
189.
Кафедра КБ-4 «Автоматизированные системы управления»
189
По оценке OWASP, почти треть всех веб-приложений содержит серьезные уязвимости, а в отчете Micro Focus 2019 Application Security Risk Report отмечается, что практически все веб-приложения имеют проблемы с безопасностью. Зная об этом, передовые компании уже давно проводят анализ исходного кода. Если несколько десятков лет назад ошибки в коде нужно было искать вручную или с помощью предупреждений компилятора, то сейчас в распоряжении разработчиков есть множество методик и инструментов – SAST, DAST, анализаторы композиции кода, фаззинг-тестирование, проверки на проникновение и многое другое. С чего же начать “безопасную разработку», о которой столько говорят в профессиональных сообществах?
Дарья Орешкина
Директор по развитию бизнеса компании Web Control
Безопасность приложения – один из основных критериев качества разрабатываемого продукта. Проверка безопасности программы делается на разных этапах различными методиками и инструментами. Программный продукт в зависимости от специфики обсуждения можно описать по-разному:
- с точки зрения задействованных специалистов, это результат труда разработчиков, тестировщиков, менеджеров, инженеров развертывания и сопровождения и др.;
- с точки зрения задействованных систем программный продукт есть результат вычислений IDE, репозиториев, сборщиков, CI/CD, баг-трекеров и т.д.
Для каждого представления создаются свои регламенты и техники обеспечения безопасности. Если рассматривать программный продукт как совокупность уникального кода, заимствованного открытого кода и логики работы программы в соответствии с ее назначением, то его проверку на уязвимости можно представить тремя способами:
- Проверка кода без его выполнения.
- Проверка поведения программы без сканирования исходного кода.
- Проверка архитектуры и логики.
Имеет смысл проверять код программы уже на этапе написания. Это позволит на ранних стадиях выявить закравшиеся ошибки и уязвимости, в том числе и наследованные из открытого кода. Компоненты Open Source можно проверить на наличие известных уязвимостей еще до включения в программный проект или на стадии сборки. В части открытого кода сфокусироваться на первоочередных уязвимостях достаточно просто, так как продвинутые инструменты анализа композиции программ (SCA) идентифицируют фактические вызовы уязвимых методов, проще говоря, указывают на потенциально эксплуатируемые уязвимости. Этап проверки итогового кода программы обычно бывает трудоемким, инструменты статического анализа кода обнаруживают потенциально опасные фрагменты, и приходится разбираться, какие из обнаруженных проблем реальные, а какие для данного проекта не несут угроз. Сканирование кода и проверка информации об известных уязвимостях Open Source – разные по своей сути технологии, но обе критично важны для выявления и устранения уязвимостей на ранних стадиях цикла разработки (SDLC), до развертывания приложения.
Проверка поведения программы без сканирования исходного кода
После создания программы требуется убедиться, что ее фактическое поведение соответствует ожидаемому. Эту задачу решают инструменты динамического анализа, фаззинг-тестирование, пентесты и др. Множество атак на приложения реализуется путем передачи в программу таких данных, при обработке которых возникает неучтенная разработчиками ситуация, впоследствии используемая хакером в своих интересах. На этапе проверки поведения программы необходимо предусмотреть возможные нарушения такого рода. Проверка поведения программы необходима не только перед запуском системы в эксплуатацию, ее нужно регулярно проводить во время работы программы для выявления не обнаруженных ранее брешей.
Выявление уязвимостей без сканирования кода и его выполнения
Эта сложная и неоднозначная аналитическая задача решается путем диагностики архитектуры программного продукта и оценки выбранных схем логической реализации. Адекватное составление модели угроз на этапе проектирования продукта позволяет предугадать возможные сценарии атак и методы защиты. Это основополагающая проверка, требующая значительных экспертных усилий, она не может быть заменена проверкой кода или тестом поведения программы.
Безопасность приложения – один из основных критериев качества разрабатываемого продукта.
Как правило, в начале разработки модель угроз делают, но вот в ходе развития продукта, при добавлении новых фич и выпуске мажорных обновлений даже опытные команды время от времени забывают обновить модель угроз, проанализировать новую логику и ее реализацию.
Инструменты анализа композиции кода (SCA)
Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты, но для получения практической пользы должны быть правильно подобраны инструменты безопасной разработки. Остановимся на одном из типов оценки исходного кода.
Инструменты анализа композиции программы зародились на рубеже тысячелетий на основе методов сканирования кода, которые выявляли фрагменты кода и сопоставляли его с базами данных Open Source. Такие инструменты применялись различными компаниями, но они давали существенное количество ложных срабатываний, замедляли работу, а самое главное – не подходили для гибких сред разработки. Однако потребность в специализированных инструментах контроля Open Source росла и была обусловлена следующими факторами:
- DevOps, контейнеры на основе Linux и т.д. привели к значительному росту использования Open Source при разработке.
- Как и коммерческое ПО, открытый исходный код содержит уязвимости. Недостаток данных о том, как и какие компоненты используются, привел к тому, что компании неосознанно подвергаются значительному риску.
- Отсутствие полной информации, политик или процессов управления компонентами Open Source привели к тому, что проверка на уязвимости проводится от случая к случаю (или вообще отсутствует), а при публикации информации о найденной уязвимости для исправления затрачиваются большие усилия.
- Зрелые компании расширяют свои возможности по управлению Open Source и проводят анализ работоспособности всей программы на основе происхождения конкретного компонента и его поддержки.
- Те, кто профессионально занимаются взломами ИТ-систем, нацеливаются на репозитории компонентов с открытым кодом и инфицируют их, обеспечивая попадание вредоносного кода на раннем звене цепочки поставки ПО.
Три способа проверки на уязвимость:
- Проверка кода без его выполнения.
- Проверка поведения программы без сканирования исходного кода.
- Проверка архитектуры и логики.
Развитый функционал для поиска уязвимых компонентов
Со временем системы проверки Open Source переродились в инструменты непрерывного управления компонентами Open Source, интегрируемыми с различными инструментами разработки – репозиториями, инструментами сборки, серверами непрерывной интеграции. Переход к обнаружению уязвимостей и проблем с лицензированием в режиме реального времени позволил управлять открытым исходным кодом и идентифицировать проблемы на более ранних этапах процесса, когда их легче и быстрее устранить.
Функционал подобных инструментов довольно широк. Инструменты анализа композиции приложения проводят инвентаризацию всех компонентов Open Source в приложении, включая прямые и транзитивные зависимости, и предоставляют информацию о каждом компоненте, в том числе данные о лицензии и наличии уязвимостей.
Инструменты с наиболее развитым функционалом, в частности WhiteSource, способны снизить число уведомлений об уязвимостях в компонентах Open Source на 70% благодаря запатентованным алгоритмам приоритизации по фактическим вызовам уязвимых методов.
Сканирование кода, анализ композиции и проверка поведения не заменяют друг друга. Эти технологии вместе на выходе позволяют создавать безопасные программные продукты.
WhiteSource агрегирует информацию об уязвимостях из разных источников в собственную базу данных и предлагает разработчикам на выбор варианты исправления, от ссылок на обновления до рекомендаций по изменению системных настроек и блокировки различных функций.
Крылатое выражение «время – деньги» как нельзя лучше характеризует ситуацию с разработкой ПО. От разработчиков требуют нереальных, на первый взгляд, вещей: сделать продукт быстро и при этом чтобы он получился безопасным. В таких условиях не обойтись без автоматизации. WhiteSource может автоматизировать весь процесс отбора, утверждения и отслеживания компонентов Open Source, автоматически применять политики для блокировки уязвимого или проблемного компонента.
Лицензионная чистота
Использование Open Source поднимает еще один вопрос, требующий внимания команды разработки, – о лицензионной чистоте. Каждый компонент Open Source, а также любой компонент, от которого он может зависеть, имеет лицензию, условия которой нужно соблюдать. Существует свыше 200 различных лицензий Open Source, у каждой из которых свои условия. Выбор компонента с неподходящей лицензией может привести к самым разным последствиям, от необходимости изменения компонента до судебного иска о нарушении авторских прав. SCA-решение также призвано автоматизировать процесс соблюдения лицензионной чистоты, чтобы освободить разработчиков от несвойственных им задач.
Полный контроль на всех этапах
Сообщество разработчиков Open Source выполняет грандиозную работу в части безопасности проектов, обнаруживая уязвимости и предлагая исправления, но Open Source децентрализован по своей природе. Информация об уязвимостях компонентов публикуется на разных ресурсах, и просто невозможно вручную сопоставлять уязвимые компоненты с используемыми в своей разработке. WhiteSource на всех этапах SDLC, от выбора компонентов с открытым кодом до мониторинга релизов в эксплуатации, позволяет отслеживать уязвимости и лицензионные соглашения Open Source.
В настоящее время информационные технологии проникли практически во все сферы ведения бизнеса. Для решения бизнес-задач создаются крупные, распределенные, постоянно модифицируемые информационные системы с тенденцией к усложнению. Они могут иметь в своем составе как готовые решения, так и внешние IT-сервисы (SaaS), собственные и заказные разработки, бесплатные продукты с открытым исходным кодом (open source). Проблемы в их работе приводят к нарушению информационной безопасности, а как следствие, к финансовым и репутационным потерям бизнеса. По данным исследования [9], последние четыре года финансовые потери бизнеса растут из-за кибератак. Повышение сложности используемых программных комплексов, их включение в контур систем управления государством и производством промышленной продукции требуют постоянного совершенствования методов тестирования, испытаний и контроля программного обеспечения.
Большинство методов анализа ПО, применяемого в аудите безопасности программных систем, можно разделить на две группы (рис. 1) — динамические методы (функциональное тестирование) и статические методы (структурное тестирование).
Рис. 1. Примерная классификация видов анализа программ (цветом выделены те виды анализа, о которых говорится в данной статье)
Динамический анализ представляет собой совокупность всех методов анализа программного обеспечения, реализуемых с помощью программ на реальном или виртуальном процессоре. Такие способы наиболее востребованы при исследовании программ методом «черного ящика» (black box), когда имеется доступ лишь к внешним интерфейсам программного обеспечения без учета их структуры, внутренних интерфейсов и состояния [5]. Этот подход не всегда эффективен при поиске ошибок, связанных с комбинациями редко используемых входных данных, а также при выявлении скрытого программного функционала (программных закладок), внесенного туда преднамеренно.
Для своей работы статический анализ не требует реализации программного кода и допускает полную или частичную автоматизацию процесса, но предполагает доступ не только к загрузочным и объектным модулям, но и к исходным текстам программной системы, к информации, связанной со средой компиляции и выполнением программных компонентов [3–5].
В соответствии с вышеизложенным для одновременного решения задач выявления случайных дефектов кода и программных закладок предлагается использовать методы статического анализа.
Методы статического анализа кода
Статический анализ исходных текстов программного обеспечения тесно связан с принципами работы компиляторов. Многие подходы такого анализа основаны на некоторых элементах компиляции, в частности, промежуточное представление исходных текстов в статических анализаторах эволюционирует совместно с развитием теории компиляторов. Современные методы анализа в целях унификации алгоритмов используют различные модели представления кода, например лексический разбор, синтаксическое дерево, дерево Канторовича, графы потока данных и управления и т. д. [1].
Подход, получивший название сигнатурного анализа, подразумевает поиск дефектов в программном коде путем сопоставления фрагментов кода с образцами из базы данных шаблонов (сигнатур) дефектов безопасности. В зависимости от технологии, применяемой при сопоставлении фрагмента кода и шаблона, а также от промежуточного представления, могут использоваться как обычные алгоритмы поиска подстроки в строке, так и регулярные выражения, специальные языки запросов по структурированной информации, в частности XQuery для XML, или специально разработанные для этой задачи способы сопоставления. В [2] приведены примеры правил формирования сигнатур ошибок, соответствующих стандарту CWE. Признакам потенциально опасных конструкций в программных системах и методам оценки их безопасности посвящены статьи 6, 7].
Самый простой способ поиска потенциально опасных конструкций — применение регулярных выражений. Этот вариант достаточно прост в реализации (легко добавляются новые шаблоны уязвимостей), однако имеет несколько критических недостатков. В первую очередь к ним относится невозможность создать шаблоны для сложных дефектов, причем даже для простых дефектов кода регулярное выражение может занимать очень много места, а также очень низкая скорость поиска.
Более эффективным считается построение промежуточного представления кода и его анализ. Именно такой способ используется почти во всех современных анализаторах кода. Общее представление структуры статического анализатора показано на рис. 2.
Рис. 2. Структура статического анализатора
На начальном этапе решение задачи анализа исходного кода напоминает действия компилятора либо интерпретатора (в случае динамического языка). Исходные тексты разбиваются на лексемы, на основании которых впоследствии строится абстрактное синтаксическое дерево (Abstract syntax tree — AST) и в дальнейшем семантический граф (Abstract semantic graph — ASG). Далее AST и ASG анализируются механизмом, подобным поиску регулярных выражений в тексте, либо используются скрипты для анализа. Помимо этого, анализ графов выполнения и потоков данных (Data Flow analysis) может дать полезную информацию.
Примеры дефектов кода
Самые распространенные виды дефектов кода — ошибки программирования и злонамеренно внесенный код. Следует заметить, что не всякая ошибка программирования приводит к возникновению уязвимости, а только те, в результате эксплуатации которых страдают защищенность, целостность и доступность данных. Злонамеренно внесенный код, как правило, позволяет получить несанкционированный доступ к системе, но бывают и другие типы дефектов, приводящие, например, к удаленному выполнению кода, сбору и отправке конфиденциальной информации либо к реализации несанкционированных действий при наступлении определенного момента времени (time bomb).
К наиболее известным и опасным уязвимостям нужно отнести уязвимости следующих видов:
Отсутствие проверки вводимых данных
Уязвимость появляется, если не производится проверка данных, поступивших из поля ручного ввода данных; от пользователя ожидается простая информация, например имя, email, текст короткого сообщения. Если при этом в поле ввода дописать код специально сформированной команды SQL или Javascript, то данный код будет выполнен. Например:
$stmt = prepare_query(«SELECT * FROM users WHERE username =?»);
В данном примере каждый параметр передается через отдельный метод bind_param, который и осуществляет фильтрацию специальных символов и ключевых слов.
Ошибки работы с памятью
Чаще всего встречаются ошибки, приводящие к переполнению буфера. Они, как правило, возникают в программах на языках C и C++. Если программа получает данные извне и копирует их во внутренний буфер без проверки размера копируемой области памяти, то при получении достаточно большого объема сведений происходит запись передаваемых данных на место адреса возврата и данных других процедур в области памяти стека. Эта ошибка может быть использована злоумышленником, который подставит нужное значение на место адреса возврата таким образом, чтобы в процессе возврата из подпрограммы переход осуществлялся вовнутрь той же перезаписанной области данных, где можно разместить вредоносный код. Пример уязвимого кода:
int main(int argc, char *argv[]) <
strcpy(buf, argv[1]);
// копирование
// без проверки длины
Пример безопасного кода:
int main(int argc, char *argv[]) <
strncpy(buf, argv[1], sizeof(buf));
// копируется не больше
Ошибки реализации
При проектировании и разработке решений для безопасности информационной системы не следует допускать появления в программном коде уязвимостей, которые в дальнейшем могут создать прецеденты нарушения информационной безопасности. К таким уязвимостям относятся:
Вредоносный код
Один из распространенных примеров вредоносного кода — внедрение разработчиком-злоумышленником возможностей несанкционированного доступа: доступа не только на основании допустимых аутентификационных сведений из базы данных, но и тех данных, о которых знает только разработчик-злоумышленник. Чаще всего к подобной информации относятся пароли-константы, но возможны и пароли, зависящие от даты и времени либо внешних поступающих данных.
Распространены и так называемые логические бомбы, действующие следующим образом: при наступлении определенного момента или при поступлении определенных входных данных программа меняет логику работы на вредоносную.
Эффективность статического анализа
Сегодня использование статических анализаторов становится объективной потребностью для обеспечения защищенности современных программных систем с высоким уровнем доверия. Введение новых стандартов разработки безопасного ПО подтверждает необходимость эффективных инструментов, поддерживающих качество программного кода.
Использование AppСhecker [8] позволяет существенно упростить и сократить затраты на ревизию кода при разработке программ, а также повысить качество кода и сократить количество ошибок и уязвимостей еще на этапе проектирования, что также позитивно скажется на затратах на доработку и поддержку выпускаемого ПО.
Помимо основного функционала в любом программном обеспечении, взаимодействующем с пользователем, очень важно удобство его применения. Удобный и понятный интерфейс (рис. 3), интеграция в процесс разработки, простота установки, обновления и поддержки становятся важными характеристиками анализаторов кода. Тем не менее сделать анализатор полностью автоматическим, действующим по «нажатию одной кнопки», невозможно.
Рис. 3. Общий вид рабочего экрана AppChecker
Как уже упоминалось, работа анализатора во многом близка работе компилятора. И для того чтобы провести качественный анализ, требуются те же действия, которые выполняет система сборки: проанализировать зависимости в проекте, распознать и «подключить» библиотечные функции и т. д., что может потребовать дополнительных настроек процесса анализа. В сравнении с другими статическими анализаторами, AppСhecker предоставляет пользователям бо? льшую гибкость в настройке: он понятен простым пользователям, а опытные разработчики смогут интегрировать его в процесс сборки любой сложности.
Важной составляющей безопасности кода является применение проверенных сторонних компонентов — библиотек или готовых программ с открытым исходным кодом. Их можно проверить, сообщая авторам о найденных уязвимостях и создавая базу уязвимостей open-source библиотек. Это особенно актуально для поддерживаемых анализатором AppСhecker интерпретируемых языков PHP, Javascript, в которых программы хранятся в виде исходных текстов.
Заключение
В статье рассмотрен метод статического анализа исходных кодов программного обеспечения, а также основные задачи и проблемы реализации автоматизированной проверки кода на примере статического анализатора AppChecker. Авторы данного продукта разработали эту технологию для удовлетворения потребностей рынка средств управления качеством исходного кода программ.
Анализ безопасности исходного кода как ключевой элемент DevSecOps
Процесс безопасной разработки невозможен без обеспечения безопасности исходного кода. Для поиска уязвимостей в создаваемых приложениях существует отдельный класс инструментов, который сейчас активно развивается, в том числе и под давлением регуляторов. Вместе с ведущими экспертами отрасли мы попытались разобраться в том, какие бывают средства тестирования исходного кода, какие задачи можно решать при помощи таких сканеров и каковы перспективы развития этого рынка.
Введение
Мы продолжаем обсуждать различные аспекты методологии DevSecOps в рамках цикла онлайн-конференций AM Live. В феврале ведущие эксперты рынка рассказали зрителям об основах безопасной разработки, а очередная встреча, прошедшая в конце марта, была посвящена обеспечению безопасности исходного кода. Мы собрали группу экспертов, чтобы обсудить, какие сканеры безопасности исходного кода представлены на рынке, чем отличаются решения классов SAST, DAST и IAST и что такое RASP-инструменты, а также порассуждать о перспективах отрасли.
В студии Anti-Malware. ru собрались:
Модерировал беседу Андрей Бешков — руководитель направления развития бизнеса компании Softline.
Зачем проверять код на безопасность
В начале дискуссии модератор предложил обсудить базовые вопросы и попросил экспертов рассказать о том, для чего вообще существуют различные сканеры безопасности и какую пользу они могут принести компании.
Первой слово взяла Дарья Орешкина, которая отметила, что организации важно понимать, где и какие фрагменты кода используются и кто их автор. При обнаружении ошибок в отдельном фрагменте необходимо оценить то, какие системы затрагивает эта проблема, и оперативно их исправить, желательно силами автора. Валерий Куваев согласился с коллегой и добавил, что следует исходить из задачи, которую организация ставит перед собой. Это могут быть требования регуляторов или желание снизить риски от кибератак.
Алексей Жуков поделился мнением, что компании уже научились управлять уязвимостями в периметре безопасности, устанавливая патчи на типовые, массовые программы — операционные системы и базы данных. Однако наряду с ними в организации могут использоваться уникальные приложения, написанные специально под определённые задачи — например, веб-сайты. Чтобы такие программы не стали точкой входа для злоумышленников, необходимо найти и устранить в них уязвимости.
По мнению Анны Архиповой, защита должна быть встроена на всех уровнях, поскольку каждый из них зависит от другого и влияет на общую безопасность организации. Сергей Деев отметил, что используемые компаниями приложения могут иметь разные задачи, однако статический анализ кода — это универсальный инструмент, который подходит абсолютно для всех типов программ. Подводя итог высказываниям коллег, Артём Синицын сказал, что в общем случае основная задача анализа кода — это обеспечение безопасности приложений или сервисов в процессе их эксплуатации. Если говорить конкретнее, то сканеры кода позволяют уменьшить издержки разработчика на устранение уязвимостей обнаруженных после релиза системы.
Чем раньше наступит стадия, когда компания начинает думать о безопасности кода, тем меньше времени, денег и других ресурсов потребуется на патчинг. Как отметили наши эксперты, чем раньше начнёшь анализ кода, тем меньше заплатишь в итоге. Существуют сервисы и приложения, которые напрямую связаны с выручкой компании — например, финансовые и торговые программы. Цена компрометации таких систем несёт не только репутационные, но и прямые денежные убытки для компании. Статический анализ позволяет решить задачу обеспечения безопасности кода на самых ранних этапах. Безусловно, это — не единственный инструмент безопасной разработки, но первый и необходимый шаг.
Сканирование кода на безопасность позволяет разработчику лучше контролировать процесс, после выпуска патча такой возможности практически не существует и создатель обновления не может управлять его использованием. Идеология Shift Left (смещение вопросов связанных с безопасностью как можно ближе к началу разработки) позволяет снизить потенциальные издержки от проблем и для разработчика, и для заказчика.
Использовать ли сканеры с открытым исходным кодом
Ещё один вопрос, который обсудили спикеры онлайн-конференции AM Live, — насколько допустимо использовать бесплатные (open-source) продукты для анализа кода. Как отметили эксперты, такие разработки могут обеспечить некоторый базовый уровень безопасности, однако для поиска уязвимостей второго порядка чаще всего необходимы специализированные ИБ-продукты. Платные инструменты часто обладают расширенной рекомендательной функциональностью. Это важно, поскольку в ряде случаев мало сообщить о проблеме, надо ещё и объяснить, что необходимо сделать, вплоть до автоматического исправления проблемного кода. Детальное описание уязвимостей и разработка рекомендаций по их исправлению требуют очень больших усилий и затрат от разработчиков сканеров, а опенсорс-команды часто ими не обладают.
Как отметил Артём Синицын, не бывает полностью бесплатного ПО и тем более не бывает дешёвой безопасности. В то же время нельзя говорить, что лучше — коммерческий сканер или бесплатный; можно говорить о том, какой инструмент лучше подходит для решения определённой задачи. Можно комбинировать различные ядра для анализа кода на разных стадиях проекта, а также применять разные сканеры для разных разработок.
Мы поинтересовались у зрителей прямого эфира, анализируют ли они исходный код своих проектов на предмет безопасности. Как оказалось, в организациях 30 % респондентов действует специальный регламент по проверке кода. Ещё 20 % опрошенных сообщили, что код анализируется, но этот процесс не поставлен на регулярную основу. Не анализируют код 17 % наших зрителей, а 18 % из них уверены в чистоте используемого в их проектах кода. Отдали процесс обеспечения безопасности кода на аутсорсинг 15 % опрошенных.
Рисунок 1. Анализируете ли вы исходный код своих проектов на безопасность?
Что такое SAST, DAST, IAST и с чего нужно начинать внедрение анализа безопасности исходного кода
Вместе с нашими экспертами мы попытались разобраться в терминологии, существующей на рынке анализа безопасности исходного кода, и попросили рассказать, чем же отличаются друг от друга и для чего предназначены технологии динамической, статической и интерактивной проверки.
Анна Архипова:
— Каждый инструмент используется на своём этапе DevSecOps. Статический анализатор поможет при написании кода и определении архитектуры приложения, динамическая проверка и, возможно, IAST будут полезны при сборке и тестировании программы. Ни один из инструментов не обеспечивает полной безопасности кода, но в комплексе они дают хороший результат.
Валерий Куваев:
— Выбор средства анализа кода зависит от возможностей и прав «заказчиков» — имеют ли они доступ к коду или могут оперировать только на уровне приложения. Безусловно, в идеале стоит начать со статического тестирования, но и другие инструменты не стоит сбрасывать со счетов.
Сергей Деев:
— Компании по-разному подходят к разработке, но если стоит цель сделать этот процесс безопасным, то SAST — это один из базовых инструментов. Однако стоит не противопоставлять статический и динамический анализ, а использовать все доступные инструменты, чтобы сделать код безопасным. Некоторые типы уязвимостей можно определить только в статике, некоторые — только в динамике, а целый ряд проблем находится на стыке возможностей этих двух инструментов.
Дарья Орешкина:
— Не стоит забывать о рисках юридического характера. Компании необходимо понимать, какая часть кода ей принадлежит, кто будет обладать правами на код в случае разделения бизнеса, а также [каковы] лицензионные требования сторонних компонентов. Анализ кода в этом случае может стать средством автоматизации работы юристов.
Артем Синицын:
— Чтобы понять текущую классификацию решений для сканирования кода, достаточно запомнить пять аббревиатур. Исторически существуют статический (SAST) и динамический (DAST) анализ, а также гибридный подход (IAST). Кроме того, существует FAST, или фаззинг — подраздел динамического тестирования на основе обратной связи. Наконец, нельзя забывать и о RASP (Runtime Application Self-Protection), технологии, которая скорее является внутренним файрволом приложения и используется для анализа и блокировки атак в реальном времени.
Алексей Жуков:
— В контексте безопасности приложений необходимо помнить об ещё одной технологии: WAF (Web Application Firewall). Это — накладное средство безопасности, которое позволяет заблокировать определённые известные уязвимости и выпустить программу дав разработчику время для исправления проблемы.
Эксперты упомянули также о продуктах класса SCA, предназначенных для анализа сторонних компонентов, используемых в системе. Базовые варианты таких решений способны формировать список сторонних библиотек, включённых в разработку, и уязвимостей в них. Более совершенные SCA-продукты способны оценить методы работы проприетарного кода и понять, возможно ли эксплуатировать найденные уязвимости в конкретной системе.
Зрители онлайн-конференции AM Live считают, что в первую очередь необходимо уделять внимание статическому анализу кода. За это в ходе проведённого нами опроса высказались 69 % респондентов. Ещё 21 % опрошенных отдают предпочтение динамическому анализу. За анализ сторонних компонентов и интерактивный анализ (IAST) отдали свои голоса 7 % и 3 % соответственно.
Рисунок 2. На какие способы анализа безопасности приложений вы обращаете внимание в первую очередь?
Что мешает внедрять средства анализа безопасности кода
Эксперты обсудили организационные проблемы, возникающие при внедрении средств анализа исходного кода. Как выяснилось, одним из существенных препятствий в этом процессе является сложность взаимодействия специалистов по информационной безопасности и разработчиков. Нередко у программистов бывает свой взгляд на степень критической важности уязвимости и приоритет её исправления. Как отметили спикеры, в ряде случаев прийти к общему знаменателю могут помочь базы данных уязвимостей, однако даже самый большой реестр не всегда применим к конкретной разработке. К тому же у каждого приложения — своя модель угроз. Поэтому оценку значимости найденных проблем необходимо выполнять в контексте конкретной разработки. Помочь в приоритизации может интерактивный анализ.
По мнению экспертов в студии, закладывать требования к безопасности программы необходимо ещё на этапе создания её архитектуры, наравне с функциональными возможностями. Важно также понимать, что ошибка не всегда является уязвимостью. Чтобы правильно построить диалог с разработчиками, следует предоставить как можно больше структурированной информации об обнаруженной проблеме со ссылками на международную практику и другие источники — в привязке к коду и в понятных терминах.
На вопрос «Что ограничивает вас во внедрении анализа безопасности исходного кода?» 28 % зрителей онлайн-трансляции ответили, что им мешает сопротивление внутри компании. Столько же голосов набрал вариант «Дефицит внутренних ресурсов». Высокая стоимость технологий анализа исходного кода на безопасность ограничивает 20 % опрошенных, а увеличение срока выхода релизов — 8 % респондентов. Наконец, 16 % наших зрителей сообщили, что в их компании этот процесс находится на стороне подрядчика.
Рисунок 3. Что ограничивает вас во внедрении анализа безопасности исходного кода?
Перспективы рынка: уйдёт ли анализ кода на безопасность в облако
В завершение беседы ведущий конференции AM Live предложил гостям в студии порассуждать о перспективах рынка и, в частности, обсудить то, будут ли анализаторы кода мигрировать в облако. Эксперты отметили, что на западном рынке этот процесс уже идёт и вендоры получают до 50 % своей прибыли от облачных систем безопасности кода. В России этот тренд также заметен, хотя и не так значим. Некоторое недоверие к облачным технологиям в нашей стране обусловлено в том числе и слабой нормативной базой, которая, впрочем, сейчас активно развивается.
Мы спросили у зрителей конференции, готовы ли они отдать анализ исходного кода в облако. Большинство участников опроса — 62 % — отрицательно отнеслись к такой возможности. Готовы использовать облачные технологии в том случае, если серверы находятся на территории России, 19 % респондентов; столько же доверяют анализу кода в облаке без дополнительных условий.
Рисунок 4. Готовы ли вы производить анализ безопасности исходного кода в облаке?
Ещё одна тенденция, которую отметили наши эксперты, — усиление требований регулирующих органов в части безопасности кода. Если ранее разработчики в первую очередь заботились о соответствии функциональным требованиям, то сейчас для поставки решений в критически важные отрасли необходимо думать не только о безопасности используемой инфраструктуры, но и о безопасности кода.
Важным вектором на ближайшие несколько лет эксперты назвали более активное использование опенсорс-компонентов, в том числе и в проприетарных разработках, а также увеличение сложности кода создаваемых программ. Всё это будет стимулировать спрос на решения способные анализировать большее количество уровней вложенности и зависимостей.
По итогам конференции мы поинтересовались у зрителей тем, как изменилось их мнение относительно технологий анализа кода после просмотра прямого эфира. Почти четверть опрошенных — 24 % — заинтересовались анализаторами и выразили готовность начать их тестирование. Чуть больше — 28 % респондентов — считают, что такое решение будет избыточно для их компании. Почти треть участников опроса уже используют сканеры исходного кода — за этот вариант отдали свои голоса 32 % зрителей. Ещё 4 % опрошенных выразили мнение, что спикеры онлайн-конференции не смогли доказать необходимость таких инструментов, а 12 % вообще не поняли, о чём шла речь.
Рисунок 5. Каково ваше мнение относительно анализаторов безопасности исходного кода?
Выводы
Мы планируем продолжить обсуждение различных аспектов DevSecOps с экспертами в этой сфере. Кроме того, зрителей ждут новые выпуски конференции AM Live, посвящённые и другим актуальным для отечественного рынка информационной безопасности вопросам. Чтобы оставаться в курсе ключевых тенденций, иметь возможность в прямом эфире наблюдать дискуссии лидеров мнений и общаться с ними в процессе онлайн-трансляции, подписывайтесь на наш YouTube-канал и включайте уведомления о новых материалах. До встречи на конференции AM Live!
Источники:
https://controlengrussia. com/programmnye-sredstva/bezopasnost-programmnye-sredstva/appchecker/
https://www. anti-malware. ru/analytics/Technology_Analysis/Source-security-analysis
Введение
Методические
указания по проведению лабораторных работ составлены в соответствии с
содержанием рабочей программы ПМ03 «Ревьюирование программных модулей» (МДК 03.02
«Управление проектами» входит в профессиональный цикл учебного плана для
специальности 09.02.07 Информационные системы и программирование.
В результате
освоения ПМ03 «Ревьюирование программных модулей» студент должен:
иметь
практический опыт в:
— измерении характеристик
программного проекта;
— использовании основных
методологий процессов разработки программного обеспечения;
— оптимизации программного
кода с использованием специализированных программных средств;
уметь:
— работать с проектной
документацией, разработанной с использованием графических языков спецификаций;
— выполнять оптимизацию
программного кода с использованием специализированных программных средств;
— использовать методы и
технологии тестирования и ревьюирования кода и проектной документации;
— применять стандартные
метрики по прогнозированию затрат, сроков и качества.
знать:
— задачи планирования и
контроля развития проекта;
— принципы построения системы
деятельностей программного проекта;
—
современные
стандарты качества программного продукта и процессов его обеспечения.
Методические указания по проведению
лабораторных работ могут быть использованы студентами для самостоятельной
работы, преподавателями на учебных занятиях.
Методические
указания по выполнению лабораторных работ содержат теоретические основы, которыми
студенты должны владеть перед проведением лабораторной работы.
Одна лабораторная
работа рассчитана на 2 часа.
Техника безопасности при выполнении
лабораторной работы
К работе с ПК допускаются лица, ознакомленные
с его устройством, принципом работы, и настоящим методическим
пособием.
Вход в лабораторию осуществляется только по разрешению
преподавателя.
На первом занятии преподаватель проводит инструктаж по
технике безопасности и напоминает студентам о бережном отношении к лаборатории
и о материальной ответственности каждого из них за сохранность оборудования и
обстановки лаборатории.
При обнаружении повреждений ПК персональную
ответственность несут студенты, выполнявшие лабораторную работу на этом ПК.
Виновники обязаны возместить материальный ущерб колледжу.
При ознакомлении с рабочим местом проверить наличие
комплектности оборудования и соединительных проводов (в случае отсутствия
какого либо элемента, необходимо немедленно сообщить об этом преподавателю).
Если во время проведения работы замечены какие-либо
неисправности оборудования, необходимо немедленно сообщить об этом
преподавателю.
После окончания лабораторной работы рабочее место привести в порядок.
Методические указания к проведению
лабораторных работ для студентов
1.
К
лабораторной работе необходимо подготовиться до начала учебного занятия.
2.
При
подготовке к лабораторной работе используйте рекомендованную литературу,
предложенную в данных методических указаниях, а также конспекты лекций.
3.
К
лабораторной работе допускаются студенты, освоившие необходимый теоретический
материал.
4.
По
окончании выполнения заданий лабораторной работы проверьте себя, ответив на
контрольные вопросы для самопроверки.
5.
Если
предложенные задания из лабораторной работы не выполнены в указанные сроки по
неуважительной причине, оценка снижается.
Техника безопасности при проведении лабораторных работ
Правила техники безопасности в компьютерном кабинете
К работе в кабинете информатики допускаются только учащиеся и
преподаватели, прошедшие инструктаж по технике безопасности, соблюдающие
указания преподавателя, расписавшиеся в журнале регистрации инструктажа.
Необходимо неукоснительно соблюдать правила по технике
безопасности, т.к. нарушение этих правил может привести к поражению электрическим
током, вызвать возгорание и навредить вашему здоровью.
При эксплуатации
оборудования необходимо остерегаться:
— поражения электрическим током;
— механических повреждений, травм.
Требования безопасности перед началом работы
1. Запрещено входить в кабинет
в верхней одежде, головных уборах, с громоздкими предметами и едой.
2. Запрещено входить в кабинет информатики в грязной обуви без бахил или без
сменной обуви.
3. Запрещается шуметь, громко разговаривать и отвлекать других учащихся.
4. Запрещено бегать и прыгать, самовольно передвигаться по кабинету.
5. Перед началом занятий все личные мобильные устройства учащихся (телефон,
плеер и т.п.) должны быть выключены.
6. Разрешается работать только на том компьютере, который выделен на занятие.
7. Перед началом работы учащийся обязан осмотреть рабочее место и свой
компьютер на предмет отсутствия видимых повреждений оборудования.
8. Запрещается выключать или включать оборудование без разрешения преподавателя.
9. Напряжение в сети кабинета включается и выключается только преподавателем.
Требования безопасности во время работы
1. С техникой
обращаться бережно: не стучать по мониторам, не стучать мышкой о стол, не
стучать по клавишам клавиатуры.
2. При возникновении неполадок: появлении изменений в функционировании
аппаратуры, самопроизвольного её отключения необходимо немедленно прекратить
работу и сообщить об этом преподавателю.
3. Не пытаться исправить неполадки в оборудовании самостоятельно.
4. Выполнять за компьютером только те действия, которые говорит преподаватель.
5. Контролировать расстояние до экрана и правильную осанку.
6. Не допускать работы на максимальной яркости экрана дисплея.
7. В случае возникновения нештатных ситуаций сохранять спокойствие и чётко
следовать указаниям преподавателя.
Запрещается
1. Эксплуатировать
неисправную технику.
2. При включённом напряжении сети отключать, подключать кабели, соединяющие
различные устройства компьютера.
3. Работать с открытыми кожухами устройств компьютера.
4. Касаться экрана дисплея, тыльной стороны дисплея, разъёмов, соединительных
кабелей, токоведущих частей аппаратуры.
5. Касаться автоматов защиты, пускателей, устройств сигнализации.
6. Во время работы касаться труб, батарей.
7. Самостоятельно устранять неисправность работы клавиатуры.
8. Работать грязными, влажными руками, во влажной одежде.
9. Работать при недостаточном освещении.
10. Работать за дисплеем дольше положенного времени.
Запрещается без разрешения преподавателя
1. Включать и выключать
компьютер, дисплей и другое оборудование.
2. Использовать различные носители информации (дискеты, диски, флешки).
3. Подключать кабели, разъёмы и другую аппаратуру к компьютеру.
4. Брать со стола преподавателя дискеты, аппаратуру, документацию и другие
предметы.
5. Пользоваться преподавательским компьютером.
Требования безопасности по окончанию работы
1.
По окончании работы дождаться пока преподаватель подойдёт и
проверит состояние оборудования, сдать работу, если она выполнялась.
2. Медленно встать, собрать свои вещи и тихо выйти из класса, чтобы не мешать
другим учащимся.
Лабораторная
работа 1
Тема: Использование метрик
программного продукта.
Цель
лабораторной работы: изучение требований к создаваемому программному
продукту, разработка технического задания.
Теоретическая
часть:
Техническое
задание представляет собой документ, в котором сформулированы основные цели
разработки, требования к программному продукту, определены сроки и этапы
разработки и регламентирован процесс приемно-сдаточных испытаний.
В
разработке технического задания участвуют как представители заказчика, так и
представители исполнителя.
В
основе этого документа лежат исходные требования заказчика, анализ передовых
достижений техники, результаты выполнения научно-исследовательских работ,
предпроектных исследований, научного прогнозирования.
Основные
факторы, определяющие характеристики разрабатываемого программного обеспечения:
—
исходные данные и требуемые результаты, которые определяют функции программы
или системы;
—
среда функционирования (программная и аппаратная);
—
возможное взаимодействие с другим программным обеспечением или специальными
техническими средствами;
—
также может быть определено, а может выбираться исходя из набора выполняемых
функций.
Разработка
технического задания выполняется в следующей последовательности. Прежде всего,
устанавливают набор выполняемых функций, а также перечень и характеристики
исходных данных.
Затем
определяют перечень результатов, их характеристики и способы представления.
Далее уточняют среду функционирования программного обеспечения: конкретную
комплектацию и параметры технических средств, версию используемой операционной
системы и, возможно, версии и параметры другого установленного программного
обеспечения, с которым предстоит взаимодействовать будущему программному
продукту.
В
случаях, когда разрабатываемое программное обеспечение собирает и хранит
некоторую информацию или включается в управление каким-либо техническим
процессом, необходимо также четко регламентировать действия программы в случае
сбоев оборудования и энергоснабжения.
На техническое
задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к
содержанию и оформлению».
В
соответствии с этим стандартом техническое задание должно содержать следующие
разделы:
—
введение;
—
основания для разработки;
—
назначение разработки;
—
требования к программе или программному изделию;
—
требования к программной документации;
—
технико-экономические показатели;
—
стадии и этапы разработки;
—
порядок контроля и приемки.
При
необходимости допускается в техническое задание включать приложения. Рассмотрим
более подробно содержание каждого раздела. Введение должно включать
наименование и краткую характеристику области применения программы или
программного продукта, а также объекта (например, системы) в котором предполагается
их использовать. Назначение введения — продемонстрировать актуальность данной
разработки и показать, какое место эта разработка занимает в ряду подобных.
Раздел
Основания для разработки должен содержать наименование документа, на
основании которого ведется разработка, организации, утвердившей данный
документ, и наименование или условное обозначение темы разработки. Таким
документом может служить план, приказ, договор и другие.
Раздел
Назначение разработки должен содержать описание функционального и эксплуатационного
назначения программного продукта с указанием категорий пользователей.
Раздел
Требования к программе или программному изделию должен включать
следующие подразделы:
—
требования к функциональным характеристикам;
—
требования к надежности;
—
условия эксплуатации;
—
требования к составу и параметрам технических средств;
—
требования к информационной и программной совместимости;
—
требования к маркировке и упаковке;
—
требования к транспортированию и хранению;
—
специальные требования.
Наиболее
важным из перечисленных выше является подраздел Требования к функциональным
характеристикам. В этом разделе должны быть перечислены выполняемые функции и
описаны состав, характеристики и формы представления исходных данных и
результатов. В этом же разделе при необходимости указывают критерии
эффективности: максимально допустимое время ответа системы, максимальный объем
используемой оперативной и/или внешней памяти.
Примечание. Если
разработанное программное обеспечение не будет выполнять указанных в
техническом задании функций, то оно считается не соответствующим техническому
заданию, т. е. неправильным с точки зрения критериев качества.
Универсальность
будущего продукта также обычно специально не оговаривается, но подразумевается.
В
подразделе Требования к надежности указывают уровень надежности, который должен
быть обеспечен разрабатываемой системой и время восстановления системы после
сбоя. Для систем с обычными требованиями к надежности в этом разделе иногда
регламентируют действия разрабатываемого продукта по увеличению надежности
результатов (контроль входной и выходной информации, создание резервных копий
промежуточных результатов).
В
подразделе Условия эксплуатации, указывают особые требования к условиям
эксплуатации: температуре окружающей среды, относительной влажности воздуха.
Как правило, подобные требования формулируют, если разрабатываемая система
будет эксплуатироваться в нестандартных условиях или использует специальные
внешние устройства, например для хранения информации.
Здесь
же указывают вид обслуживания, необходимое количество и квалификация персонала.
В противном случае допускается указывать, что требования не предъявляются. В
подразделе Требования к составу и параметрам технических средств указывают
необходимый состав технических средств с указанием их основных технических
характеристик: тип микропроцессора, объем памяти, наличие внешних устройств.
При этом часто указывают два варианта конфигурации: минимальный и
рекомендуемый.
В
подразделе Требования к информационной и программной совместимости при
необходимости можно задать методы решения, определить язык или среду
программирования для разработки, а также используемую операционную систему и
другие системные и пользовательские программные средства, с которым должно
взаимодействовать разрабатываемое программное обеспечение. В этом же разделе
при необходимости указывают, какую степень защиты информации необходимо
предусмотреть.
В
разделе Требования к программной документации указывают необходимость наличия
руководства программиста, руководства пользователя, руководства системного
программиста, пояснительной записки. На все эти типы документов также
существуют ГОСТы.
В
разделе Технико-экономические показатели рекомендуется указывать
ориентировочную экономическую эффективность, предполагаемую годовую потребность
и экономические преимущества по сравнению с существующими аналогами.
В
разделе Стадии и этапы разработки указывают стадии разработки, этапы и
содержание работ с указанием сроков разработки и исполнителей.
В
разделе Порядок контроля и приемки указывают виды испытаний и общие
требования к приемке работы. В приложениях при необходимости приводят: перечень
научно-исследовательских работ, обосновывающих разработку; схемы алгоритмов, таблицы,
описания, обоснования, расчеты и другие документы, которые следует использовать
при разработке. В зависимости от особенностей разрабатываемого продукта
разрешается уточнять содержание разделов, т. е. использовать подразделы,
вводить новые разделы или объединять их. В случаях, если какие-либо требования,
предусмотренные техническим заданием, заказчик не предъявляет, следует в
соответствующем месте указать «Требования не предъявляются». Разработка
технического задания — процесс трудоемкий, требующий определенных навыков.
Наиболее сложным, как правило, является четкое формулирование основных
разделов: введения, назначения и требований к программному продукту.
Задание
1: Изучить нормативные документы по разработке технического задания
на разработку программного продукта.
Задание
2:
Разработать техническое задание на программный продукт по заданному варианту.
Порядок выполнения работы:
Внимательно изучите варианты заданий.
Варианты заданий:
1. Программа учета домашней медиатеки.
2. Программа планирования дел «Ежедневник».
3. Информационная система учета услуг в автомастерской.
4. Программа информационной поддержки спортивных соревнований.
5. Информационно-справочная система для продажи билетов в
кинотеатре.
6. Программа учета и анализа продаж в продовольственном магазине.
7. Информационная система факультета «Абитуриент».
8. Программа информационного обеспечения фестиваля художественной
самодеятельности студентов.
9. Программа информационной поддержки спартакиады университета.
10.Программа учета и анализа доходов и расходов семьи.
11.Программа формирования счетов-квитанций для жильцов ТСЖ.
12.Система управления теплицей.
13.Программа обработки данных аттестации студентов.
14.Визуальный конструктор Е-сетей.
15.Программа управления очередностью обслуживания клиентов в
поликлинике.
16.Программа терминала оплаты за услуги населению.
17.Программа информационной поддержки спортивных соревнований.
18.Программа учета контингента студентов на факультете.
19.Программу «Маклер» для учета заявок на обмен квартир и поиска
вариантов обмена.
20. Компьютерная игра «Сражение роботов».
Контрольные вопросы:
1. Что понимают под технологичностью программного обеспечения?
2. Какие типы программных продуктов можно выделить?
3. Назовите основные эксплуатационные требования к ПП.
4. В каких ситуациях необходимы предпроектные исследования?
5. Назовите, какой раздел технического задания можно считать
основным и почему?
Лабораторная
работа 2
Тема: Проверка
целостности программного кода.
Цель
лабораторной работы: ознакомиться с программными средствами обеспечения
безопасности и системами контроля целостности.
Теоретическая
часть:
Последние годы, по данным исследований антивирусных компаний,
характеризуются повышением активности вредоносного кода.
Одной из тенденций в создании безопасной среды является разработка
средств, обеспечивающих целостность кода, посредством выполнения его контроля.
Целостность ресурсов информационной системы – состояние
ресурсов информационной системы, при котором их изменение осуществляется только
преднамеренно субъектами, имеющими на него право, при этом сохраняются их
состав, содержание и организация взаимодействия.
Контроль целостности кода заключается в проверке состояния кода
исполняемых модулей.
Можно выделить следующие виды контроля целостности кода:
— контроль запуска (загрузки) кода;
— контроль времени выполнения;
— комбинированный.
Контроль запуска (загрузки) кода предполагает проверку
целостности модулей на самом раннем этапе.
Данный вид может обеспечивать предотвращение от загрузки
неизвестного или модифицированного кода.
Контроль времени выполнения подразумевает
периодическую проверку целостности уже загруженного в память кода.
Данный вид контроля целостности позволяет выявить наличие
вредоносной активности в вычислительной системе.
Комбинированный контроль целостности совмещает первые два
вида и предполагает, как проверку целостности кода при его загрузке, так и
периодическую проверку во время выполнения.
Для проверки целостности используются следующие методы контроля:
— сравнение данных;
— сравнение значений хеш-функций;
— установка защиты на память, содержащую код;
— проверка целостности потока выполнения.
Предлагается комбинированный вид контроля целостности, основанный
на сравнении значений хеш-функций.
Значения хеш-функций предлагается вычислять от неизменяемых частей
всех исполняемых файлов в системе и использовать одни и те же значения
хеш-функций, как для проверки целостности во время загрузки модуля в память,
так и при периодической проверке.
Проверка целостности при этом подразумевается как для модулей
режима ядра, так и для модулей, выполняющихся в пользовательском режиме.
Такой подход обеспечил бы предотвращение загрузки любых
неизвестных или модифицированных исполняемых модулей и предоставил бы
возможность обнаружения их модификации.
Для достижения цели обеспечения предотвращения загрузки
неизвестного или модифицированного кода, а также проверки целостности во время
выполнения необходимо решить следующие задачи:
— определить, какие именно части исполняемых модулей не должны
изменяться (и соответственно являются объектами контролирования целостности);
— разработать модель выполнения контроля целостности кода и
алгоритм проверки целостности.
Задание:
Определить
неизменяемые части исполняемых модулей.
Порядок выполнения работы:
При решении задачи определения неизменяемых частей,
во—первых, была проанализирована спецификация формата PE – Microsoft Portable
Executable and Common Object File Format.
По итогам анализа данной спецификации выделены следующие части
структуры PE, которые не должны модифицироваться:
— заголовок MS-DOS полностью (структура IMAGE_DOS_HEADER);
— заголовок PE полностью (структура IMAGE_NT_HEADERS32 или
IMAGE_NT_HEADERS64), включая заголовки разделов (структуры
IMAGE_SECTION_HEADER);
— разделы, в описании характеристик которых (поле Characteristics
структуры IMAGE_SECTION_HEADER) не установлен флаг разрешения записи
(IMAGE_SCN_MEM_WRITE), за исключением частей разделов, содержащих информацию об
импорте (таблицы поиска импорта – Import Lookup Table, таблицы адресов импорта
– Import Address Table).
Во-вторых, был разработан прототип программных средств по
обеспечению контроля целостности кода для проверки результатов анализа
спецификации. Данный прототип позволил внести следующие корректировки в
представленный выше список неизменяемых частей структуры модулей:
— поле AddressOfEntryPoint структуры IMAGE_OPTIONAL_HEADER из
заголовка PE (IMAGE_NT_HEADERS32/64) изменяется у всех управляемых сборок .NET
в процессе инициализации;
— поле ImageBase структуры IMAGE_OPTIONAL_HEADER из заголовка PE
(IMAGE_NT_HEADERS32/64) изменяется у всех исполняемых модулей, у которых в поле
DllCharacteristics структуры IMAGE_OPTIONAL_HEADER задан флаг
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE; данный флаг указывает, что к данному
модулю необходимо применить механизм рандомизации адресного пространства
(Address Space Layout Randomization, ASLR);
— в заголовках разделов (структуры IMAGE_SECTION_HEADER) значения
полей VirtualSize, SizeOfRawData, PointerToRawData, PointerToRelocations,
PointerToLinenumbers, NumberOfRelocations, NumberOfLinenumbers в памяти могут
отличаться от значений в исполняемом файле.
Помимо этого в ходе исследования, проводимого с помощью прототипа,
было выявлено, что у модулей, выполняющихся в режиме ядра, разделы, имеющие
флаг IMAGE_SCN_MEM_DISCARDABLE, могут выгружаться из памяти после загрузки без
возможности последующего возврата в память. К таким разделам, как правило,
относятся разделы “INIT” (содержат код инициализации модуля), “.reloc”
(содержат информацию, необходимую для переадресации) и “.rsrc” (содержат
ресурсы).
Таким образом, если исполняемый модуль – это совокупность
заголовка и разделов:
то участки
исполняемых модулей, подлежащие проверке, представляют собой совокупность
заголовка без перечисленных выше модифицируемых участков и множества разделов с
запретом на запись:
Вывод:
Таким образом, разработан метод проверки целостности исполняемых
модулей, основанный на сравнении значений хеш-функции.
Метод обеспечивает возможность использования, как для контроля
загрузки, так и для контроля времени выполнения.
Возможности такого использования метода обусловлены проверкой
только тех участков исполняемых модулей, которые не должны изменяться при их
нормальном функционировании.
Точное определение неизменяемых участков модулей получено в
результате экспериментального исследования и использовано для формального описания
модели эталонной проверочной информации. Также отличительной особенностью
метода является использование ключа при поиске эталонной проверочной
информации, что позволяет ускорить процесс проверки. Гипотеза о составе ключа
поиска подтверждена экспериментальным путём.
Разработанный метод реализован для операционной системы Windows 7.
Основной программный компонент представляет собой монолитный функциональный
драйвер.
Данный компонент реализован как драйвер виртуального устройства,
чтобы получать доступ к памяти, как модулей режима ядра, так и любых модулей
пользовательского режима, а также иметь возможность запрещать загрузку любых
неизвестных или модифицированных исполняемых модулей.
Реализация таких функций в пользовательском режиме невозможна
из-за архитектурных ограничений и реализации операционной системы.
Тестирование программного компонента показало, что он успешно
выполняет как контроль загрузки, так и контроль времени выполнения.
Однако в ходе экспериментального исследования было установлено,
что в логику работы некоторых приложений входит модификация собственного кода.
Соответственно, методы корректной обработки самомодифицирующегося
кода являются предметом дальнейших исследований.
Лабораторная
работа 3
Тема: Проверка
корректности программного кода.
Цель
лабораторной работы: ознакомиться с программными средствами обеспечения
проверки корректности программного кода.
Теоретическая
часть:
Если в общем случае рассматривать жизненный цикл системы, то
рассматриваем правую часть рисунка.
Применительно к нашей системе, жизненный цикл можно представить так:
сначала необходимо проверить код, затем архитектуру и требования.
На этапе проверки программного кода необходимо проверить
корректность работы написанного кода.
Для этого
предлагается проводить тестирование каждого модуля отдельно. То есть, будут
тестироваться модули по отдельности.
Критерии качества
делятся на два типа:
— функциональные
– определяются предметной областью и функциями выполняемой программы;
— конструктивные
– определяются общими для всех программ свойствами.
Корректность
текстов программ – степень соответствия исходных программ формализованным
правилам языков спецификаций и программирования.
Конструктивная
корректность модулей – соответствие их структуры общим правилам структурного
программирования и конкретным правилам оформления и внутреннего построения
программных модулей в данном заказе.
Функциональная
корректность модулей – корректность обработки исходных данных и
получения результатов.
Конструктивная
корректность данных определяется правилами их структурирования и упорядочения.
Функциональная
корректность данных связана в основном с конкретизацией их содержания в
процессе исполнения программ, а также при подготовке данных внешними
абонентами.
Лабораторная работа
4
Тема: Анализ потоков
данных.
Цель
лабораторной работы: познакомиться с программными средствами обеспечения
проверки корректности программного кода.
Теоретическая
часть:
Понятию «поток» соответствует последовательный переход процессора
от одной команды к другой.
Процессу операционной системы назначают адресное пространство и
набор ресурсов, которые совместно используются всеми его потоками.
Это означает, что они разделяют одни и те же глобальные
переменные. Поскольку каждый поток может иметь доступ к любому виртуальному
адресу, один поток может задействовать стек другого потока.
Между потоками одного процесса нет полной защиты. Чтобы
организовать взаимодействие и обмен данными, потокам не требуется обращаться к
операционной системе, им достаточно использовать общую память – один поток
записывает данные, а другой читает их.
Каждому потоку принадлежат следующие ресурсы:
— код исполняемой функции;
— набор регистров процессора;
— стек для работы приложения;
— стек для работы операционной системы;
— маркер доступа, который содержит информацию для системы
безопасности.
В операционных системах Windows различаются потоки двух
типов:
— системные – выполняют различные сервисы операционной
системы и запускаются ядром операционной системы;
— пользовательские – служат для решения задач пользователя
и запускаются приложением.
В работающем приложении различаются рабочие потоки (working threads) и потоки
интерфейса пользователя (user interface threads).
Рабочие потоки выполняют различные фоновые задачи в приложении.
Потоки интерфейса пользователя связаны с окнами и выполняют
обработку сообщений, поступающих эти окнам.
Качество системы – степень удовлетворения системой заявленных и
подразумеваемых потребностей различных заинтересованных сторон, которая
позволяет оценить ее достоинства.
Характеристика качества программы – некоторое поддающееся
измерению свойство, отражающее отдельные факторы, которые влияют на качество
программы.
Критерий качества – некоторый численный показатель,
характеризующий степень, которая присуща оцениваемому свойству программы.
Критерий качества должен соответствовать следующим требованиям:
— давать численную характеристику основной целевой функции
программы;
— обеспечивать возможность определить затраты, необходимые для
достижения требуемого уровня качества, и степень влияния на показатель качества
внешних факторов;
— по возможности быть простым, хорошо измеримым и иметь малую
дисперсию.
Для измерения критериев и характеристик качества программ
используют метрики, которые составляют систему измерений качества.
Такие измерения могут проводиться на уровне критериев
качества программ или на уровне отдельных характеристик качества:
— система измерений позволяет непосредственно сравнивать программы
по качеству, но сами измерения не могут быть проведены без субъективных оценок
свойств программ;
— измерения могут быть выполнены объективно и достоверно, но
оценка качества ПО в целом будет связана с субъективной интерпретацией
получаемых оценок.
При исследовании метрик ПО различают два основных подхода:
— когда ищутся метрики оценки самого ПО;
— либо используются метрики, помогающие оценить условия разработки
программы.
Задание:
1.
Классифицируйте метрики по виду информации, получаемой при оценке
качества ПО (будет 3 пункта).
2.
Классифицируйте метрики по основным направлениям применения (будет
6 групп).
Лабораторная
работа 5
Тема: Использование
метрик стилистики.
Цель
лабораторной работы: получить навыки в расчете метрик стилистики компьютерных
программ.
Теоретическая
часть:
За время своего существования программирование перестало быть
искусством отдельных исполнителей, превратившись в предмет коллективной
производственной деятельности.
Язык программирования и сами программы являются не только
средством общения программиста с компьютером, но и средством общения
программистов между собой.
Появляются новые требования к читаемости и воспринимаемости
программ, соблюдение которых упрощает контакт внутри группы разработчиков, а
также позволяет обслуживать и корректировать программы без участия
непосредственных разработчиков.
Наиболее простой метрикой стилистики и понятности является оценка
уровня комментированности программы F:
F = Nком/Nстр,
где Nком – количество комментариев в программе;
Nстр – количество строк или операторов исходного текста.
Таким образом, метрика F отражает насыщенность программы
комментариями.
Исходя из практического опыта принято считать, что F ³ 0.1, т.е. на
каждые десять строк программы должен приходиться минимум один комментарий. Как
показывают исследования, комментарии распределяются по тексту программы
неравномерно: в начале программы их избыток, а в середине или в конце –
недостаток. Это объясняется тем, что в начале программы, как правило,
расположены операторы описания идентификаторов, требующие более «плотного»
комментирования.
Кроме того, в начале программы также расположены «шапки»,
содержащие общие сведения об исполнителе, характере, функциональном назначении
программы.
Такая насыщенность компенсирует недостаток комментариев в теле
программы, и поэтому приведенная формула недостаточно точно отражает
комментированность функциональной части текста программы.
Более удачен вариант, когда вся программа разбивается на n равных
сегментов и для каждого из них определяется Fi Уровень комментированности
программы считается нормальным, если выполняется условие: F = n.
В противном случае какойлибо фрагмент программы дополняется
комментариями до нормального уровня. Необходимо подчеркнуть, что стилистика и
понятность программ тесно связана и с размером и со сложностью программ.
Поэтому не следует забывать о некоторой условности группировки
метрик программ.
Контрольные вопросы:
1. Для чего рассчитываются метрики стилистики?
2. Какие метрики стилистики существуют?
3. Как рассчитывается оценка уровня комментированности программы?
4. Какой уровень комментированности считается нормальным?
Задание:
Рассчитать
метрику уровня комментированности программы, разбив исходный код на равные
части.
Лабораторная
работа 6
Тема: Использование
метрик сложности.
Цель
лабораторной работы: получить навыки в расчете метрик потока данных компьютерных
программ.
Теоретическая
часть:
При оценке
сложности программ, как правило, выделяют три основные группы метрик:
— метрики размера
программ;
— метрики
сложности потока управления программ;
— метрики сложности
потока данных программ.
Оценки первой
группы наиболее просты и поэтому получили широкое распространение. Традиционной
характеристикой размера программ является количество строк исходного текста.
Под строкой понимается любой оператор программы.
Непосредственное
измерение размера программы, несмотря на свою простоту, дает хорошие
результаты. Оценка размера программы недостаточна для принятия решения о ее
сложности.
Таким образом,
оценка размера программы есть оценка по номинальной шкале, на основе которой
определяются только категории программ без уточнения оценки для каждой
категории. К группе оценок размера программ можно отнести также метрику
Холстеда. За базу принят подсчет количества операторов и операндов используемых
в программе, т.е. определение размера программы.
Основу метрики
Холстеда составляют четыре измеряемые характеристики программы: h1 — число
уникальных операторов программы, включая символы-разделители, имена процедур и
знаки операций (словарь операторов); h2 – число уникальных операндов программы
(словарь операндов); N1 – общее число операторов в программе N2 – общее число
операндов в программе.
Опираясь на эти
характеристики, получаемые непосредственно при анализе исходных текстов
программ, Холстед вводит следующие оценки:
— Словарь
программы h=h1 + h2
— Длину
программы N=N1+N2
— Объем
программы V=N log2 h
Смысл оценок h и
N достаточно очевиден, поэтому подробно рассмотрим только характеристику V.
Количество символов, используемых при реализации некоторого алгоритма,
определяется в числе прочих параметров и словарей программы h, представляющим
собой минимально необходимое число символов, обеспечивающих реализацию
алгоритма.
Далее Холстед
вводит h* — теоретический словарь программы, т.е. словарный запас, необходимый
для написания программы с учетом того, что необходимая функция уже реализована
в данном языке и, следовательно, программа сводится к вызову этой функции.
Следующей
метрикой сложности потока данных программ является метрика Чепина.
Существует
несколько ее модификаций. Рассмотрим более простой, а с точки зрения
практического использования – достаточно эффективный вариант этой метрики.
Суть метода
состоит в оценке информационной прочности отдельно взятого программного модуля
с помощью анализа характера использования переменных из списка ввода-вывода.
Все множество
переменных, составляющих список ввода вывода, разбивается на четыре
функциональные группы Р – вводимые переменные для расчетов и для обеспечения
вывода.
Примером может
служить используемая в программах лексического анализатора переменная,
содержащая строку исходного текста программы, то есть сама переменная не
модифицируется, а только содержит исходную информацию. М – модифицируемые или
создаваемые внутри программы переменные. C – переменные, участвующие в управлении
работой программного модуля (управляющие переменные). Далее вводится значение
метрики Чепина:
Q = a1P + a2M +
a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.
Весовые
коэффициенты использованы для отражения различного влияния на сложность программы
каждой функциональной группы. По мнению автора метрики, наибольший вес, равный
трем, имеет функциональная группа С, так как она влияет на поток управления
программы. Весовые коэффициенты остальных групп распределяются следующим
образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю,
поскольку «паразитные» переменные не увеличивают сложности потока данных
программы, но иногда затрудняют ее понимание.
С учетом весовых
коэффициентов выражение примет вид
Q = P + 2M + 3C + 0.5T
Следует отметить,
что рассмотренные метрики сложности программы основаны на анализе исходных
текстов программ, что обеспечивает единый подход к автоматизации их расчета.
Контрольные
вопросы:
1. Какие метрики
оценки сложности программ существуют?
2. Какие
характеристики составляют метрику Холстеда?
3. Что такое
метрика сложности потока данных?
4. Как
рассчитывается метрика Чепина?
Задание:
1. На основании
выданного преподавателем задания написать программу на заданном языке
программирования. В ходе написания программы реализовать вывод всех входных и
выходных данных.
2. Используя
исходный текст программы, необходимо рассчитать 6 базовых метрик Холстеда.
Лабораторная
работа 7
Тема: Выполнение измерений
характеристик кода в среде Visual Studio.
Цель
лабораторной работы: получить навыки в получении метрик оценки
качества кода при выполнении работ в IDE Visual Studio.
Теоретическая
часть:
Процесс подготовки и проведения измерений включает следующие три
этапа:
— выбор рабочей нагрузки, представительной с точки зрения исследования
параметров выполнения программы на исследуемой системе;
— выбор (разработка) средств регистрации параметров потребления
ресурсов системы;
— выбор (разработка) алгоритмов расчетов характеристик программ по
результатам измерений.
Все эти этапы объединяются в единое целое в зависимости от
назначения проводимого эксперимента и его планирования.
Существует два основных способа регистрации измеряемых параметров
– трассирующий и выборочный.
При трассирующем способе измеряемые параметры фиксируются
в момент наступления какого-либо события, связанного с изменением управляющих
таблиц операционной системы.
Данный метод характеризуется меньшим количеством измерений
параметров и сильной зависимостью от конкретной рабочей нагрузки.
При выборочном способе измерения производятся в моменты времени,
обычно равноудаленные друг от друга.
Достоинства этого способа заключается в его простоте, т.к. не надо
регистрировать наступление событий.
Практическая часть:
1. Необходимо по заданию преподавателя создать приложение на языке
программирования C#.
2. Выбрав пункт меню Анализ, выбрать подпункт Вычислить
метрики кода для решения.
Альтернативным способом может быть вызов контекстного меню
нажатием правой клавиши мыши на названии решения в обозревателе решений и выбор
пункта Рассчитать метрики кода.
3. Дождавшись появления окна Результаты метрик кода,
провести анализ разработанного приложения на основе предоставленных метрик:
— индекс удобства поддержки;
— цикломатическая сложность программы;
— глубина наследования;
— взаимозависимость классов;
— количество строк кода.
Лабораторная
работа 8
Тема: Выполнение
измерений характеристик кода в среде.
Цель
лабораторной работы: получить навыки использования инструментального
средства IDE Eclipse для работы в системе контроля версий Subversion.
Теоретическая
часть:
Современные проекты не реализуются одним разработчиком,
следовательно, происходит работа в команде. Поэтому перед разработчиками встает
проблема совместного использования и владения программным кодом и другими файлами
проекта.
Если учитывать, что над проектом работает несколько человек, то
объединение внесенных изменений в одну общую версию может занять достаточно
много времени.
Для решения данной задачи целесообразно использовать системные
управления (контроля) версиями, а также для удобства разработки использовать
среды программирования в связке с системами контроля версий, в частности с
Subversion (SVN). Даже если над проектом работает один человек, то
использование такой связки оправдывает затраченное на изучение и
конфигурирование время.
При работе с проектами на Eclipse достаточно удобно использовать
дополнительно подключаемые модули, в частности модуль «Subversion». Для
добавления поддержки SVN в Eclipse нужно в меню выбрать «Help», затем «Install
New Software…» и далее в поле «Work with:» ввести адрес:
http://download.eclipse.org/releases/juno В итоге появится список с возможными
обновлениями. Для добавления поддержки SVN необходимо выбрать «Collaboration»,
и далее отметить «Subversion SVN Team Provider», «Subversion SVN Team Provider
Localization (Optional)» и «Subversion SVN Team Provider Sources».
После того, как были выбраны элементы, нажимаем «Next» и переходим
к просмотру элементов, которые необходимо установить. Убедимся, что
устанавливаются необходимые элементы и нажимаем «Next». Изучаем лицензионное
соглашение и подтверждаем согласие.
Далее происходит установка элементов, где в процессе установки,
возможно, потребуется подтверждение доверия к устанавливаемому элементу. После
окончания установки, мастер обновлений попросит перезагрузить Eclipse.
Практическая часть:
1. Необходимо по заданию преподавателя создать приложение на языке
программирования Java.
2. Для оценки метрик кода, написанного на языке программирования
Java, в IDE Eclipse потребуется
загрузка и установка плагина Eclipse Metrics.
Для этого необходимо:
— загрузить JAR-файл Eclipse Metrics;
— сохранить загруженный JAR-файл в каталоге плагинов Eclipse;
— перезапустить Eclipse.
3. Подключаемый модуль Eclipse Metrics можно настраивать (включить или отключить) для
каждого Java-проекта.
Чтобы подключить плагин, необходимо открыть пункт меню File и выбрать
подпункт Properties проекта, в открывшемся окне выбрать вкладку Metrics и установить
флажок Enable Metrics Gathering. Нажмите ОК для
повторной компиляции проекта и вычисления метрик. При выходе метрик за пределы
указанного диапазона в представлении Problems View генерируются и отображаются
предупреждения, а блок кода помечается.
4. Для установки предпочтений необходимо выбрать пункт меню Windows, выбрать
подпункт Preferences, а в нем
вкладку Metrics.
Лабораторная
работа 9
Тема: Анализ
программного кода на предмет ошибок.
Цель
лабораторной работы: получить навыки анализа программного кода на
предмет ошибок.
Теоретическая
часть:
