Статические анализаторы в коммерческой разработке: одна голова хорошо, а несколько — лучше

Статические анализаторы в коммерческой разработке: одна голова хорошо, а несколько — лучше

Любая компания, которая начинает внедрять процессы безопасной разработки, в первую очередь задумывается об инструменте статического анализа. С него, как правило, начинается «проба пера» по внедрению практик безопасной разработки. Статические анализаторы являются «пилотом» и «первой ласточкой» в коммуникации зарождающейся роли Application Security (подразделения, ответственного за развитие безопасной разработки) с командой разработки ПО.

Это вполне объяснимо, т. к. данный инструмент ближе программисту. Команды разработки, так или иначе, всегда использовали инструментарий статического анализа (начиная с IDE плагинов и простых линтеров) самостоятельно, без запроса со стороны Application Security. Уже позже развитие отношений между Application Security и разработкой перейдет на новый уровень доверия — использование динамических анализаторов, проведения обучений по тематике безопасной разработки, SCA и т. д., а некоторые даже попробуют фаззинг… Но оставим их и вернемся к «статике».

Статические анализаторы существуют давно и в большом разнообразии представлены на рынке, как в open-source, так и среди коммерческих решений. При выборе подходящего решения компаниям приходится ответить на множество вопросов: что лучше, что удобнее, что эффективнее? И самое главное — как это применить к нашим реалиям, процессам, процедурам сборки (пайплайнам)?

Поразмыслив еще, они понимают, «не мы первые, кто задается таким вопросом», — а что у «коллег по цеху»?

Думаем, что регулятор инициировал сравнение инструментов статического анализа (SAST), в том числе с намерением ответить и на этот вопрос.

Мы в «Лаборатории Касперского» работаем с SAST каждый день, на большом объеме кода, знаем и понимаем данную практику, ежедневно видим пользу от ее применения. В нашей практике встречались как случаи, когда разные инструменты находили одни и те же баги, а также когда ни один из используемых SAST не находил ошибку, которая должна обнаруживаться подобными решениями. 

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

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

Там, где это возможно, инструменты работают в блокирующем режиме — любое срабатывание останавливает заливку кода в мастер-ветку, пока срабатывание не будет обработано.

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

Вопрос необходимости сравнения SAST инструментов мы поднимали в процессе согласования ГОСТ по статическому анализу.

Мы всецело приветствуем инициативу и надеемся на выработку полезных критериев по оценке инструментов. Эти критерии дадут компаниям-новичкам в данной области больше информации для выбора, облегчат им «первый старт», а зрелые компании, вероятно, найдут ответы на давно волнующие их вопросы.

В любом случае, подобные коллаборации ведущих разработчиков ПО приносят пользу и ускоряют развитие всей индустрии разработки.

Пожелаем нам всем удачи и будем с нетерпением ждать результатов!