Разработчики используют плагины каждый день, и их функциональность призвана упростить разработку, например, автоматически проверять проставление всех специальных символов (таких как «;», «:») или соблюдение синтаксиса. Они буквально были созданы для того, чтобы разработчики прямо во время написания кода могли осуществить его проверку на уязвимости и сразу исправлять их, не выходя из IDE. Давайте разберемся, какие бывают плагины и как с ними работать?
В последние годы тема безопасной разработки стала очень важной и актуальной. Сегодня уже трудно найти человека, связанного с разработкой или ИБ, который никогда не слышал или не видел упоминаний про DevSecOps. Согласно множеству исследований, атаки на веб-приложения являются одним из наиболее распространенных видов кибератак. Например, согласно данным Positive Technologies, более 72% уязвимостей, найденных пентестерами, были связаны с ошибками в коде приложений, а в 91% приложений была зафиксирована утечка важных данных. Исследований подобного рода довольно много, и сделаны они разными компаниями и людьми; найти их тоже нетрудно — достаточно воспользоваться поисковиком. Но объединяет их одно: они подчеркивают важность и необходимость использования практик безопасной разработки.
При построении DevSecOps-процессов компании стараются внедрять наилучшие и общепризнанные практики. Например, если обратиться к референсной архитектуре DevSecOps компании Sonatype, мы можем не только изучить лучший инструментарий и его место в общем пайплайне, но и отметить очень важную закономерность — смещение проверки кода на безопасность на наиболее ранние этапы разработки (shift left). Это связано с тем, что на каждом этапе от разработки до тестирования и вывода приложения в продакшн происходит удорожание исправления и закрытия оставленных уязвимостей или багов. Это может быть выражено, например, в человеко-часах, когда разработчики по завершении своей работы над проектом направляются на следующий. В случае обнаружения проблемы нужно выдергивать сотрудника с нового проекта или выделять дополнительные часы на работы по закрытию уязвимостей в уже завершенном. С другой стороны, пропущенная в продакшн уязвимость может нести за собой огромные репутационные и финансовые риски. Именно эти аргументы и являются основным толчком к внедрению такой практики, как shift left.
Референсная архитектура DevSecOps компании Sonatype
Если упростить референсную архитектуру, мы можем выделить несколько основных этапов проверки кода, такие как угрозы исходного кода, конвейера сборки и конвейера доставки. На схеме в контексте IDE-плагинов для безопасной разработки нас интересует этап «Угрозы исходного кода». На этом этапе происходит написание кода; эта стадия включает в себя как первые написанные строки, так и готовый код перед сборкой проекта, например мастер-ветка GitLab.
Тут также стоит отметить, что наиболее популярные технологии проверки кода, такие как SAST, DAST, SCA, расположены на этапе «Угрозы конвейера сборки». То есть проверки осуществляются на этапе, когда разработчик уже отправил свой код в репозиторий. Ни одной компании не хватит ресурсов и возможностей, если каждый разработчик будет отправлять на проверку каждую новую написанную функцию или модуль в SAST-анализатор. А в случае, если компания впервые или редко применяет SAST-, DAST- или SCA-анализ, то вполне вероятен сценарий, когда разработчику принесут на исправление и разбор толстый отчет с уязвимостями, а их анализ может затратить довольно ощутимое количество рабочего времени. И именно тут на помощь могут прийти плагины для безопасной разработки.
Смещение фокуса проверок на более ранние этапы разработки
Плагины для безопасной разработки находят уязвимости и не задокументированные возможности в коде приложения прямо в процессе его написания. Встроенные модули анализа обнаруживают уязвимости исходного кода и ошибки конфигурационных файлов, используемые в процессе разработки. Сами плагины используют вычислительные ресурсы компьютера разработчика и не требуют дополнительных сторонних ресурсов. Найти их можно буквально по поиску в маркетплейсе IDE.
Скриншот из маркетплейса VSCode
Сами плагины бывают open и close source, то есть некоторые из них позволяют заглянуть в их исходный код и использовать кастомные правила. Это может быть полезно, если в компании повышенные или нестандартные требования к безопасности кода. В числе прочего они дают возможность заглянуть в исходный код работы самих ядер анализа. Плагины с закрытым исходным кодом не позволяют изменять принцип работы ядер или (в некоторых случаях) дописывать кастомные правила и закрытую базу знаний. Закрытая база знаний содержит уже устоявшиеся правила поиска уязвимостей и алгоритмы поиска. Обычно закрытая база говорит о том, что она наполнена актуальными и действительно содержательными проверками на уязвимости и разработчики продукта продолжают ее поддерживать. Помимо этого, плагины, созданные вендорами, разрабатывающими полноценные SAST-анализаторы, могут быть синхронизированы. Результаты, полученные SAST-решениями, могут быть связаны через плагин в IDE разработчика и позволить ему обработать результаты в привычной обстановке, прямо внутри IDE. Плагины существуют для различных языков программирования, IDE и, соответственно, для разных задач программирования; примеры — в таблице в конце статьи.
На рисунке ниже изображен пример работы плагина для безопасной разработки. На скриншоте можно выделить четыре основных момента:
-
Плагины после анализа кода выводят найденные уязвимости в виде ошибок компиляции. Все найденные уязвимости выводятся списком и позволяют в удобном режиме переключаться между ними.
-
При выборе конкретной уязвимости автоматически подсвечивается уязвимый участок кода.
-
Управление уязвимостью. Ее можно подтвердить, опровергнуть (отметить как false positive, чтобы в дальнейшем эта сработка не мозолила глаза), и если функциональность плагина позволяет, то сразу сгенерировать эксплойт для проверки уязвимости.
-
Отображение потока данных (data flow), которое позволяет пройти с уязвимостью весь путь, начиная, например, от объявления уязвимой переменной, и отследить все ее взаимодействия с другими данными до точки выхода (места, где данная уязвимость будет проэксплуатирована).
Что отображает плагин
Использование плагинов, конечно, не сможет заменить собой полноценный SAST-, DAST- и SCA- анализ и стать панацеей, но может стать отличным дополнительным инструментарием для построения безопасной разработки и реализации практики shift left. Стоит отметить, что в то же SAST-решение проект уже попадает зачастую полностью собранным, а разработчик может отвечать в нем за написание отдельных модулей. Но использовав плагин перед загрузкой своих модулей в общую ветку и осуществив проверку с последующим исправлением, можно сократить количество работы на этапе разбора результатов SAST.
Внедрение плагинов может быть как личной инициативой разработчика, так и регламентированным внутри компании. Личная мотивация — это, например, повышение собственной квалификации. Не секрет, что редко у разработчиков в рамках обучения, будь то курсы или программа университета, предусмотрено обучение принципам ИБ и безопасного кодинга. Плагины помогут очень доступно, на живом примере и в режиме реального времени, продемонстрировать, как недостатки кода могут привести к условной «утечке данных», а самое важное, что появится возможность узнать, как эти недостатки можно устранить. Для компании польза состоит в том, что, помимо shift left, использование плагинов поможет обучить сотрудников, внедрить принципы безопасной разработки и позволит писать чистый код. И, конечно же, общий плюс как для сотрудников, так и для компании, — отличное конкурентное преимущество, ведь безопасность в текущих реалиях стала как никогда актуальна.
Ну и логично закончить примером классных плагинов. Positive Technologies в рамках комьюнити по безопасной разработке PosiDev выпускает для разработчиков бесплатные плагины к IDE, которые доступны в JetBrains и Visual Studio Code . Поэтому если интересуетесь разработкой, обязательно попробуйте их внедрить в работу.
Список плагинов для различных языков программирования и IDE:
Автор Лев Новоженин, AppSec-инженер в Positive Technologies.
