Сортування попереджень статичних аналізаторів за пріоритетом при пошуку і виправлення програмних помилок

За 2015 рік в Національній базі даних вразливостей США (National Vulnerability Database, NVD) було зареєстровано 6,488 нових програмних вразливостей, все ж у ній налічується 74,885 вразливостей, знайдених за період 1988-2016 рр.. Інструменти статичного аналізу перевіряють вихідний код програм на наявність дефектів, у тому числі потенційних вразливостей захисту, і видають діагностичні повідомлення (попередження), в яких вказується місце передбачуваного дефекту, його характер, і, як правило, додаткова контекстуальная інформація. Достовірність таких попереджень потім оцінюється користувачем. Трудовитрати на перевірку всіх попереджень та виправлення всіх підтверджених помилок вручну найчастіше значно перевершують бюджет і терміни проекту. З цієї причини користувачі потребують в інструментах, які дозволили б сортувати попередження за ступенем важливості, тим самим визначаючи порядок їх перевірки. Справжня стаття присвячена проведеним нами дослідженням даного питання з використанням класифікаційних моделей, покликаних допомогти фахівцям з аналізу і програмістам в класифікації попереджень за пріоритетністю визначенні оптимального порядку виправлення відповідних помилок.

Попередження статичних аналізаторів: проблеми і основне завдання
Інструменти статичного аналізу перевіряють додатка, не виконуючи їх, на відміну від інструментів динамічного аналізу. При статичному аналізі зазвичай перевіряються вихідні файли програми, хоча можлива перевірка і двійкових файлів. Результат роботи таких інструментів являє собою набір попереджень, які як мінімум містять інформацію про розташування дефекту у вихідному коді (наприклад, шлях до файлу і номер рядка), а також текстовий опис проблеми. Багато аналізатори також надають додаткову контекстуальну інформацію, наприклад, відомості про гілках виконання досліджуваного ділянки коду і значеннях змінних, які можуть привести до спрацьовування діагностики. У разі помилок, що зачіпають відразу кілька рядків коду, в деяких статичних аналізаторах у попередженні зазначаються початкова і кінцева рядка.

Деякі з попереджень можуть виявитися псевдопозитивними (помилковими спрацьовуваннями), які помилково видаються на коректний код і обумовлені неминучим для статичного аналізу компромісом між точністю і швидкістю перевірки. Зокрема, аналізатор може бути змушений видавати неточні результати, щоб укластися в розумні строки і прийнятне кількість обчислювальних ресурсів. Деякі статичні аналізатори, наприклад, інструменти автоматичного доведення теорем зразок Z3, орієнтовані на точність аналізу на шкоду продуктивності. Крім хибнопозитивних результатів статичні аналізатори також можуть демонструвати псевдонегативні (тобто коли попередження не видаються на помилковий код). У деяких випадках така поведінка пояснюється тим, що інструмент просто не вміє виявляти певні типи помилок.

Допустимі співвідношення між швидкістю і точністю аналізу були узгоджені в ході обговорень між розробниками статичних аналізаторів (як закритих, так і відкритих), за підсумками яких було визначено оптимальну кількість видаваних попереджень, яке дозволило б виявляти реальні помилки, не породжуючи при цьому занадто багато помилкових спрацьовувань. На тему того, як важко проходили ці обговорення, є примітна стаття Ела Бессі з Coverity: A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World .

Попереднє дослідження виявило зменшення збіги за типами дефектів, що виявляються найбільш популярними інструментами. З одного боку, це пояснюється тим, що розробка статичного аналізатора з нуля — це трудомістка задача, і виробники просто не можуть включити всі види аналізу відразу. З іншого боку, для діагностики деяких видів помилок вимагають великої кількості пам'яті, часу для аналізу або дискового простору. Такі діагностики не включаються в інструмент, якщо вони користуються малим попитом серед користувачів.

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

