Статическое тестирование безопасности приложений - Static application security testing

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

В отличие от динамическое тестирование безопасности приложений (DAST) инструменты для черный ящик функциональности приложения, инструменты SAST ориентированы на содержимое кода приложения, тестирование методом белого ящика Инструмент SAST сканирует исходный код приложений и его компонентов для выявления потенциальных уязвимостей безопасности в их программном обеспечении и архитектуре. Инструменты статического анализа могут обнаруживать около 50% существующих уязвимостей безопасности.[1].

В SDLC, SAST выполняется на ранних этапах процесса разработки и на уровне кода, а также тогда, когда все фрагменты кода и компоненты объединены в согласованную среду тестирования. SAST также используется для обеспечения качества программного обеспечения.[2] даже если многие в результате ложный положительный результат препятствуют его принятию разработчиками[3]

Инструменты SAST интегрированы в процесс разработки, чтобы помочь командам разработчиков, поскольку они в основном сосредоточены на разработке и поставке программного обеспечения в соответствии с запрошенными спецификациями.[4]. Инструменты SAST, как и другие инструменты безопасности, ориентированы на снижение риска простоя приложений или на то, чтобы конфиденциальная информация, хранящаяся в приложениях, не была скомпрометирована.

База данных Информационного центра прав конфиденциальности на 2018 год.[5] показывает, что более 612 миллионов записей были взломаны.

Обзор

Тесты безопасности приложений их выпуска: статическое тестирование безопасности приложений (SAST), динамическое тестирование безопасности приложений (DAST) и интерактивное тестирование безопасности приложений (IAST), сочетание этих двух.[6].

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

Точность инструмента SAST определяется объемом анализа и конкретными методами, используемыми для выявления уязвимостей. Различные уровни анализа включают:

Объем анализа определяет его точность и способность обнаруживать уязвимости с использованием контекстной информации.[8]

На функциональном уровне распространенной техникой является построение Абстрактное синтаксическое дерево для управления потоком данных внутри функции.[9]

С конца 90-х необходимость адаптироваться к бизнес-задачам преобразовала разработку программного обеспечения с помощью компонентности.[10] обеспечивается процессами и организацией групп разработчиков[11]Отслеживание потока данных между всеми компонентами приложения или группы приложений позволяет проверять требуемые вызовы выделенных процедур для дезинфекция и что предпринимаются правильные действия для искажения данных в определенных частях кода.[12][13]

Рост числа веб-приложений повлек за собой их тестирование: Verizon Data Breach сообщает в 2016 году, что 40% всех утечек данных связаны с уязвимостями веб-приложений.[14] Помимо внешних проверок безопасности, все больше внимания уделяется внутренним угрозам. По данным индекса Clearswift Insider Threat Index (CITI), 92% их респондентов в опросе 2015 года заявили, что они сталкивались с инцидентами в сфере ИТ или безопасности за предыдущие 12 месяцев, и что 74% этих нарушений были инициированы инсайдерами.[15] Ли Хэдлингтон разделил внутренние угрозы на 3 категории: вредоносные, случайные и непреднамеренные. Стремительный рост мобильных приложений предполагает обеспечение безопасности приложений на более ранних этапах процесса разработки, чтобы уменьшить количество вредоносного кода.[16]

Сильные стороны SAST

Чем раньше уязвимость будет исправлена ​​в SDLC, тем дешевле будет ее исправить. Затраты на исправление при разработке в 10 раз ниже, чем при тестировании, и в 100 раз ниже, чем при производстве.[17]Инструменты SAST запускаются автоматически на уровне кода или приложения и не требуют взаимодействия. При интеграции в контекст CI / CD инструменты SAST могут использоваться для автоматической остановки процесса интеграции при выявлении критических уязвимостей.[18]

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

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

Слабые стороны SAST

Несмотря на то, что разработчики положительно относятся к использованию инструментов SAST, существуют различные проблемы, связанные с внедрением инструментов SAST разработчиками.[4]

При использовании гибких процессов в разработке программного обеспечения ранняя интеграция SAST порождает множество ошибок, поскольку разработчики, использующие эту структуру, в первую очередь сосредотачиваются на функциях и доставке.[20]

Сканирование множества строк кода с помощью инструментов SAST может привести к появлению сотен или тысяч предупреждений об уязвимостях для одного приложения. Он генерирует множество ложных срабатываний, увеличивая время расследования и снижая доверие к таким инструментам. Это особенно актуально, когда инструмент не может определить контекст уязвимости.[21]

