Внедрение статического анализа: на что обратить внимание или 5 «правил хорошего тона»
Статический анализ – это «базовый минимум» наших дней в контексте построения практик разработки безопасного программного обеспечения. Заключается он в инструментальном исследовании исходных кодов программы, не предусматривающем выполнения анализируемого кода.
Статический анализ приятен и прост в применении: не требует запуска исследуемого кода, подготовки исполняемого окружения анализа или гибкой настройки самого анализатора, как, например, в случае с классическими инструментами динамического анализа веб-приложений.
Вместе с этим статический анализ «вгоняет в тоску», особенно тех самых первопроходцев из числа разработчиков, которые осмелились проанализировать свой код: сканирование проходит часами, а по первым результатам иногда и вовсе непонятно что делать. В одних случаях – нет единого интерфейса обработки результатов и приходится работать с логами, в других – результат удобно выносится в отдельный интерфейс, но количество срабатываний измеряется сотнями и даже тысячами.
Важное значение при внедрении процесса статического анализа играет применяемый инструментарий (статический анализатор), выбор которого зависит от исследуемого языка программирования и необходимых критериев к уровню анализа, а также удобства его использования в процессе разработки программного обеспечения.
Опыт интеграции различных средств статического анализа в целях исследования безопасности программных продуктов на множестве языков позволил нам определить следующие лучшие практики.
1. Грамотная оценка требований к статическому анализатору
Кейс: Разработчик запросил внедрение простейшего статического анализатора «как можно быстрее». Через год разработчик проходит сертификацию и возвращается со словами «этот инструмент нам не подходит».
Итог: Повторная апробация уже другого инструмента, перестройка схемы проведения статического анализа и механизмов автоматизации, а самое главное - излишняя затрата ресурсов и времени специалистов.
Совет: Не стоит выбирать первый попавшийся инструмент. Статические анализаторы бывают разные и могут осуществлять различные виды анализа: от более распространённых алгоритмов оценки абстрактного синтаксического древа до множества подвидов анализа графа потока управления. При повышенных требованиях безопасности к конечному продукту должны быть выставлены соответствующие требования к качеству его анализа, в связи с чем к выбору инструмента следует подходить с предельным вниманием. Поэтому следует в том числе следовать рекомендациям, заложенным в национальном стандарте ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования».
2. Формирование единого интерфейса хранения и обработки результатов анализа
Кейс: Разработчик реализовал статический анализ с применением инструмента А, имеющего собственный веб-интерфейс обработки результатов, затем внедрил инструмент B с иным сервером управления историями статического анализа, после чего в пул инструментов статического анализа добавился инструмент С без интерфейса обработки результатов. Внедрение инструментов осуществлялось поэтапно для групп проектов на различных языках программирования.
Итог: Специалистам, занимающимся обработкой результатов инструментальных средств, приходится работать со множеством систем, что лишает реализацию процесса статического анализа удобства и глобально усложняет процесс управления дефектами в коде. Отслеживать все выявляемые ошибки и уязвимости в различных анализаторах становится сложнее.
Совет: При выборе инструментов следует обратить внимание на проприетарные решения, которые, как правило, имеют единый интерфейс обработки результатов, однозначно упростят процесс статического анализа, сделают его прозрачнее и удобнее. В случае использования множества обособленных анализаторов хорошим примером является использование общепринятого форматa отчётов для статических анализаторов (формат SARIF). Также стоит рассмотреть вопрос совместного использования специализированных программ класса ASOC/ASPM для централизации и дедупликации результатов различных автоматизированных проверок программных продуктов. Особую пользу это принесёт в случае, если требуется систематизировать получение артефактов статического анализа, например, в процессе сертификации средств защиты информации.
3. Подготовка внутреннего регламента проведения оценки срабатываний
Кейс: Разработчик внедрил инструмент и подвергает процедуре статического анализа ряд своих проектов. Специалисты, осуществляющие обработку результатов, не проводят оценку должным образом, не дают пояснения срабатываниям, а схожие срабатывания в отличных проектах оцениваются разными специалистами и вовсе по-разному: в одном месте дефект устраняется, в другом – игнорируется.
Итог: Результат работы анализатора не обрабатывается должным образом, актуальные дефекты и уязвимости упускаются из виду, качество кода остаётся на прежнем уровне – всё это снижает эффективность статического анализа.
Совет: При интеграции инструмента стоит чётко определить порядок оценки его результатов: сформировать инструкцию с необходимыми пояснениями для специалистов, участвующих в процессе статического анализа. При этом, в случае, если используется несколько интерфейсов обработки результатов, то подобные инструкции следует сформировать для каждого из них. Вместе с этим важно определить не только порядок исправления подтверждённого дефекта и последующей его перепроверки, но и обоснования неактуальности для неподтвержденного срабатывания: согласно национальному стандарту ГОСТ Р 71207-2024 «Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования», поясняющий комментарий в таких случаях должен в полной мере разъяснять причину неактуальности, а коротких и не подкрепляемых доказательствами формулировок следует избегать.
4. Тонкая настройка статического анализатора
Кейс: Разработчик внедрил инструмент, но слишком много времени тратит на анализ и последующий разбор срабатываний, которые в подавляющем большинстве не будут исправлены.
Итог: Время уходит «впустую», теряется доверие к процессу и результатам статического анализа.
Совет: При интеграции инструмента следует обратить внимание на его тонкую настройку: определить используемые наборы детекторов с целью отключения или изменения уровня серьёзности для тех из них, которые являются избыточными. Также необходимо пересмотреть состав анализируемых проектов, исключив при этом ненужный код (например, юнит-тесты). Вместе с этим стоит внимательно изучить применяемые опции анализатора: некоторые анализаторы, способны, к примеру, выполнять кросс-языковой анализ, что может оказаться для некоторых проектов крайне полезным. В каких-то случаях, наоборот, требуется исключить из анализа нецелевые языки программирования для оптимизации и повышения качества исследований.
5. Особое внимание к артефактам статического анализа
Кейс: Разработчик внедрил инструмент и реализует все требования при проведении статического анализа, однако не может подтвердить это при прохождении сертификационных испытаний.
Итог: Трата ресурсов как временных, так и человеческих, риск повторного проведения отдельных этапов исследований.
Совет: Осуществляйте логирование при проведении анализа, автоматизируйте процесс получения отчётов, не удаляйте файлы артефактов анализатора.
Интеграция статического анализатора – это не только про написание скрипта, который проведёт анализ кода. Этот процесс включает в себя ряд этапов, начиная от выбора инструмента, заканчивая систематизацией артефактов данного процесса. А когда речь идёт о процессе поиска уязвимостей в коде, важно уделять внимание даже самым мелким деталям.
Авторы:
Харитонов Степан Михайлович, руководитель направления безопасной разработки и сертификации ООО «НПЦ «КСБ»
Колосов Алексей Иванович, инженер по безопасной разработке и сертификации ООО «НПЦ «КСБ»