Згідно з емпіричними даними, отриманими Кременеком та ін аналізаторів, які здатні ефективно виявляти програмні помилки, помилкові спрацьовування становлять 30% і вище від загальної кількості видаваних ними попереджень. Наша задача, таким чином, полягає в тому, щоб добитися максимально можливої автоматизації процесу встановлення істинності/хибності попереджень. Ми також визначаємо ступінь достовірності у тих попереджень, які вимагають перевірки, для того, щоб полегшити процес сортування попереджень пріоритету.

Наш підхід
Дослідження інших авторів, присвячені проблемі об'єднання попереджень від різних інструментів та їх оцінки — [Meng 2008], [Kong 2007], [Kremenek 2004a] [Plakosh 2014], — спираються на статистичні методи, які не враховують складні потенційні кореляції між різними факторами (наприклад, беруть до уваги меншу кількість ознак класифікації та/або використовують більш прості математичні моделі) або не дають докладного опису для попереджень від декількох інструментів. В той же час є безліч робіт, які досліджують питання класифікації попереджень якого-небудь одного інструменту і використовують методи їх сортування за пріоритетом на основі тих же ознак, що враховуються, і в наших класифікаційних моделях. Приклади таких статей: [Heckman 2011], [Ruthruff 2008], [Kremenek 2004b] [Heckman 2007].

Авторам попередніх досліджень вдалося точно встановити ступінь достовірності попереджень окремих аналізаторів і на основі цього показника і ряду інших факторів класифікувати їх за пріоритетом. Так, автори дослідження Predicting Accurate and Actionable Static Analysis Warnings: An Experimental Approach розробили моделі, які правильно визначили помилкові спрацьовування серед попереджень статичного аналізатора FindBugs більш ніж у 85% випадків. Попередження, що підлягають оцінці, сортувалися по пріоритету на підставі динамічно оновлюваних даних про те, виправлялися чи підтверджені помилки того або іншого типу в минулому. У попередніх дослідженнях при вирішенні проблеми диференціації між помилковими і реальними помилками використовувалися такі методи, як збір контекстуальної інформації про код, вибір типів попереджень, злиття даних, машинне навчання, а також математичні та статистичні моделі. Всі ці методи та механізми використовуються і в нашому дослідженні. Крім того, ми застосовуємо технологію динамічного виявлення дефектів, теорію графів і механізм верифікації моделей. Спираючись на роботу інших дослідників, ми об'єднали безліч ознак класифікації, відповідних параметрам попереджень і самого коду.

