Статическое тестирование безопасности приложений (SAST) – это эффективная и хорошо зарекомендовавшая себя технология проверки безопасности программного обеспечения. Она позволяет разработчикам создавать качественный и защищенный софт, устойчивый к тем видам атак, которые стали особенно распространенными в последние годы.
Однако главная проблема SAST заключается в том, что этот метод склонен выдавать большое количество ложноположительных срабатываний, которые впустую тратят время инженерной команды. В этой статье рассматривается SAST и проблема ложноположительных срабатываний, а также способы их предотвращения и то, чем здесь может помочь Mend SAST.
Что такое SAST?
SAST – это методология тестирования приложений, которая оценивает исходный код для обнаружения потенциальных недостатков в архитектуре, используя статический анализ программ для поиска уязвимостей. В SAST приложение сканируется без необходимости выполнения его кода. Его также называют white box тестированием. SAST работает рука об руку с другими практиками безопасного кодирования, такими как анализ исходного кода и инструменты его проверки, обеспечивая разработчикам несколько уровней защиты при обнаружении уязвимостей.
SAST является одним из нескольких подходов, используемых в тестировании безопасности приложений (AST). Другими основными подходами являются динамическое тестирование безопасности (DAST), интерактивное тестирование безопасности (IAST) и анализ состава программного обеспечения (SCA).
В идеале SAST проводится на ранних стадиях жизненного цикла разработки программного обеспечения (SDLC). Смещая безопасность влево (принцип «shift left»), разработчики получают возможность быстро исправлять проблемы, не ломая сборки и не пропуская дефекты на более поздние стадии разработки, где устранение ошибок стоит значительно дороже.
Одним из преимуществ SAST по сравнению с DAST или IAST является то, что SAST обнаруживает недостатки в 100% кодовой базы. Например, использование ненадежного шифрования – это то, что инструмент DAST или IAST обнаружить не сможет, но это легко заметит инструмент SAST.
Проблема ложноположительных срабатываний SAST
Несмотря на множество преимуществ, инструменты SAST нажили не самую лучшую славу из-за генерации огромного количества предупреждений о ложноположительных срабатываниях – потенциальных дефектах кода, которых на самом деле не существует, если проверить их более детально. Чтобы продемонстрировать это, вот два типичных примера проблем, возникающих при таких обстоятельствах.
Во-первых, специфические для конкретного проекта операции по очистке данных.
Это меры, которые принимаются с целью защиты от уязвимости. Вот пример таких операций для защиты от SQL-инъекций:
final var allowedColumns = List.of(“col1”, “col2”, “col3”);
if(allowedColumns.contains(userInput)){
stmt.executeQuery(“SELECT ” + userInput + ” FROM table”)
}В этом примере userInput – это строка, поступающая извне: так называемые «недоверенные» данные. Эти данные легко могут контролироваться злоумышленником и стать причиной SQL-инъекции.
Когда недоверенные данные попадают в участок кода, где их использование может нанести вред, это место считают опасной точкой обработки таких данных (англ. taint sink). В приведенном выше фрагменте кода метод executeQuery является опасной точкой обработки данных для SQL-инъекции. Если не предпринять дополнительные меры защиты, киберпреступники могут атаковать базу данных, добавив вредоносную строку через userInput, и использовать её для совершения злоумышленных действий, таких как удаление всех пользователей, получение прав администратора и т. д.
В целом инструменты SAST проверяют, существует ли путь к недоверенной точке обработки данных (taint flow), и если он есть, то фиксируют уязвимость. Понимание этой механики также помогает при сравнении SAST и SCA, поскольку SAST анализирует непосредственно кастомный код, тогда как SCA фокусируется на сторонних и open-source компонентах.
Однако, если в этом потоке предприняты определенные меры, благодаря которым до недоверенной точки обработки могут дойти только безопасные значения, то уязвимости нет. Эти меры называются операциями по очистке данных, так как после них в недоверенную точку обработки попадает только ввод, безопасный для такого использования. Таким образом, злоумышленник никак не сможет вызвать executeQuery со вредоносной строкой.
Обычно операцией по очистке данных может выступать либо какая-то стандартная функция библиотеки (которую инструмент распознает автоматически, если вендор знает об этой библиотеке и заранее прописал соответствующее правило), либо что-то «домашнее», специфическое для проекта. В данном случае allowedColumns.contains(userInput) и является такой специализированной операцией. Она проверяет, входит ли userInput в число разрешенных строк.
В целом, лучший способ предотвратить SQL-инъекцию – использовать параметризованные запросы. Здесь они не используются, поэтому инструменты статического анализа сообщат об уязвимости. Но на самом деле это ложноположительное срабатывание, поскольку в данном случае применяется специфическая для проекта операция по очистке данных через вайтлистинг ввода (проверку того, что передана только одна из ожидаемых строк). Об этом ни один инструмент статического анализа не может знать заранее.
Второй пример – это контекстно-зависимая уязвимость.
Решение безопасности просто не может предсказать, является ли программа достаточно чувствительной, чтобы требовать аутентификации и авторизации. Поэтому многие инструменты сообщают о любом типе неаутентифицированного доступа, создавая ложноположительные оповещения для абсолютно безобидного софта. Например, неаутентифицированный доступ к сервису, который просто показывает текущее время, вряд ли является реальной уязвимостью.
Последствия ложноположительных срабатываний SAST
Чтобы разобраться, что такое ложноположительное срабатывание, важно понимать весь спектр результатов тестирования, которые может выдать SAST-инструмент:
- Истинно отрицательный (True Negative) – правильно показывает, что уязвимости нет.
- Истинно положительный (True Positive) – правильно показывает, что уязвимость есть.
- Ложноотрицательный (False Negative) – не показывает уязвимость, хотя на самом деле она существует.
- Ложноположительный (False Positive) – ошибочно показывает, что уязвимость есть, хотя на самом деле её нет.
Целью любого инструмента AST должна быть максимизация истинно отрицательных и истинно положительных результатов при минимизации ложноотрицательных и ложноположительных. Однако с инженерной точки зрения этого трудно достичь. На практике большинство продуктов SAST были разработаны так, чтобы максимизировать количество истинно положительных результатов, даже ценой создания большого количества ложноположительных срабатываний. Это приводит к колоссальным потерям времени, поскольку разработчики вынуждены искать баги, которых на самом деле нет, что порождает следующие проблемы.
Основные причины ложноположительных срабатываний
Существуют две главные причины ошибочных оповещений во время SAST-тестов:
#1 Чрезмерные предположения в сканерах
Некоторые инструменты SAST заложили в свой алгоритм слишком много предположений, чтобы обеспечить поддержку многих языков программирования. В большинстве случаев эти предположения являются общими и не могут корректно применяться ко всем языкам. Если какой-то кусок кода непонятен такому инструменту или отсутствует зависимость, он просто предполагает, что в коде есть проблема. Как результат – куча ложноположительных оповещений.
#2 Плохо спроектированные правила
Некоторые традиционные инструменты SAST разработаны неэффективно и не могут с уверенностью подтвердить уязвимость. Чтобы компенсировать это, они маркируют код как уязвимый при малейшем намеке на проблему – просто на всякий случай.
Например, они ищут определенные слова в названиях строковых переменных, чтобы определить, содержат ли они чувствительные данные (учетные данные аутентификации, пароли, ключи и т. д.).
Пример такого кода:
userPasswordLabel.Text = “Please enter your password”;Хотя название переменной содержит слово «password», это вовсе не означает, что она хранит секретные данные. Это просто текстовая метка. Если инструмент SAST не может провести более глубокий анализ, чтобы определить, раскрывает ли переменная чувствительную информацию, он мгновенно создаст ложноположительное оповещение.
Как избегать ложноположительных срабатываний SAST
Вот несколько способов укротить ложноположительные срабатывания и не дать им сломать стратегию раннего тестирования безопасности организации:
#1 Выбрать качественный инструмент
Стоит выбрать решение, которое заточено под конкретные задачи. Если взять первый попавшийся инструмент без оценки его эффективности, можно провести кучу времени за разбором ложноположительных оповещений вместо устранения реальных угроз.
Нужен инструмент, который делает глубокий, точный и комплексный анализ на нужном языке программирования и покрывает широкий спектр уязвимостей. Универсальный инструмент, не оптимизированный под выбранный язык, может без веских причин выдавать много срабатываний.
Кроме того, нужно выбирать инструмент, который может беспрепятственно интегрироваться в текущую DevOps-среду и CI/CD-пайплайн. Это избавит от необходимости отдельно настраивать или запускать сканирование, что могло бы увеличить количество лишнего шума в результатах SAST.
#2 Практиковать кастомизацию
Применение индивидуального набора правил к инструменту SAST поможет снизить количество ложноположительных срабатываний. Использование стандартных настроек инструмента может не соответствовать конкретным потребностям организации.
Если настроить инструмент SAST в соответствии с собственными предпочтениями, это поможет выявлять именно те проблемы, которые интересуют организацию, и минимизировать количество ложноположительных оповещений. Внедрение инструмента без предварительной настройки может сгенерировать кучу информационного мусора, из-за которого есть риск пропустить реальные угрозы, вредящие программному обеспечению.
#3 Фильтровать и приоритезировать
Также есть возможность отфильтровывать результаты, которые не имеют существенного значения для жизнеспособности софта. Например, можно игнорировать оповещения из тех частей программы, которые содержат «мертвый код», или из пакетов, что вообще не вызываются.
Это поможет расставить приоритеты в результатах тестирования на основе того, что является наиболее важным для компании. Таким образом появится возможность определить первоочередность их исправления по уровню серьезности угроз, статусу уязвимостей и возможности устранения. Это позволит сосредоточиться на самых критических аномалиях вместо того, чтобы тратить усилия на разбор проблем, которые почти или вообще ни на что не влияют.
Чем помогает Mend SAST
Mend SAST позволяет разработчикам создавать приложения быстро без компромиссов с безопасностью. С ним возможно эффективно сократить риски и уменьшить операционные нагрузки, которые обычно возникают из-за лавины оповещений. Mend SAST имеет революционный движок сканирования, который выдает результаты в 10 раз быстрее традиционных решений, так что разработчикам не придется ждать.
Он интегрируется в текущую DevOps-среду и CI/CD-пайплайны, поэтому не нужно отдельно настраивать или запускать сканирование. Кроме того, он является комплексным и поддерживает более 30 различных языков программирования, а также множество разнообразных фреймворков и платформ. Это гарантирует видимость более 70 типов CWE (в частности, OWASP Top 10 и SANS 25) в десктопных, веб и мобильных приложениях, обеспечивая глубокий анализ широкого спектра уязвимостей.
Mend SAST обеспечивает максимальную эффективность и удобство для разработчиков, позволяя им выявлять и устранять уязвимости сразу – тогда, когда это сделать быстрее и проще всего. Встроенные отчеты для таких стандартов безопасности, как PCI и HIPAA, позволяют легко выполнять требования по комплаенсу. Эффективность и эргономичность Mend SAST помогут разработчикам программного обеспечения научиться доверять своим рабочим инструментам и охотнее сотрудничать с членами команды безопасности.