Рекомендации

  1. ^ Окунь, В .; Guthrie, W. F .; Gaucher, H .; Блэк, П. Э. (октябрь 2007 г.). «Влияние средств статического анализа на безопасность программного обеспечения: предварительное расследование» (PDF). Материалы семинара ACM 2007 года по качеству защиты. ACM: 1–5. Дои:10.1145/1314257.1314260. S2CID  6663970.
  2. ^ Ayewah, N .; Hovemeyer, D .; Morgenthaler, J.D .; Penix, J .; Пью, В. (сентябрь 2008 г.). «Использование статического анализа для поиска ошибок». Программное обеспечение IEEE. IEEE. 25 (5): 22–29. Дои:10.1109 / MS.2008.130. S2CID  20646690.
  3. ^ Джонсон, Бретань; Сон, Юки; Мерфи-Хилл, Эмерсон; Боудидж, Роберт (май 2013 г.). «Почему бы разработчикам программного обеспечения не использовать инструменты статического анализа для поиска ошибок». ICSE '13 Материалы Международной конференции по программной инженерии 2013 г.: 672–681. ISBN  978-1-4673-3076-3.
  4. ^ а б Оетоян, Тосин Даниэль; Милошская, Бисера; Грини, Мари (май 2018 г.). «Мифы и факты об инструментах тестирования безопасности статических приложений: исследование Telenor Digital». Международная конференция по гибкой разработке программного обеспечения. Springer: 86–103.
  5. ^ «Нарушения данных | Центр обмена информацией по правам человека». privacyrights.org.
  6. ^ а б Parizi, R.M .; Qian, K .; Shahriar, H .; Wu, F .; Тао, Л. (июль 2018 г.). «Контрольные требования для оценки инструментов тестирования уязвимости программного обеспечения». 42-я ежегодная конференция по компьютерному программному обеспечению и приложениям IEEE (COMPSAC). IEEE: 825–826. Дои:10.1109 / COMPSAC.2018.00139. ISBN  978-1-5386-2666-5. S2CID  52055661.
  7. ^ Шахматы, B .; МакГроу, Г. (декабрь 2004 г.). «Статический анализ для безопасности». Безопасность и конфиденциальность IEEE. IEEE. 2 (6): 76–79. Дои:10.1109 / MSP.2004.111.
  8. ^ Шахматы, B .; МакГроу, Г. (октябрь 2004 г.). «Анализ рисков в разработке программного обеспечения». Безопасность и конфиденциальность IEEE. IEEE. 2 (4): 76–84. Дои:10.1109 / MSP.2004.55.
  9. ^ Ямагути, Фабиан; Лоттманн, Маркус; Рик, Конрад (декабрь 2012 г.). «Обобщенная экстраполяция уязвимостей с использованием абстрактных синтаксических деревьев». Материалы 28-й ежегодной конференции по приложениям компьютерной безопасности. IEEE. 2 (4): 359–368. Дои:10.1145/2420950.2421003. S2CID  8970125.
  10. ^ Буч, Гради; Козачинский, Войтек (сентябрь 1998 г.). «Компонентная разработка программного обеспечения». Симпозиум IEEE 2006 г. по безопасности и конфиденциальности (S & P'06). Программное обеспечение IEEE. 15 (5): 34–36. Дои:10.1109 / MS.1998.714621. S2CID  33646593.
  11. ^ Мезо, Питер; Джайн, Радхика (декабрь 2006 г.). «Гибкая разработка программного обеспечения: принципы и передовой опыт адаптивных систем». Симпозиум IEEE 2006 г. по безопасности и конфиденциальности (S & P'06). Управление информационными системами. 23 (3): 19–30. Дои:10.1201/1078.10580530/46108.23.3.20060601/93704.3. S2CID  5087532.
  12. ^ Лившиц, В.Б .; Лам, М. (Май 2006 г.). «Поиск уязвимостей безопасности в приложениях Java с помощью статического анализа». Симпозиум по безопасности USENIX. 14: 18.
  13. ^ Йованович, Н .; Kruegel, C .; Кирда, Э. (май 2006 г.). «Pixy: инструмент статического анализа для обнаружения уязвимостей веб-приложений». Симпозиум IEEE 2006 г. по безопасности и конфиденциальности (S & P'06). IEEE: 359–368. Дои:10.1109 / SP.2006.29. ISBN  0-7695-2574-1. S2CID  1042585.
  14. ^ «Отчет о расследовании утечки данных за 2016 год» (PDF). 2016.
  15. ^ «Индекс внутренних угроз Clearswift (CITI)» (PDF). 2015.
  16. ^ Сяньюн, Мэн; Цянь, Кай; Ло, Дэн; Бхаттачарья, Прабир; У Фань (июнь 2018). «Безопасная разработка мобильного программного обеспечения с помощью детекторов уязвимостей в статическом анализе кода». 2018 Международный симпозиум по сетям, компьютерам и коммуникациям (ISNCC): 1–4. Дои:10.1109 / ISNCC.2018.8531071. ISBN  978-1-5386-3779-1. S2CID  53288239.
  17. ^ Хосейн, Шахадат (октябрь 2018 г.). «Эффекты доработки и повторного использования в экономике программного обеспечения». Глобальный журнал компьютерных наук и технологий.
  18. ^ Окунь, В .; Guthrie, W. F .; Gaucher, H .; Блэк, П. Э. (октябрь 2007 г.). «Влияние средств статического анализа на безопасность программного обеспечения: предварительное расследование» (PDF). Материалы семинара ACM 2007 года по качеству защиты. ACM: 1–5. Дои:10.1145/1314257.1314260. S2CID  6663970.
  19. ^ Сиаввас, М .; Tsoukalas, D .; Янкович, М .; Kehagias, D .; Chatzigeorgiou, A .; Tzovaras, D .; Aničić, N .; Геленбе, Э. (август 2019). «Эмпирическая оценка взаимосвязи между техническим долгом и безопасностью программного обеспечения». 9-я Международная конференция по информационному обществу и технологиям. Дои:10.5281 / zenodo.3374712. | chapter = игнорируется (помощь)
  20. ^ Арреаза, Густаво Хосе Ньевес (июнь 2019 г.). «Методология разработки безопасных приложений в облаках (MDSAC) для конференций IEEECS». 2019 6-я Международная конференция IEEE по кибербезопасности и облачным вычислениям (CSCloud) / 2019 5-я Международная конференция IEEE по пограничным вычислениям и масштабируемым облакам (EdgeCom). IEEE: 102–106. Дои:10.1109 / CSCloud / EdgeCom.2019.00-11. ISBN  978-1-7281-1661-7.
  21. ^ Джонсон, Бретань; Сон, Юки; Мерфи-Хилл, Эмерсон; Боудидж, Роберт (май 2013 г.). «Почему бы разработчикам программного обеспечения не использовать инструменты статического анализа для поиска ошибок». ICSE '13 Материалы Международной конференции по программной инженерии 2013 г.: 672–681. ISBN  978-1-4673-3076-3.