Наш підхід також враховує досвід дослідження, проведеного Інститутом програмної інженерії Карнегі-Меллон (Software Engineering Institute, SEI), Improving the Automated Detection and Analysis of Secure Coding Violations [Plakosh 2014], підсумком якого стала розробка трьох бінарних логістичних регресійних моделей для класифікації попереджень (за основу були взяті попередження, для яких є відповідники в базі Стандартів безпечного програмування SEI CERT — ці моделі враховують, в яких аналізаторах спрацьовувала та чи інша діагностика. Іншими словами, для трьох правил з Стандартів безпечного програмування SEI CERT автори дослідження розробили класифікатори, які потім були «навчені» на наборі вже перевірених попереджень від декількох інструментів. Далі ці класифікатори були протестовані на іншому наборі попереджень, при цьому кожен класифікатор повинен був оцінити їх як істинні або хибні, після чого точність прогнозів порівнювалася з реальними даними ручної оцінки. У цій роботі вперше були запропоновані просунуті методи статистичного аналізу набору попереджень від різних статичних аналізаторів, що дозволяють максимально точно передбачити істинність/хибність того чи іншого попередження.

У нашому дослідженні ми доповнюємо роботу SEI за рахунок впровадження механізму оцінки додаткових класифікаційних методів і використання набагато більшого числа ознак класифікації. Крім того, аналізований нами набір даних відрізняється ббільшій обсягом і різнорідністю. Ми розробили класифікатори для правил, а також початковий класифікатор, який використовує формат ідентифікатора правил SEI CERT (він включає в себе 3-літерний префікс, що позначає тип правила, номер, дефіс і назва мови програмування, наприклад: «INT33-C») у якості ще однієї ознаки класифікації. Ми продовжуємо вдосконалювати наші класифікаційні моделі, пробуючи різні параметри класифікаторів, додаючи нові дані набори попереджень, на яких «навчаються» і тестуються моделі, а також експериментуючи з наборами вхідних даних при розробці класифікаторів. Як тільки класифікатор готовий, ми застосовуємо його до відповідним попередженням в тестовому наборі для того, щоб оцінити точність передбачення наших моделей. Новизна нашого підходу полягає в тому, що ми використовуємо кілька аналізаторів, враховуємо більше ознак і застосовуємо ряд просунутих методів класифікації, з яких відбираються найбільш продуктивні.

На команду дослідників з SEI, яка допомагає мені в роботі над цим проектом, входять Девід Свобода, Уїлл Снейвлі, Роберт Стодард, Девід Зуброу, Дженніфер Бернс, Гільєрмо Марсі-Сантурьо, Елі Канал, Крістін Бек і Річард Чин. Наша команда співпрацює зі старшим викладачем Школи інформатики Університету Карнегі — Меллон (CMU's School of Computer Science ), Клер Ле Гу, яка виступає в ролі консультанта. Її досвід надзвичайно корисний для нашого проекту, оскільки вона займається дослідженнями в області програмної інженерії та мов програмування, а саме спеціалізується на проблемах розробки, налагодження і забезпечення якості програмних систем. Наше дослідження також відповідає завданням, поставленим Міністерством оборони у зв'язку з потребою в технології оперативного, супроводжуваного та автоматизованого аналізу та верифікації програм. Крім того, наше дослідження відповідає одній з двох завдань стратегічного плану SEI: забезпечення безпеки програмно-залежних систем протягом всього їх життєвого циклу.

Наш підхід дозволить фахівцям з аналізу і програмістам сортувати попередження за ступенем важливості за рахунок автоматизації таких процесів:
  • Визначення ступеня достовірності попередження (тобто ймовірності, що те чи інше попередження є істинним або хибним).
  • Розподіл попереджень за трьома категоріями: передбачувані справжні попередження (e-TP), передбачувані помилкові спрацьовування (e-FP) і проміжні (I). При цьому попередження першої групи (e-TP) після виявлення відразу направляються отладчикам, минаючи ручну перевірку.
  • Сортування проміжних попереджень на підставі їх ступеня достовірності. При цьому також можуть враховуватися додаткові фактори, що мають відношення до даного попередження, наприклад, ризики і витрати, пов'язані з його обробкою.
При розробці класифікатора для деякого правила з Стандартів безпечного програмування SEI CERT ми використовуємо архівні дані по всім перевіреним попередженням, що належать до цього правила, а також нові дані, зібрані в рамках цього проекту. Аналогічно враховуються архівні та нові дані при створенні класифікатора для всього набору попереджень.

Спираючись на досвід згаданих вище досліджень (як всередині SEI, так і за його межами), ми виділили наступні ознаки класифікації для включення в наші моделі (неповний список):
  • глибина попередження (глибина передбачуваного знаходження дефекту в файлі)
  • кількість значущих рядків коду (SLOC) у функції/методі, файл, програму
  • загальна кількість рядків коду (LOC) у функції/методі, файл, програму
  • цикломатическая складність
  • зв'язність (модулів програми)
  • зчеплення ("«елементів модуля)
  • мова
  • збігаються попередження (однакові рядки коду, файл і правило), видані усіма аналізаторами
  • частота змін коду
  • число попереджень (на файл, функцію і т. д.)
  • кількість квитків у функції/методі
  • число функцій/методів у файлі
  • число параметрів у функції/методі
  • середня кількість токенів
  • середня кількість SLOC
  • частково збігаються шляхи до файлів
  • ім'я класу (де застосовно)
  • назва методу/функції
  • назва пакету (де застосовно)
  • безліч інших показників, специфічних для конкретного інструменту, які можуть варіювати для різних попереджень
Обробка архівних даних з перевіреним попереджень та відповідних ознак з наведеного списку відбувається із застосуванням чотирьох методів класифікації:Один з наборів даних, які використовуються в нашому дослідженні, включає в себе результати оцінки попереджень 20 баз вихідного коду загальним обсягом 19,237 KLOC (тисяч рядків коду)і містить 3,147 підтверджених реальних попереджень та 11,772 підтверджених помилкові спрацьовування.

Для перевірки цих баз використовувався інструмент Source Code Analysis Laboratory (SCALe) CERT -програмна платформа, що об'єднує в собі засоби аналізу цілої низки комерційних, відкритих і експериментальних інструментів. Завдяки тому, що SCALe користується можливостями декількох статичних аналізаторів, що він виявляє більше дефектів, ніж будь-який окремо взятий інструмент. Однак такий підхід передбачає великий обсяг вихідних даних і, відповідно, вимагає великих трудовитрат для їх обробки. Всього з допомогою SCALe було проаналізовано понад 16 мільйонів рядків коду, включаючи бази вихідних кодів Міністерства оборони, систем енергопостачання, медичного обладнання тощо

За допомогою графічного інтерфейсу SCALe користувач завантажує в інструмент набір звітів статичних аналізаторів і відповідні вихідні файли. Попередження зберігаються в єдиному форматі в окрему базу даних SCALe. Кожне попередження супроводжується додатковою інформацією, наприклад, відомості про відповідний йому правилі з набору Стандартів безпечного програмування CERT. SCALe також зберігає асоціацію між цими правилами та попередженнями від кожного з підключених аналізаторів, так що одному і тому ж правилу CERT може відповідати кілька попереджень від різних інструментів. Ці асоціації між попередженнями і правилами представляють особливу важливість для нашої задачі за класифікацією попереджень на рівні окремих правил.

Додаток також можна використовувати для вивчення попереджень. Інтерфейс на основі веб-браузера дозволяє фільтрувати попередження і сортувати їх по пріоритету, переглядати відповідний ділянку вихідного коду і позначати попередження як істинні або хибні. База даних динамічно оновлюється при внесенні змін.

Ми вдосконалили SCALe для нашого проекту, так що тепер він може збирати додаткову інформацію по кожному попередженню і виконувати ряд допоміжних задач, наприклад, забезпечувати анонімність даних. Додаткова інформація витягується з декількох джерел. Метрики вихідного коду (такі як цикломатическая складність і кількість значущих рядків коду) обчислюються за допомогою модифікованої версії інструменту Lizard. Поля для додаткових параметрів витягуються з звітів аналізаторів.

Крім того, ми розробили скрипт, який об'єднує і аналізує попередження, готуючи дані до обробки додатками статистичного аналізу. Цей скрипт конвертує многотабличную базу даних модифікованої версії SCALe в лінійний файл .csv, в якому записи розділені комою — такий формат зручний для інструментів, здійснюють класифікацію. Наш скрипт також об'єднує попередження, що збігаються за параметрами [правило, номер рядка, файл]. Нарешті, скрипт проводить додатковий аналіз і додає до записів такі дані як число попереджень на файл, число попереджень на функцію і глибину вкладеності файлу в проекті, а також розбиває шляхи до файлів таким чином, щоб частково збігаються шляхи могли використовуватися в якості ознак класифікації.

Наш метод розробки класифікаторів може бути легко розширений для роботи з іншими стандартами і платформами, здатними зберігати дані перевірок. Наприклад, правила програмування CERT можуть бути замінені іншими схожими стандартами, а інструмент SCALe — іншими платформами. Зберігаються в SCALe асоціації попереджень з правилами можуть бути замінені на асоціації з іншими правилами і нумерованими списками помилок, наприклад, Єдиний каталог програмних вразливостей (Common Weakness Enumeration , Стандарт підтвердження безпеки додатків OWASP (OWASP Application Security Verification Standard Project ) і Стандарт розробки програмного забезпечення на мові C MISRA. Аналогічно дані оцінки попереджень з інших платформ, які працюють з кількома аналізаторами, можуть бути конвертовані в інші формати, підтримувані нашими класифікаторами та інструментами їх розробки.

Випробування нашого підходу з партнерами з Міністерства оборони
Крім 20 кодових баз, перевірених CERT, ми використовуємо дані трьох підрозділів Міністерства оборони (про цьому виді співпраці ми поговоримо в окремій статті), два з яких заявили про необхідність перевірки захищеності їх коду обсягом понад 100 MSLOC (мільйонів значущих рядків коду). Екстраполюючи результати, зібрані на архівних даних попередніх перевірок CERT (при коефіцієнті 3.31 попередження на 1000 рядків коду), ми очікуємо, що для кодових баз обох підрозділів вдасться ідентифікувати приблизно 662,000 попереджень. Наше завдання полягає в тому, щоб автоматично встановити істинність/хибність помічених дефектів з точністю 95%. У разі успіху наш метод (і створені на його основі аналізатори) допоможе значно знизити трудовитрати за оцінкою результатів аналізу і сортування знайдених дефектів по пріоритету.

При використанні нашої системи автоматичної класифікації фахівці у зазначених підрозділах могли б обробляти попередження за наступною схемою:
  • e-TP (передбачувані справжні помилки) направляються безпосередньо команді отладчиков.
  • I (проміжні попередження) направляються для оцінки команді аналітиків.
  • e-FP (передбачувані помилкові спрацьовування) ігноруються.
Подальша екстраполяція архівних даних CERT дає співвідношення істинних/помилкових попереджень 1:3.74. Таким чином, з урахуванням нашої амбітної задачі по обробці 90% попереджень та коректному розподіл їх за групами e-TP e-FP, очікуються такі результати для 200 MSLOC: 126,000 e-TP, які будуть відразу спрямовані команді отладчиков, 470,000 e-FP, які будуть проігноровані, і 66,000 I, які будуть оцінені вручну. Ці цифри припускають скорочення часу на ручне оцінку попереджень на 90%, при цьому будуть враховуватися всі попередження, тому що рівень захищеності коду не буде знижуватися (іншими словами, 90% автоматично ідентифікованих e-TP або e-FP-попереджень відповідають скорочення часу на їх оцінку вручну на 90%). Ступінь достовірності проміжних попереджень допоможе визначити порядок їх перевірки. На практиці ті з них, які мають найменший пріоритет, можуть зовсім ігноруватися.

На малюнку нижче показано, як наш метод допоможе вдосконалити процес перевірки додатків. Кодові бази перевіряються кількома статичними аналізаторами, і кожен з них видає свій набір попереджень. Стрілки під написом „Today“ (»сегодня"), ведучі від блоку «Alerts» («попередження») до діаграми з червоною рамкою, вказують на звичну стратегію обробки сигналів, при якій кожне з попереджень і відповідний йому код повинні перевірятися вручну для встановлення його істинності чи хибності. Цей процес, як правило, забирає надто багато часу, враховуючи обмежений бюджет проектів. Жовтим кружечком на даній діаграмі показано кількість попереджень, які можна оцінити за 12,939 годин роботи (виходячи з того, що на кожне попередження зазвичай йде 5 хвилин, згідно з результатами дослідження [Hayward, 2008]), а червоним еліпсом — залишилися 506,733 неперевірених попередження. З іншого боку, наша стратегія показана верхнім рядом стрілок: 90% попереджень будуть автоматично і коректно розподілені по групах e-TP або e-FP, в результаті чого користувачеві залишиться перевірити лише 66,000 проміжних попереджень. На це піде всього лише 5,500 годин, що становить менше половини часу для першого сценарію. Більш того, наш метод гарантує, що всі попередження, що вимагають ручної перевірки, обов'язково її пройдуть.



Рис. 1: Завдання нашого дослідження полягає в тому, щоб значно скоротити час на ручну оцінку неперевірених попереджень та їх кількість. Зображення жінки і ноутбука («Woman And Laptop») узято із наступного джерела: www.publicdomainpictures.net/view-image.php?image=47526&picture=woman-and-laptop.

Подальша робота
У нещодавно опублікованому дослідженні Automatically Learning Semantic Features for Defect Prediction було показано, що аналіз семантичних ознак програм може значно поліпшити точність виявлення програмних дефектів. У зв'язку з цим ми плануємо згодом додати такий аналіз в наші класифікаційні моделі. Більше того, ми розраховуємо застосовувати семантичні ознаки з зберігаються в репозиторії звітів при розробці класифікаторів. Ми також збираємося використовувати механізм автоматичної оптимізації параметрів класифікаційних методів, що, згідно з результатами недавнього дослідження Automated Parameter Optimization of Classification Techniques for Defect Prediction Models , допоможе значно поліпшити наші класифікатори.

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

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

Можливо також, що в майбутньому результати нашого дослідження будуть об'єднані з рішеннями в області автоматичного виправлення коду, робота над якими в даний час ведеться у SEI. В цьому випадку наші моделі будуть застосовуватися після автоматичного рефакторінгу коду, який допоможе усунути лише незначна кількість попереджень про потенційні помилки. Наш метод може бути використаний для сортування по пріоритету (при експертному аналізі) потенційних напівавтоматичних виправлень, коректність яких не гарантована і які вимагають ручної оцінки (наприклад, фахівець повинен визначити, чи буде деякий автоматичне виправлення коректним з урахуванням бажаного поведінки коду). Всі інші попередження, для яких немає автоматичних виправлень, можуть бути класифіковані звичайним способом за допомогою нашого методу, як описано вище (тобто з розподілом за категоріями e-TP, e-FP I).

У наступній статті цієї серії ми розповімо про співпрацю нашої команди з трьома підрозділами Міністерства оборони, згаданими вище.

Ми будемо раді вашим відгукам про даній роботі — залишайте їх в розділі коментарів під текстом.

Додаткові ресурси
Читайте і коментуйте наші статті і допомагайте нам удосконалювати Стандарти програмування SEI CERT, розробка яких ведеться на основі загальнодоступних вікі-сайтів.

Також ми запрошуємо вас відвідати сайт Лабораторії аналізу вихідного коду CERT.

Далі наводяться джерела цитат у цій статті:

[Heckman 2011] Heckman, Sarah, and Laurie Williams. A systematic literature review of actionable alert identification techniques for automated static code analysis. Information and Software Technology 53.4 (2011): 363-387.

[Heckman 2007] Heckman, Sarah. Adaptively ranking alerts generated from automated static analysis, Crossroads 14.1, 2007.

[Kong 2007] Kong, Deguang, et al. ISA: a source code static vulnerability detection system based on data fusion. Proceedings of the 2nd international conference on Scalable information systems. ICST, 2007.

[Kremenek 2004] Kremenek, Ted, et al. Correlation exploitation in error ranking. ACM SIGSOFT Software Engineering Notes. Тому 29. N6. ACM, 2004.

[Meng 2008] N. Meng, Q. Wang, Q. Wu, H. Mei, An approach to merge results of multiple static analysis tools, Proceedings of the Eight International Conference on Quality Software, Oxford, UK, August 12-13, 2008.

[Plakosh, 2014] Plakosh, Daniel, Robert Seacord, Robert W. Stoddard, David Svoboda, and David Zubrow. Improving the Automated Detection and Analysis of Secure Coding Violations. (2014).

[Ruthruff 2008] Ruthruff, Joseph R., et al. Predicting accurate and actionable static analysis warnings: an experimental approach. Proceedings of the 30th international conference on Software engineering. ACM, 2008.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.