Статическое
тестирование безопасности приложений (SAST) снискало популярность среди групп
по безопасности как простой способ развертывания тестирования безопасности без
реального привлечения разработчиков. Благодаря возможности анализа исходного
кода на ранних этапах жизненного цикла поставки ПО решения SAST предлагали
более проактивный подход к поиску проблем безопасности до начала производства.
Но это имело свою цену.
Многие из результатов
инструментов SAST являются потенциальными уязвимостями, что
означает, что для оценки и приоритизации рисков требуется много ручных усилий и
времени. Разработчикам остается анализировать тысячи оповещений с минимальным
контекстом, чтобы определить, какие проблемы являются наиболее критическими, не
говоря уже о том, как сопоставить их с категориями CWE, чтобы точно определить
реальную проблему и необходимое исправление.
Боль в SAST
Первоначальное
обещание SAST проактивного тестирования безопасности для групп безопасности
быстро стало фундаментальной проблемой для разработчиков из-за его
чрезвычайного шума. Завалив разработчиков тысячами результатов, в основном
«ложных срабатываний», и пометив шаблоны кода как «потенциально небезопасные»
без оценки фактической эксплуатируемости, оно сделало практически невозможным
для разработчиков расставить приоритеты в исправлении проблем. SAST также не
предоставляет осмысленного контекста; он может обнаружить проблемный шаблон
кода, но он не может определить, действительно ли этот код используется, открыт
для Интернета или активно способствует эксплуатируемой уязвимости. Он не
отвечает на важные вопросы, например: работает ли этот код в
производстве? Открыт ли он? Может ли он быть фактически эксплуатируемым?
Результат? Тысячи
оповещений, но ничего не исправляется. Разработчики остаются в тикетах Jira,
разбросанных по PR и бэклогам, с неопределенными сроками «как можно скорее» и
без четкого понимания приоритетов.
Между тем, программное
обеспечение еще предстоит выпустить.
SAST требует контекста выполнения для расстановки приоритетов
Безопасность без
контекста — это просто догадки. Без знания того, что можно эксплуатировать, где
в кодовой базе существует риск и как его исправить — тестирование безопасности
— это просто поток бессмысленных предупреждений. Современное динамическое
тестирование безопасности приложений (DAST) переворачивает сценарий, тестируя
приложения во время выполнения, выявляя реальные риски вместо теоретических.
Вместо того чтобы выдавать отчет, полный «потенциальных» проблем, оно четко сообщает
разработчикам: эта уязвимость может быть эксплуатирована в этой службе, в этой
строке кода. Вот в чем сила контекста, которую мы создали в StackHawk.
Теперь я первым
признаю, что у устаревшего DAST были свои проблемы. Эти решения традиционно
были медленными, не соответствовали рабочим процессам разработчиков и не
обращали внимания на API. Сканирование производства занимало часы или дни, и
даже когда уязвимости были обнаружены, не было возможности отследить их до
исходного кода для простого исправления. Без тестирования API устаревший DAST
пропускал значительную часть современной поверхности атаки, оставляя
организации уязвимыми.
Однако современные
решения DAST решают эти проблемы, работая как код, тестируя API и микросервисы
в режиме реального времени и предоставляя мгновенную обратную связь там, где
работают разработчики.
Современные DAST + SAST = практические идеи
Современный DAST
продолжит развиваться и поддерживать скорость доставки современного
программного обеспечения, которая только ускоряется с ростом ИИ. В мире DAST
2.0 API и приложения тестируются в режиме реального времени, пока разработчики
пишут и объединяют код. Инженеры и команды по безопасности теперь получают
немедленные, действенные сведения о безопасности в своих рабочих процессах, вместо
того чтобы просеивать поток потенциальных уязвимостей.
Если говорить кратко:
объединяя результаты SAST с современным контекстом DAST, инженеры могут
расставить приоритеты и открыть шлюзы для более быстрой и безопасной поставки
программного обеспечения.
Заключение
SAST помог определить
раннюю эру AppSec, но он никогда не был разработан для масштаба, сложности и
скорости современной разработки. Разработчики тонут в шуме, а команды по
безопасности погребены под уязвимостями, которым не хватает четкой приоритетности.
С кодированием с помощью ИИ будущее SAST может устареть, поскольку ИИ-пилоты
будут генерировать исправления и рекомендации.
Современный DAST
обеспечивает проверку там, где это важно в точке риска, в режиме реального
времени, интегрированную непосредственно в инженерные рабочие процессы. Речь
идет не только о поиске уязвимостей, но и о доказательстве того, что можно
эксплуатировать, и обеспечении быстрых и эффективных исправлений.
Комментариев нет:
Отправить комментарий