Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Приложения всё чаще подвергаются кибератакам, а использование 0-day уязвимостей занимает высокие позиции. Внедрение SAST в процесс разработки позволит сделать продукт безопаснее для пользователей. Однако такой путь к безопасному будущему многим кажется непонятным.
SAST (Static Application Security Testing) — тестирование безопасности приложений путём проверки их исходного кода. В процессе анализа SAST-инструмент — статический анализатор — находит участок кода с потенциальной уязвимостью. Преимуществом такого метода тестирования является возможность его применения на ранних этапах разработки, причём подозрительные места могут быть найдены даже в редко используемых участках кода.
Количество инцидентов информационной безопасности растёт с каждым годом. Согласно отчёту Positive Technologies, в 3 квартале 2023 года было проведено 807 кибератак, что на 4.3% процента больше показателя 3 квартала прошлого года; а атаки, связанные с эксплуатацией уязвимостей, занимают 3 место среди всех методов. Не удивительно, что на сегодняшний день во многих компаниях стоит необходимость выстраивания цикла безопасной разработки (SSDLC — Secure Software Development Life Cycle). Нередко инциденты связаны с уязвимостями в исходном коде приложений. Большая часть таких проблем возникает как раз на ранних этапах разработки, непосредственно в процессе написания кода.
SAST-решения призваны помогать разработчикам и специалистам по безопасности с поиском уязвимостей в исходном коде. Более того, SAST заполняет пропасть между безопасностью и разработкой, делая разработчиков более ответственными за свой продукт. В SSDLC использование SAST-инструментов укрепилось как раз на этапе разработки.
Сегодня IDE тоже умеют находить ошибки, связанные с безопасностью, однако их анализ не настолько глубокий, — IDE не помогут найти уязвимости внедрения XSS и SQL-инъекций. Здесь в бой вступают статические анализаторы: их межпроцедурный анализ потока данных позволяет отслеживать изменение данных между несколькими функциями, что помогает в обнаружении потенциальных инъекций. Поэтому одними предупреждениями IDE уже не обойтись. При разработке приложения следует также использовать SAST-инструменты.
Несмотря на необходимость использования SAST, среди руководителей и разработчиков ходит несколько мифов и неясностей. Хотелось бы остановиться подробнее на некоторых из них.
К сожалению, не все видят пользу от использования SAST на регулярной основе. Разработчики или специалисты по безопасности запускают анализ кода продукта, выписывают или сразу исправляют некоторые найденные дефекты и забывают про SAST-инструмент до следующего аудита безопасности. Если же в отчёте не было полезных срабатываний, то может быть принято решение о нецелесообразности внедрения SAST в проверенном проекте.
Единоразовые проверки статическим анализатором активно разрабатываемых проектов могут быть неинформативными, поскольку большинство серьёзных уязвимостей уже могли быть исправлены посредством тестирования, code review и других методов. Преимуществом использования SAST является обнаружение ошибок на ранних стадиях процесса разработки — непосредственно на этапе написания кода. Но для этого необходимо его регулярное использование.
При запуске анализа старого проекта первый раз на разработчика могут свалиться сотни, а то и тысячи разных предупреждений. На их исправление уйдут недели. До проверки приложения оно могло работать стабильно, проблем с безопасностью не было, или они оперативно исправлялись. А теперь разработчик видит на экране монитора многостраничный отчёт с неизвестными ему аббревиатурами CWE, OWASP и прочими.
Конечно, сразу бежать исправлять все предупреждения не имеет смысла. Не все из них могут являться непосредственно серьёзными ошибками или дефектами безопасности. Как правило, современные статические анализаторы фильтруют предупреждения по категориям: от самых критичных до мелких улучшений, от проблем производительности до потенциальных уязвимостей. Критичные предупреждения как раз могут являться тем, на что необходимо обратить внимание в первую очередь.
От большей части ложных срабатываний можно избавиться даже путем правильной настройки SAST-решения — это заметно снизит их процент, но, конечно, не избавит от необходимости постепенного исправления найденных проблем. А вот как в начале использования SAST не нагрузить разработчиков, вы можете почитать в нашей статье "Как внедрить статический анализатор кода в legacy проект и не демотивировать команду".
SAST-инструменты могут казаться трудными в настройке. Если одна часть людей считает статический анализатор простым инструментом, то вторая, наоборот, может долго откладывать его запуск, так как анализатор видится им сложным и непонятным.
Для рядового разработчика ничего сложного в настройке SAST нет. Первоначально достаточно просто установить анализатор, зарегистрировать лицензию, если необходимо, и запустить сборку проекта. Многие SAST-решения поддерживают инкрементальный анализ, так что после сборки код приложения сразу будет проверен. Как правило, инструменты имеют понятную для разработчиков документацию и доступную техническую поддержку, куда всегда можно обратиться, так что серьёзных проблем с дальнейшей настройкой не должно возникнуть.
Всё оказалось легко и просто. Однако из-за страха первого запуска компания может лишиться такой полезной вещи, как SAST.
Еще одной проблемой, которая может возникнуть при внедрении SAST, является выбор хорошего инструмента. На рынке представлено достаточно разных решений, так как же выбрать из них то, которое подойдет для проекта?
При выборе статического анализатора в первую очередь стоит руководствоваться используемыми в проекте языками программирования, а также платформами, на которых производится разработка. Сегодня анализаторы доступны почти для всех языков программирования и платформ, инструменты имеют плагины для большинства популярных IDE. Рынок SAST также довольно большой, так что можно не останавливаться на одном варианте, а сравнить несколько анализаторов и выбрать более подходящий вашему проекту.
Так как SAST-решения призваны искать уязвимости в исходном коде, следует также обратить внимание на покрытие инструментом требований стандартов безопасной разработки и возможность поиска уязвимостей из соответствующих баз и списка потенциальных уязвимостей CWE, OWASP ASVS.
Когда мы говорим о внедрении SAST в процесс разработки, нельзя не вспомнить и про CI/CD. Третьим критерием при выборе статического анализатора является интеграция с CI/CD системами. Важно принять во внимание не только простоту настройки инструмента, но и разнообразие форматов отчёта и удобство их просмотра.
Стоит обратить внимание на удобство пользования SAST-инструментом в принципе, так как анализатор призван помогать в code review и в поиске уязвимостей, а не мешать разработке продукта. Хороший инструмент должен подсвечивать проблемные участки кода, ссылаться на нужный файл и правильную строку в текстовом отчете, иметь функционал по быстрому подавлению ложных срабатываний.
Во время исследования рынка SAST в первую очередь можно изучить и сравнить популярные анализаторы. Такие инструменты должны уметь проводить глубокий анализ, быть удобными и находить большинство потенциальных уязвимостей. В качестве примера хотелось бы рассмотреть SAST-решение PVS-Studio.
PVS-Studio — это статический анализатор кода для поиска ошибок и потенциальных уязвимостей в коде программ, написанных на языке C, C++, C#, Java. Анализатор поддерживает операционные системы Windows, Linux и macOS и может быть интегрирован в большинство популярных CI/CD систем.
Будучи SAST-инструментом, PVS-Studio поддерживает поиск потенциальных уязвимостей CWE, а также следит за соответствием таким стандартам безопасной разработки, как OWASP ASVS и SEI CERT Coding Standards. А если к вашему продукту предъявляются требования к надёжности, PVS-Studio поможет проверить код на соответствие стандартам MISRA C, MISRA C++ и AUTOSAR C++14 Coding Guidelines.
Если ваш проект написан на C#, вы можете использовать PVS-Studio как SCA-решение: анализатор умеет искать уязвимости в компонентах, используемых в приложении.
PVS-Studio входит в реестр отечественного ПО: N 9837. Анализатор можно использовать по требованию ФСТЭК без сертификации в проектах до 4-го уровня доверия включительно.
Вы также можете попробовать PVS-Studio самостоятельно в течение 7 дней. Просто загрузите анализатор по этой ссылке.
Чем же PVS-Studio удобен в повседневном использовании? Для удобства встраивания в процессы PVS-Studio предлагает механизм подавления предупреждений для выстраивания baseline-уровня сообщений, который полезен как при регулярных проверках, так и при внедрении в legacy-проект. Механизм подавления основан на использовании специальных suppress файлов, в которых хранятся предупреждения, помеченные как "ненужные" для проверяемого проекта. Подавить сообщения можно непосредственно в плагине, выделив их в отчёте анализатора.
Ещё одна полезная фича PVS-Studio — утилита blame-notifier, предназначенная для автоматизации оповещения по почте разработчиков, на код которых анализатор выдал предупреждения. Отчёт может рассылаться как отдельно каждому разработчику, на код которого анализатор выдал предупреждение, так и, например, тимлиду полностью: с указанием разработчиков, предупреждений и самих проблемных мест.
Подводя итоги, можно сказать, что в современном процессе разработки программного продукта не обойтись без использования SAST-решений. Компании всё чаще принимают решения о создании веб-приложений, а среди всех инцидентов безопасности атаки на веб-сервисы занимают не последнее место. Чтобы уменьшить репутационные и денежные риски, необходимо побеспокоиться о безопасности своего продукта, о выстраивании SSDLC и DevSecOps и, соответственно, о внедрении SAST в процесс разработки.
Однако не стоит относиться к статическим анализаторам как к панацее от всех проблем и уязвимостей. SAST-инструменты не идеальны и вряд ли таковыми будут. Они призваны в первую очередь помогать замечать подозрительные места в коде, но не каждое подозрительное место может являться дефектом. При этом это не означает, что SAST применять бессмысленно. Большинство уязвимостей могут быть допущены из-за невнимательности разработчиков. Такой помощник, как статический анализатор, позволит избежать подобных проблем.
Виктория Пелипенко — специалист по поддержке пользователей и C# программист в отделе внутренней разработки в PVS-Studio. Помогает людям внедрить в свои процессы SAST-инструмент, а также сама использует анализатор при разработке. Интересуется темой информационной безопасности и стремится создавать защищенные системы.
0
0
0
130
0
0