Мы используем куки, чтобы пользоваться сайтом
было удобно.
Вебинар: Статический анализ кода в методическом документе ЦБ РФ "Профиль защиты" - 16.02
Ни для кого не новость, что цена поздно обнаруженной уязвимости в разработке очень высока. Но что нужно сделать, чтобы избежать такой ситуации? В статье обсудим, что такое политика нулевой терпимости и то, как статический анализ и ASOC помогут её достичь.
В современной разработке цена обнаруженной после релиза уязвимости катастрофически высока: дефект, приводящий к утечке данных, или критический сбой в системе — это большой удар по репутации и бюджету. И в отношении таких дефектов традиционный подход "найди и исправь" часто не работает — он слишком медленный, дорогой и ненадёжный.
Что делать в такой ситуации? Наверное, самый эффективный путь — не дать дефекту шанса появиться в коде. Именно эту задачу решает политика нулевой терпимости к ошибкам, о которой мы сегодня поговорим.
Несмотря на столь страшное название, нулевая терпимость означает не отсутствие ошибок вообще, а установление жёсткого контроля над конкретными заранее определёнными классами проблем, которые не должны попадать в исходный код ни при каких обстоятельствах. Достичь такого контроля можно, придерживаясь принципов нулевой терпимости.
Принцип профилактики — предотвращение ошибок на этапе разработки эффективнее и экономически выгоднее их последующего исправления.
Принцип немедленного обнаружения — выявление дефектов должно происходить как можно раньше в жизненном цикле программного обеспечения.
Оба этих принципа решают примерно одну и ту же проблему. Ошибка может пройти путь по всем этапам жизненного цикла вплоть до релизной версии продукта. И с каждым пройденным этапом стоимость этой ошибки растёт: баг в строке кода, который разработчик может исправить в IDE за пару минут, на этапе тестирования уже превращается в 2-3 часа работы. Если же эта ошибка попадёт в продакшн, то на её срочное исправление уже уйдёт день работы команды из 3-5 человек. И это уже не говоря о том, что баг может нанести урон пользователям ПО. В таком случае стоимость ошибки может дойти до невероятных масштабов.
Принцип полной ответственности разработчика — разработчик, написавший код, несёт полную ответственность за его качество, безопасность и исправление дефектов, которые инструмент обнаружил до коммита.
Разделение ответственности только создаст дополнительных проблем. Как минимум, сколько времени в случае инцидента будет потрачено на определение виновного?
Собственно, для соблюдения этого принципа нужно обеспечить работу анализатора кода на всех необходимых этапах:
Подробнее о сценариях использования анализатора мы поговорим чуть позже.
Ну и помимо непосредственно принципов нам также был бы полезен какой-нибудь стандарт кодирования, который установит для нас чёткие правила. Соблюдение этих правил вместе с принципами нулевой терпимости поможет достичь наилучшего результата в предотвращении попадания дефектов к пользователям.
Существуют различные стандарты безопасности кода, которые помогают поддерживать нулевую терпимость к ошибкам. Анализатор PVS-Studio имеет классификацию срабатываний по множеству различных стандартов безопасности: OWASP ASVS, CERT или ГОСТ Р 71207—2024, а также по CWE — системе классификации недостатков безопасности.
Примечание. Подробнее о PVS-Studio как о SAST-решении можно прочитать на этой странице.
Остановимся подробнее на одном из них. OWASP Application Security Verification Standard (ASVS) — это список требований к безопасности приложений и тестов, которые могут использоваться архитекторами ПО, разработчиками, тестировщиками, специалистами по защищённости приложений, продавцами инструментов и пользователями для разработки, сборки, тестирования и верификации защищённых приложений.
В анализаторе PVS-Studio есть целая категория диагностических правил, позволяющая находить код, не соответствующий стандартам OWASP. О том, как их включить и настроить, можно прочитать в соответствующем разделе нашей документации.
Плагины PVS-Studio для IDE, кстати, позволяют отображать срабатывания конкретно из этой категории с помощью фильтров, находящихся над таблицей срабатываний:
Остаётся вопрос: как искать ошибки? Статические анализаторы предлагают спектр способов, каждый из которых оптимизирован под конкретную задачу и этап работы.
Говоря о сценариях работы с анализатором, важно отметить, что для эффективной работы используемый инструмент не должен нарушать стандартный рабочий процесс. Не стоит, например, использовать отдельную IDE только для работы с результатами анализа, это неудобно и неэффективно.
При разработке нашего инструмента мы в том числе стараемся сделать так, чтобы PVS-Studio можно было интегрировать в процесс разработки, не перекраивая его под нужды анализатора.
Итак, первым важным этапом в использовании статического анализатора является локальный анализ. Каждому разработчику необходимо проверять свои изменения локально, и помочь в этом могут плагины для IDE. Чтобы проверить изменения, достаточно будет пары кликов и небольшого ожидания. Подробнее о том, в каких IDE можно использовать PVS-Studio, написано в этом разделе документации.
Помимо удобства также важно и максимально сократить необходимое для анализа время. В этом поможет инкрементальный анализ. Он позволяет проверять только те файлы, которые изменялись разработчиком, что значительно ускорит работу. Подробнее о том, что такое инкрементальный анализ, а также о том, как его приготовить, мы писали целую статью в нашем блоге.
Помимо локального запуска важно иметь и анализ на сервере. Причём в нескольких вариациях. Во-первых, нам нужен анализ приходящих изменений, то есть pull request'ов. Так мы сможем проверить, что внесённое разработчиком изменение не прячет в себе никаких неприятностей. Подробнее о том, как это работает — и даже с реальным примером пайплайна для GitHub Actions, — мы говорили в этой статье.
Во-вторых, нам необходимо анализировать весь проект в ночных сборках, если в master-ветку вносились какие-то изменения. Нужно это по одной простой причине: нам необходимо оценить, как внесённые изменения повлияли на общую работоспособность проекта. Это позволяет сделать межмодульный анализ. Заставлять разработчиков анализировать весь проект, да ещё и с межмодульным анализом, может быть излишне.
Для всего, что будет найдено во время серверного анализа, нам нужна система, позволяющая оперативно отслеживать результаты. В этой роли выступают различные ASOC-платформы, позволяющие превращать данные статического анализа в задачи, а также предоставлять измеримые метрики безопасности, позволяющие отслеживать развитие проекта во времени.
На практике внедрение SAST быстро показывает, что основная сложность заключается уже не в выявлении проблем, а в их системном жизненном цикле. Необходимо корректно определить приоритеты с учётом критичности сервиса, устранить дублирование предупреждений, назначить ответственных исполнителей, контролировать сроки исправления и объективно измерять прогресс. Без централизованного инструментария результаты анализа часто так и остаются изолированными отчётами, а команда AppSec вынуждена вручную администрировать процессы между разработкой и безопасностью.
Именно эту задачу CyberCodeReview решает, как единый центр управления уязвимостями. Платформа трансформирует отчёт PVS-Studio в управляемые артефакты безопасности с чётким жизненным циклом, статусами и метриками. Благодаря глубоким интеграциям с экосистемой разработки (системы контроля версий, CI/CD, трекеры задач) обнаруженные дефекты автоматически встраиваются в привычный рабочий процесс команд. Это делает процесс устранения уязвимостей прозрачным, координируемым и позволяет превратить принцип нулевой терпимости в постоянную управляемую практику.
Денис Тропин, CTO и совладелец CyberCodeReview:
Для рассмотрения того, как это работает, возьмём новую интеграцию PVS-Studio в CyberCodeReview — ASOC-платформу для анализа защищённости кода и приложений. Подробнее о её возможностях можно прочитать в документации.
Инструмент позволяет просматривать результаты анализа PVS-Studio. Для этого предусмотрена возможность загрузки кроссплатформенного JSON-отчёта.
На странице продукта внутри платформы необходимо нажать на кнопку Импорт, перетащить или выбрать файл JSON-отчёта PVS-Studio, в поле Сканер выбрать PVS-Studio, а также установить другие необходимые настройки. После этого нужно нажать на кнопку Импорт.
После этого, если в отчёте были срабатывания анализатора, они появятся в Security Center. Подробнее о загрузке отчёта с помощью UI можно прочитать в соответствующем разделе документации инструмента.
После загрузки отчёта все срабатывания анализатора появятся в списке необработанных уязвимостей. Уровни достоверности срабатываний PVS-Studio будут совпадать с уровнями критичности в веб-интерфейсе CyberCodeReview.
Открыв конкретное срабатывание, можно увидеть, на какой файл оно было выдано, какой идентификатор имеет по CWE, а также его сообщение.
Далее на основе срабатывания анализатора можно создать задачу в Jira, подтвердив её и назначив ответственного исполнителя. Подробнее об интеграции с CyberCodeReview описано в документации на нашем сайте.
При внедрении статического анализа важно понимать, что сам по себе инструмент не гарантирует отсутствие ошибок, в том числе и критических дефектов безопасности. Его эффективность раскрывается только в рамках выстроенной системы, основанной на чётких правилах, стандартах и принципах.
Политика нулевой терпимости — один из наиболее действенных подходов для обеспечения надёжности и безопасности кода. Стоит помнить простую истину: от ошибок не застрахован даже самый опытный специалист. Поэтому защита должна строиться не на доверии к человеку, а на процессах, которые не позволяют ошибке превратиться в инцидент.
Кстати, проверить свой проект с помощь PVS-Studio можно благодаря бесплатной лицензии, которую можно получить здесь. Как говорится, лучше один раз увидеть, чем сто раз услышать.
Memento securitatis.
0
0
0
193
2
0