ГОСТ Р № 71207-2024 от 18.01.2024

5.2 На подготовительном этапе проведения статического анализа ПО осуществляют выбор инструмента или набора инструментов статического анализа для регулярного проведения анализа всего кода ПО в рамках жизненного цикла ПО в соответствии с требованиями разделов 7 и 8. Для этого должен быть выполнен анализ документации ПО, а также анализ исходного кода ПО для определения языков программирования, на которых написано ПО, параметров среды функционирования ПО. Для ПО, требующего сборки (трансляций кода, компоновки и т. п.), должен быть выполнен анализ документации системы сборки, инструментов сборки ПО и параметров среды их функционирования (операционные системы, процессорные архитектуры).
С учетом этих данных необходимо выбрать один или несколько статических анализаторов, удовлетворяющих требованиям разделов 7 и 8 и обеспечивающих анализ ПО с установленными параметрами. 
Статический анализатор (набор анализаторов) должен обеспечивать поиск ошибок в программах, написанных на языках программирования, используемых при разработке ПО. Следует использовать регулярно обновляющиеся статические анализаторы, поддерживающие современные стандарты языков программирования и соответствующие системы сборки. 

5.3 Для ПО, требующего сборки, необходимо подготовить сборочную среду ПО и среду анализа ПО. В противном случае, если сборка не предусмотрена (например, ПО состоит исключительно из интерпретируемых скриптов), подготавливают только среду анализа ПО.
Следует использовать среду анализа ПО, позволяющую выполнять статический анализ ПО выбранным инструментом (набором инструментов) анализа с учетом заданных в разделе 5 временных ограничений на периодичность проводимого анализа и устранение выявленных потенциальных ошибок. 
Допустимо использовать для сборки и анализа статический анализатор, развернутый в виртуальной инфраструктуре или предоставляемый разработчику ПО в виде сервиса. 

Для ПО, требующего сборки, настройка инструмента анализа заключается в выполнении в подготовленной сборочной среде первичной сборки ПО под контролем статического анализатора и в первичной конфигурации анализатора. В противном случае, если сборка не предусмотрена, действия ограничиваются первичной конфигурацией анализатора.
В ходе конфигурации должны быть выполнены выбор и включение типов предупреждений анализатора, соответствующих списку критических ошибок, приведенных в 6.3. В ходе конфигурации могут быть также включены другие типы предупреждений анализатора, соответствующих другим потенциальным ошибкам, специфичным для анализируемого ПО (дефекты кодирования для языка программирования ПО, принятые стили кодирования и пр.).
Выполнение первичного анализа заключается в запуске анализатора в подготовленной конфигурации и в среде анализа ПО. В результате первичного анализа должен быть получен исходный набор выданных анализатором предупреждений и выполнена настройка параметров анализатора на анализ данного ПО в среде анализа (количество потребляемой памяти, процессорных ядер и т. п.).
Полученный набор предупреждений должен быть размечен согласно 5.5. Результаты разметки должны быть сохранены для возможности сравнения результатов последующих запусков анализатора на данном ПО. Данные результаты формируют начальную базу предупреждений о потенциальных ошибках. 
После анализа результатов первичной разметки конфигурация статического анализатора может быть доработана, в частности могут быть включены дополнительные типы предупреждений, выполнена настройка анализатора на используемые в заданном ПО заимствованные компоненты, доработаны и настроены алгоритмы выдачи конкретных типов предупреждений и пр. Кроме того, статический анализатор может быть по-разному настроен для различных компонентов анализируемого ПО, например для тестов искать только критические ошибки. 
На основании результатов начального этапа проведения статического анализа ПО может быть принято решение о выборе другого статического анализатора. 

5.5 Предупреждения о потенциальных ошибках, полученные в ходе статического анализа ПО, должны быть размечены: просмотрены для экспертного определения их истинности или ложности. Каждое выданное предупреждение о критической ошибке (типы критических ошибок приведены в 6.3—6.5) должно быть отнесено к определенной категории. Категории должны включать: истинные предупреждения, ложные предупреждения, истинные, но не требующие исправлений кода предупреждения. Допускается расширять приведенный перечень категорий. 

