# Статический анализ и ASOC: нулевая терпимость к ошибкам в проекте

Ни для кого не новость, что цена поздно обнаруженной уязвимости в разработке очень высока\. Но что нужно сделать, чтобы избежать такой ситуации? В статье обсудим, что такое политика нулевой терпимости и то, как статический анализ и ASOC помогут её достичь\.

![1341_StaticAnalysisAndASOC_ru/image1.png](https://import.viva64.com/docx/blog/1341_StaticAnalysisAndASOC_ru/image1.png)

В современной разработке цена обнаруженной после релиза уязвимости катастрофически высока: дефект, приводящий к утечке данных, или критический сбой в системе — это большой удар по репутации и бюджету\. И в отношении таких дефектов традиционный подход "найди и исправь" часто не работает — он слишком медленный, дорогой и ненадёжный\.

Что делать в такой ситуации? Наверное, самый эффективный путь — не дать дефекту шанса появиться в коде\. Именно эту задачу решает политика нулевой терпимости к ошибкам, о которой мы сегодня поговорим\.

## Политика нулевой терпимости к срабатываниям

Несмотря на столь страшное название, нулевая терпимость означает не отсутствие ошибок вообще, а установление жёсткого контроля над конкретными заранее определёнными классами проблем, которые не должны попадать в исходный код ни при каких обстоятельствах\. Достичь такого контроля можно, придерживаясь принципов нулевой терпимости\.

**Принцип профилактики** — предотвращение ошибок на этапе разработки эффективнее и экономически выгоднее их последующего исправления\.

**Принцип немедленного обнаружения** — выявление дефектов должно происходить как можно раньше в жизненном цикле программного обеспечения\.

Оба этих принципа решают примерно одну и ту же проблему\. Ошибка может пройти путь по всем этапам жизненного цикла вплоть до релизной версии продукта\. И с каждым пройденным этапом стоимость этой ошибки растёт: баг в строке кода, который разработчик может исправить в IDE за пару минут, на этапе тестирования уже превращается в 2\-3 часа работы\. Если же эта ошибка попадёт в продакшн, то на её срочное исправление уже уйдёт день работы команды из 3\-5 человек\. И это уже не говоря о том, что баг может нанести урон пользователям ПО\. В таком случае стоимость ошибки может дойти до невероятных масштабов\. 

**Принцип полной ответственности разработчика** — разработчик, написавший код, несёт полную ответственность за его качество, безопасность и исправление дефектов, которые инструмент обнаружил до коммита\. 

Разделение ответственности только создаст дополнительных проблем\. Как минимум, сколько времени в случае инцидента будет потрачено на определение виновного? 

Собственно, для соблюдения этого принципа нужно обеспечить работу анализатора кода на всех необходимых этапах:

* локально на машинах разработчиков \(с помощью, например, IDE плагинов\);
* на сервере \(CI/CD после каждого коммита, а также ночные сборки для мониторинга общего состояния кодовой базы\)\. 

Подробнее о сценариях использования анализатора мы поговорим чуть позже\.

Ну и помимо непосредственно принципов нам также был бы полезен какой\-нибудь стандарт кодирования, который установит для нас чёткие правила\. Соблюдение этих правил вместе с принципами нулевой терпимости поможет достичь наилучшего результата в предотвращении попадания дефектов к пользователям\.

## Стандарты безопасности кода

Существуют различные стандарты безопасности кода, которые помогают поддерживать нулевую терпимость к ошибкам\. Анализатор PVS\-Studio имеет классификацию срабатываний по множеству различных стандартов безопасности: OWASP ASVS, CERT или ГОСТ Р 71207—2024, а также по CWE — системе классификации недостатков безопасности\.


> \*\*Примечание\\\.\*\* Подробнее о PVS\\\-Studio как о SAST\\\-решении можно прочитать \[на этой странице\]\(https://pvs\-studio\.ru/ru/pvs\-studio/sast/\)\\\.

Остановимся подробнее на одном из них\. [OWASP Application Security Verification Standard \(ASVS\)](https://owasp.org/www-project-application-security-verification-standard/) — это список требований к безопасности приложений и тестов, которые могут использоваться архитекторами ПО, разработчиками, тестировщиками, специалистами по защищённости приложений, продавцами инструментов и пользователями для разработки, сборки, тестирования и верификации защищённых приложений\. 

В анализаторе PVS\-Studio есть целая категория диагностических правил, позволяющая находить код, не соответствующий стандартам OWASP\. О том, как их включить и настроить, можно прочитать [в соответствующем разделе](https://pvs-studio.ru/ru/docs/manual/6536/) нашей документации\.

Плагины PVS\-Studio для IDE, кстати, позволяют отображать срабатывания конкретно из этой категории с помощью фильтров, находящихся над таблицей срабатываний:

![1341_StaticAnalysisAndASOC_ru/image2.png](https://import.viva64.com/docx/blog/1341_StaticAnalysisAndASOC_ru/image2.png)

Остаётся вопрос: как искать ошибки? Статические анализаторы предлагают спектр способов, каждый из которых оптимизирован под конкретную задачу и этап работы\. 

## Сценарии использования

Говоря о сценариях работы с анализатором, важно отметить, что для эффективной работы используемый инструмент не должен нарушать стандартный рабочий процесс\. Не стоит, например, использовать отдельную IDE только для работы с результатами анализа, это неудобно и неэффективно\.

При разработке нашего инструмента мы в том числе стараемся сделать так, чтобы PVS\-Studio можно было интегрировать в процесс разработки, не перекраивая его под нужды анализатора\. 

Итак, первым важным этапом в использовании статического анализатора является локальный анализ\. Каждому разработчику необходимо проверять свои изменения локально, и помочь в этом могут плагины для IDE\. Чтобы проверить изменения, достаточно будет пары кликов и небольшого ожидания\. Подробнее о том, в каких IDE можно использовать PVS\-Studio, написано [в этом разделе документации](https://pvs-studio.ru/ru/docs/#:~:text=JSON%20Compilation%20Database-,%D0%A1%D1%80%D0%B5%D0%B4%D1%8B%20%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8,-%D0%A0%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%20PVS%2DStudio)\.

Помимо удобства также важно и максимально сократить необходимое для анализа время\. В этом поможет инкрементальный анализ\. Он позволяет проверять только те файлы, которые изменялись разработчиком, что значительно ускорит работу\. Подробнее о том, что такое инкрементальный анализ, а также о том, как его приготовить, мы писали [целую статью](https://pvs-studio.ru/ru/blog/posts/1218/) в нашем блоге\.

Помимо локального запуска важно иметь и анализ на сервере\. Причём в нескольких вариациях\. Во\-первых, нам нужен анализ приходящих изменений, то есть pull request'ов\. Так мы сможем проверить, что внесённое разработчиком изменение не прячет в себе никаких неприятностей\. Подробнее о том, как это работает — и даже с реальным примером пайплайна для GitHub Actions, — мы говорили [в этой статье](https://pvs-studio.ru/ru/blog/posts/1264/)\.

Во\-вторых, нам необходимо анализировать весь проект в ночных сборках, если в master\-ветку вносились какие\-то изменения\. Нужно это по одной простой причине: нам необходимо оценить, как внесённые изменения повлияли на общую работоспособность проекта\. Это позволяет сделать [межмодульный анализ](https://pvs-studio.ru/ru/blog/terms/6791/)\. Заставлять разработчиков анализировать весь проект, да ещё и с межмодульным анализом, может быть излишне\. 

Для всего, что будет найдено во время серверного анализа, нам нужна система, позволяющая оперативно отслеживать результаты\. В этой роли выступают различные ASOC\-платформы, позволяющие превращать данные статического анализа в задачи, а также предоставлять измеримые метрики безопасности, позволяющие отслеживать развитие проекта во времени\.

> На практике внедрение SAST быстро показывает, что основная сложность заключается уже не в выявлении проблем, а в их системном жизненном цикле\. Необходимо корректно определить приоритеты с учётом критичности сервиса, устранить дублирование предупреждений, назначить ответственных исполнителей, контролировать сроки исправления и объективно измерять прогресс\. Без централизованного инструментария результаты анализа часто так и остаются изолированными отчётами, а команда AppSec вынуждена вручную администрировать процессы между разработкой и безопасностью\.
>
> 
>
> Именно эту задачу CyberCodeReview решает, как единый центр управления уязвимостями\. Платформа трансформирует отчёт PVS\-Studio в управляемые артефакты безопасности с чётким жизненным циклом, статусами и метриками\. Благодаря глубоким интеграциям с экосистемой разработки \(системы контроля версий, CI/CD, трекеры задач\) обнаруженные дефекты автоматически встраиваются в привычный рабочий процесс команд\. Это делает процесс устранения уязвимостей прозрачным, координируемым и позволяет превратить принцип нулевой терпимости в постоянную управляемую практику\.
>
> 
>
> Денис Тропин, CTO и совладелец CyberCodeReview:

## Интеграция в CyberCodeReview

Для рассмотрения того, как это работает, возьмём новую интеграцию PVS\-Studio в [CyberCodeReview](https://cybercodereview.ru/cybercodereview) — ASOC\-платформу для анализа защищённости кода и приложений\. Подробнее о её возможностях можно прочитать в [документации](https://docs.cybercodereview.ru/)\. 

Инструмент позволяет просматривать результаты анализа PVS\-Studio\. Для этого предусмотрена возможность загрузки кроссплатформенного JSON\-отчёта\.

На странице продукта внутри платформы необходимо нажать на кнопку **Импорт**, перетащить или выбрать файл JSON\-отчёта PVS\-Studio, в поле **Сканер** выбрать PVS\-Studio, а также установить другие необходимые настройки\. После этого нужно нажать на кнопку **Импорт**\.

![1341_StaticAnalysisAndASOC_ru/image3.png](https://import.viva64.com/docx/blog/1341_StaticAnalysisAndASOC_ru/image3.png)

После этого, если в отчёте были срабатывания анализатора, они появятся в **Security Center**\. Подробнее о загрузке отчёта с помощью UI можно прочитать в соответствующем [разделе документации](https://docs.cybercodereview.ru/security-center/scanners/importing-reports-from-scanners-to-security-center/manual-import-using-report-file) инструмента\.

После загрузки отчёта все срабатывания анализатора появятся в списке необработанных уязвимостей\. Уровни достоверности срабатываний PVS\-Studio будут совпадать с уровнями критичности в веб\-интерфейсе CyberCodeReview\.

![1341_StaticAnalysisAndASOC_ru/image4.png](https://import.viva64.com/docx/blog/1341_StaticAnalysisAndASOC_ru/image4.png)

Открыв конкретное срабатывание, можно увидеть, на какой файл оно было выдано, какой идентификатор имеет по CWE, а также его сообщение\.

![1341_StaticAnalysisAndASOC_ru/image5.png](https://import.viva64.com/docx/blog/1341_StaticAnalysisAndASOC_ru/image5.png)

Далее на основе срабатывания анализатора можно создать задачу в Jira, подтвердив её и назначив ответственного исполнителя\. Подробнее об интеграции с CyberCodeReview описано в [документации на нашем сайте](https://pvs-studio.ru/ru/docs/manual/7181/)\.

## Заключение

При внедрении статического анализа важно понимать, что сам по себе инструмент не гарантирует отсутствие ошибок, в том числе и критических дефектов безопасности\. Его эффективность раскрывается только в рамках выстроенной системы, основанной на чётких правилах, стандартах и принципах\.

Политика нулевой терпимости — один из наиболее действенных подходов для обеспечения надёжности и безопасности кода\. Стоит помнить простую истину: от ошибок не застрахован даже самый опытный специалист\. Поэтому защита должна строиться не на доверии к человеку, а на процессах, которые не позволяют ошибке превратиться в инцидент\. 

Кстати, проверить свой проект с помощь PVS\-Studio можно благодаря бесплатной лицензии, которую можно [получить здесь](https://pvs-studio.ru/ru/pvs-studio/try-free/)\. Как говорится, лучше один раз увидеть, чем сто раз услышать\.

_Memento securitatis\._