5.6 Для своевременного выявления и исправления ошибок статический анализ должен регулярно применяться к разрабатываемому ПО. Накопление непроанализированных изменений ухудшает качество проводимой экспертизы результатов анализа, а именно: чаще возникают ошибки, при которых истинное предупреждение неверно классифицируется как ложное срабатывание, а также увеличивается длительность проводимой экспертизы. Затем такое накопление приводит и к усложнению выявленных исправлений ошибок в силу увеличившегося временного промежутка между внесением ошибки и ее исправлением.
Регулярность статического анализа ПО обеспечивается автоматизацией процедуры проведения анализа согласно требованиям 5.6—5.8, например с помощью системы непрерывной интеграции. 
Статический анализ ПО в рамках жизненного цикла ПО следует проводить регулярно на этапе конструирования и комплексирования ПО. Статический анализ всего разрабатываемого ПО следует выполнять не реже одного раза в 10 рабочих дней, если за данный период времени исходный код был изменен. Статический анализ добавленных или измененных частей ПО следует выполнять после каждого внесенного изменения. 
Результаты каждого проведенного статического анализа должны сохраняться в хранилище результатов анализа. 
В случае использования при разработке ПО системы непрерывной интеграции проведение статического анализа должно быть включено в состав автоматически выполняемых проверок кода. 

5.8 Выданные статическим анализатором предупреждения должны быть размечены согласно 5.5. Для своевременной и эффективной работы с полученными результатами статического анализа просмотр выданных анализатором предупреждений следует выполнять: 

5.9 Выявленные потенциальные ошибки, которые в результате верификации согласно 5.7 были отнесены к истинным, не позже, чем через 10 рабочих дней после выполнения разметки следует исправить либо запланировать сроки их устранения в соответствии с принятыми разработчиком ПО процессами разработки ПО. Если применяется гибкая методология разработки ПО, то план по устранению потенциальной ошибки включается в ближайший цикл разработки. При анализе ПО целиком устранение выявленных потенциальных критических ошибок должно быть выполнено не позднее начала квалификационного тестирования ПО. Для выполненных изменений исходного кода ПО должна быть обеспечена возможность однозначной идентификации изменений, которые исправляют конкретные ошибки. 

5.13 В соответствии с требованиями ГОСТ Р 56939 разработчик ПО должен проводить регулярный поиск уязвимостей на этапе эксплуатации жизненного цикла ПО. В состав применяемых инструментальных средств разработчик ПО должен включать статический анализатор. Рекомендуется настраивать конфигурацию статического анализатора и применять специализированные методы статического анализа для более глубокого поиска ошибок. Например, настройка конфигурации может задавать другие пороговые значения для используемых ресурсов, таких как память и вычислительные ядра процессора, менять параметры эвристик применяемых математических моделей. Примером специализированного метода анализа является статический анализ помеченных данных. 

7.2 Статический анализатор представляет собой один инструмент или набор инструментов, обеспечивающих в совокупности выполнение требований 7.3—7.6. В этом случае для каждого типа ошибки по 7.3 в наборе должны быть инструменты, удовлетворяющие требованиям 7.4—7.6. 

7.3 Методы анализа, реализованные в статическом анализаторе, должны обеспечивать поиск критических ошибок, типы которых определяются в соответствии с поддерживаемым языком программирования. Требуемые типы критических ошибок для компилируемых языков — согласно 6.3, кроме приведенных в перечислении д), для интерпретируемых — согласно 6.4, кроме приведенных в перечислении в), дополнительно для языков C/C++ — согласно 6.5. Методы анализа могут обеспечивать поиск остальных типов критических ошибок по 6.3 и 6.4. 

7.6 Если статический анализатор для поиска ошибок, определенных в 6.3, перечисление а), применяет анализ помеченных данных, должна быть предоставлена возможность конфигурации анализа: должны задаваться процедуры-источники и процедуры-стоки чувствительных данных. 

8.2 Статический анализатор должен поддерживать анализ ПО с используемыми заимствованными компонентами целиком, при этом удовлетворяя требованиям 7.3—7.6, 8.3 и 8.4. 

8.4 Требования по качеству выполняемого статического анализа предъявляются для критических типов ошибок, приведенных в 6.3—6.5, и проверяются на квалификационном наборе тестов, построенных в соответствии с требованиями раздела 10.
Для данных типов ошибок на наборе тестов, отвечающих требованиям 10.4, статический анализатор должен обеспечивать достижение следующих показателей: 

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

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

8.7 Статический анализатор должен обеспечивать возможность автоматизации действий, приведенных в 5.6, для использования в системах непрерывной интеграции, например с помощью предоставления консольного интерфейса или программного интерфейса статического анализатора. 

9.2 Для обеспечения процессов проведения статического анализа согласно требованиям 5.3 и 5.6 привлекаются специалисты, совмещающие компетенции по разработке ПО с компетенциями по информационно-технологическому обслуживанию (системному администрированию). Следует привлекать специалистов, обладающих следующими знаниями и умениями: 

9.3 Для обеспечения процессов проведения статического анализа согласно требованиям 5.2, 5.4, 5.7—5.12 привлекаются специалисты, совмещающие компетенции по разработке ПО с компетенциями в области обеспечения кибербезопасности. Следует привлекать специалистов, обладающих следующими знаниями и умениями: 

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

10.1.1 Проверку на соответствие требованиям раздела 7 и 8.5—8.12 выполняют путем анализа документации статических анализаторов и иных реализующих требования программ и последующего анализа результатов их запусков в соответствующих рабочих окружениях (успешен/не успешен). Проверку на полноту реализованных методов и ошибок анализа согласно 7.3—7.6 дополнительно выполняют с помощью набора квалификационных тестов согласно 10.1.2. 

10.1.2 Проверка на соответствие требованиям 8.4 должна выполняться с помощью набора квалификационных тестов, удовлетворяющего требованиям 10.2, для каждого языка программирования, поддерживаемого статическим анализатором.
Если для языка программирования отсутствует доступный набор тестов, в полной мере соответствующий требованиям 10.2, допускается использовать набор тестов, частично соответствующий требованиям 10.2.
Примечание — Примером открытого набора тестов, частично соответствующего требованиям 10.2, перечисления а) и б), является Juliet Test Suite. 

Состав набора квалификационных тестов следует регулярно пересматривать. 
Пример построения квалификационных тестов для ошибки переполнения буфера с использованием ряда поточных вариантов согласно 10.2, перечисление а), представлен в приложении Б. 

10.4 Долю ложноположительных срабатываний рассчитывают по формуле:
100 % • FPW/TW,
где FPW — число предупреждений об обнаруженных ошибках, отнесенных к ложным срабатываниям;
TW — число всех предупреждений об ошибках, выданных статическим анализатором.
Показатель доли ложноположительных срабатываний, заданный требованиями 8.4, перечисление а), должен независимо рассчитываться и оцениваться для двух групп тестов: квалификационных тестов небольшого размера, отвечающих требованиям 10.2, перечисления а) и б), квалификационных тестов различных размеров, отвечающих требованиям 10.2, перечисление в). 

10.5 Долю ложноотрицательных срабатываний (пропусков) рассчитывают по формуле:
100 %-FN/TB,
где FN — число известных ошибок, которые не были обнаружены;
ТВ — суммарное число ошибок в тестовых программах, намеренно заложенных и непреднамеренно внесенных в код и обнаруженных в ходе анализа.
Примечание — Из-за наличия в составе набора тестов на базе реальных программ возможны ситуации выявления ранее неизвестных ошибок, которые были допущены разработчиками программы, на базе которой разрабатывался тест.
Показатель доли ложноотрицательных срабатываний, заданный требованиями 8.4, перечисление б), должен независимо рассчитываться и оцениваться для двух групп тестов: квалификационных тестов небольшого размера, отвечающих требованиям 10.2, перечисления а) и б), квалификационных тестов различных размеров, отвечающих требованиям 10.2, перечисление в). 

10.7 Для оценки выполнимости требований 8.3 (скорости работы статического анализатора) следует применять набор квалификационных тестов, удовлетворяющий требованиям 10.2.