ГОСТ Р 71207-2024 Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования.
ГОСТ Р 71207-2024
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Защита информации
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Статический анализ программного обеспечения. Общие требования
Information protection. Secure software development. Software static analysis. General requirements
ОКС 35.020
Дата введения 2024-04-01
Предисловие
1 РАЗРАБОТАН Федеральной службой по техническому и экспортному контролю (ФСТЭК России), Федеральным государственным бюджетным учреждением науки "Институт системного программирования им.В.П.Иванникова Российской академии наук" (ИСП РАН)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 января 2024 г. № 25-ст
4 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Уровень безопасности создаваемого программного обеспечения (ПО) связан с наличием уязвимостей и критических ошибок в программном коде. В свою очередь, количество найденных ошибок во многом определяется уровнем используемых в ходе разработки инструментов. Для этого современные инструменты поиска ошибок, такие как статические и динамические анализаторы, обеспечивают определенный набор характеристик анализа: полноту и качество, скорость, удобство для пользователя, применимость к современным языкам программирования и др.
Настоящий стандарт устанавливает общие требования к внедрению и выполнению статического анализа ПО, а также исходные данные, необходимые для его выполнения. Настоящий стандарт устанавливает требования к методам статического анализа, инструментам анализа (статическим анализаторам) и к специалистам, участвующим в анализе. Настоящий стандарт устанавливает методику проверки устанавливаемых требований к инструментам анализа.
Настоящий стандарт входит в комплекс стандартов, направленных на достижение целей, связанных с предотвращением появления и/или устранением уязвимостей программ, содержит общие требования по проведению статического анализа ПО и применяется совместно с ГОСТ Р 56939.
1 Область применения
Настоящий стандарт описывает порядок внедрения и выполнения статического анализа, устанавливает требования к его выполнению, классификацию ошибок, находимых статическими анализаторами, а также требования к методам анализа, к инструментам статического анализа, к специалистам, участвующим в выполнении анализа, а также к методике проверки статических анализаторов на соответствие требованиям данного стандарта.
Настоящий стандарт предназначен:
- для разработчиков статических анализаторов;
- для разработчиков средств защиты информации, средств обеспечения безопасности информационных технологий;
- для разработчиков программного обеспечения (ПО).
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ 19.102 Единая система программной документации. Стадии разработки
ГОСТ 28397 (ИСО 2382-15-85) Языки программирования. Термины и определения
ГОСТ Р 50922 Защита информации. Основные термины и определения
ГОСТ Р 56939 Защита информации. Разработка безопасного программного обеспечения. Общие требования
ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины, определения и сокращения
3.1 В настоящем стандарте применены термины по ГОСТ Р 50922, ГОСТ 28397, а также следующие термины с соответствующими определениями:
3.1.1 анализ иерархии классов: Статический анализ, позволяющий выявить в программах на объектно-ориентированных языках список классов, реализованных в программе, а также отношения наследования между этими классами.
3.1.2 анализ косвенных вызовов: Статический анализ, позволяющий в программе, использующей вызовы по указателю или вызовы виртуальных методов, установить множество процедур, которые могут вызываться при выполнении заданного косвенного вызова.
Примечание - Анализ потока управления, анализ потока данных, анализ помеченных данных, анализ псевдонимов и анализ косвенных вызовов в общем случае дают приближенные результаты.
3.1.3 анализ помеченных данных: Статический анализ, при котором анализируется течение потока данных от источников до стоков.
Примечания
1 Под источниками понимаются точки программы, в которых данные начинают иметь пометку - некоторое заданное свойство. Под стоками понимаются точки программы, в которых данные перестают иметь пометку.
2 Распространенная цель анализа помеченных данных - показать, что помеченные данные не могут попасть из источников - точек ввода пользователя в стоки - процедуры записи на диск или в сеть. Факт такого попадания означает утечку конфиденциальных данных.
3.1.4 анализ потока данных: Статический анализ, при котором определяются свойства обрабатываемых программой данных.
Примечание - Могут определяться возможные значения переменных и констант, точки программы, в которых используются определенные переменные и пр.
3.1.5 анализ потока управления: Статический анализ, при котором выделяются процедуры программы, линейные участки кода процедур и условия переходов между этими участками.
3.1.6 анализ программы на синтаксическом уровне: Статический анализ, при котором обрабатывается представление программы, полностью отражающее ее синтаксическую структуру, например абстрактное синтаксическое дерево.
3.1.7 анализ псевдонимов: Статический анализ, позволяющий установить наличие в программе доступа к одной и той же переменной или функции с помощью различных ссылок (указателей).
3.1.8 внутреннее представление: Структуры данных или служебный язык, которые используются статическим анализатором для представления исходного кода программы в ходе анализа.
Примечание - Внутреннее представление может строиться как перед выполнением основного анализа в ходе отдельного, настраиваемого пользователем этапа контролируемой сборки ПО, так и вместе с выполнением статического анализа (например, когда используемый язык программирования не требует выполнения сборки).
3.1.9 императивный язык программирования: Язык программирования, в котором используется парадигма программирования, описывающая действия над данными в терминах последовательности команд.
3.1.10 индуктивная переменная: Переменная цикла программы, значение которой может быть выражено в виде функции от счетчика цикла или других индуктивных переменных.
Примечание - Индуктивные переменные, как правило, выражаются линейными функциями от счетчика цикла, изменяясь на каждой итерации цикла на фиксированное целое значение.
3.1.11
инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них.
[ГОСТ Р 51904-2002, пункт 3.17] |
3.1.12 контролируемая сборка ПО: Сборка ПО, при выполнении которой статическим анализатором фиксируются порядок запуска программных средств, их настройки и используемые конфигурации.
3.1.13 критическая ошибка в программе: Ошибка, которая может привести к нарушению безопасности обрабатываемой информации.
3.1.14 ложноотрицательное срабатывание (ошибка второго рода): Отсутствие предупреждения об ошибке со стороны статического анализатора в ситуации наличия заведомо известной ошибки в программе, которая способна реализоваться в ходе выполнения программы.
3.1.15 ложноположительное срабатывание (ошибка первого рода): Выданное статическим анализатором предупреждение, которое указывает на конструкцию или несколько конструкций в программе (возможно, в совокупности с некоторым множеством возможных значений переменных программы), не содержащих ошибку, которая может реализоваться в ходе выполнения программы.
3.1.16 межмодульные связи: Совокупность связей по управлению, когда код одного программного модуля передает управление другому модулю, и связей по данным, когда программные модули совместно используют какие-либо данные.
3.1.17 межмодульный анализ: Статический анализ, при котором выполняется совместный анализ программы или нескольких программ, состоящих из нескольких программных модулей, и выявляемые свойства программы затрагивают процедуры или переменные из различных модулей.
3.1.18 межпроцедурный контекстно-чувствительный анализ: Статический анализ, при котором выявляемые свойства программы учитывают взаимодействие нескольких процедур, в том числе - возникающее в результате выполнения нескольких процедур или вызовов процедурами друг друга, а также контексты их вызова.
Примечания
1 В ходе анализа учитывается контекст вызова процедуры при обработке ее вызова, т.е. сопоставляется информация из вызывающей и вызываемой процедур применительно к каждому месту вызова и его окружению: фактическим параметрам, состоянию глобальных переменных и т.п.
2 Термины 3.1.6, 3.1.17, 3.1.18, 3.1.28, 3.1.32, 3.1.36 определяют различные свойства методов анализа программ, которые могут применяться как при статическом анализе программ, так и для оптимизаций программы в ходе ее компиляции. В настоящем стандарте термины 3.1.6, 3.1.17, 3.1.18, 3.1.28, 3.1.32, 3.1.36 трактуются как свойства методов статического анализа. В свою очередь, термины 3.1.1-3.1.5, 3.1.7 описывают семейства видов анализа.
3.1.19 модельный вариант (ошибки): Подтип некоторого типа ошибки в программе, отнесение к которому осуществляется исходя из особенностей реализации ошибки данного типа и особенностей языка программирования.
Примечание - Разбиение типа ошибки на модельные варианты применяется из-за технологических ограничений статического анализа в целях эффективной работы статических анализаторов, сводя задачу поиска ошибки более общего типа к задаче поиска ошибок множества подтипов.
3.1.20 ошибка в программе: Конструкция или набор конструкций в исходном коде программы, наличие которой указывает на возможность реализации угроз безопасности информации и/или на ошибку реализованного в программе алгоритма.
Примечания
1 Ошибка в программе может быть уязвимостью программы, программной закладкой, ошибкой реализованного алгоритма, приводить к утечке конфиденциальных данных, отказу программного обеспечения и пр. В настоящем стандарте в задачи статического анализа не входит разграничение ошибок в части последствий, необходимо найти потенциальные места ошибок.
2 При анализе части программы (процедур) с неизвестным контекстом вызова ошибка может реализоваться в контексте, не содержащемся в известной анализатору части. В этом случае судить о ложности срабатывания можно лишь с учетом всей программы.
3.1.21 поточный вариант (ошибки): Способ выражения ошибки в исходном коде программы через конкретную структуру потоков управления и данных.
Примечание - Поточные варианты являются общими для всех типов ошибок, так как характеризуют не саму ошибку, а способ ее выражения в исходном коде программы (характерный вид потоков управления и данных).
3.1.22
программа: Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
[ГОСТ 19781-90, статья 1] |
3.1.23
программное обеспечение: Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
[ГОСТ 19781-90, статья 2] |
3.1.24 путь выполнения: Последовательность операторов программы или процедуры, которая выполняется при заданных входных данных или параметрах процедуры.
3.1.25 разработчик программного обеспечения: Организация, выполняющая работы на всех стадиях разработки программы или ответственная, как минимум, за такие процессы жизненного цикла, как процессы реализации и процессы поддержки программных средств.
Примечание - Стадии разработки - по ГОСТ 19.102, процессы жизненного цикла - по ГОСТ Р ИСО/МЭК 12207.
3.1.26 сборка ПО: Процесс построения из исходных модулей ПО программных модулей, готовых к выполнению или интерпретации, и/или библиотек.
3.1.27
сборочная среда: Совокупность программных и аппаратных средств, служб связи, интерфейсов, форматов данных, протоколов, стандартов, обеспечивающих преобразование исходного кода программ в программные пакеты в соответствии с представленными метаданными и с учетом зависимостей программного пакета.
[Адаптировано из ГОСТ Р 54593-2011, пункт 3.13] |
3.1.28 сигнатурный анализ: Статический анализ, определяющий наличие свойства программы при помощи поиска строк в исходном коде программы по некоторому образцу, в том числе заданному с помощью формального языка поиска, например при помощи регулярных выражений.
3.1.29 система непрерывной интеграции: Система, обеспечивающая автоматизированную сборку и тестирование ПО.
Примечание - Частые автоматизированные сборки ПО применяются для скорейшего выявления ошибок и решения проблем, возникающих при объединении изменений кода.
3.1.30 система сборки ПО: Совокупность программных средств и конфигурационных файлов, которая позволяет выполнить сборку ПО.
3.1.31 среда анализа ПО: Совокупность программных и аппаратных средств, служб связи, интерфейсов, форматов данных, протоколов, стандартов, обеспечивающих статический анализ программы.
3.1.32 статистический анализ: Статический анализ, определяющий статистику для некоторого свойства программы, например: насколько часто в программе проверяется возвращаемое значение некоторой функции.
3.1.33 статический анализ: Вид работ по инструментальному исследованию программы, основанный на анализе исходных кодов в режиме, не предусматривающем реального выполнения кода, и выполняемый для определения свойств программы.
Примечания
1 В профессиональной терминологии устоялось взаимозаменяемое применение терминов "анализ исходных текстов" и "анализ исходного кода".
2 В частности, статический анализ применяется для выявления ошибок в программе.
3.1.34 статический анализатор: Программное инструментальное средство, которое выполняет статический анализ в автоматическом режиме.
3.1.35 тип ошибки: Категория ошибок в программе, отражающая их общность в свойствах или характеристиках.
Примечание - Статические анализаторы снабжают предупреждения об ошибке диагностической информацией, в состав которой входит тип ошибки. Применяемая в статических анализаторах типизация разнится, что затрудняет соотнесение предупреждений, полученных от разных анализаторов. Для облегчения работы с предупреждениями в диагностическую информацию добавляют соотнесение ошибки с одной из популярных систем классификации дефектов безопасности, например с перечнем угроз БДУ ФСТЭК России или MITRE CWE.
3.1.36 чувствительный к путям выполнения анализ: Статический анализ программы, при котором могут быть определены ее свойства, проявляющиеся лишь на некоторых путях выполнения программы, и условия (или часть условий), при обращении которых в истину выполнение программы пойдет по указанному анализатором пути.
3.2 В настоящем стандарте применены следующие сокращения:
БДУ - банк данных угроз;
ЭВМ - электронная вычислительная машина;
CWE - общий перечень дефектов (недостатков) безопасности (Common Weakness Enumeration);
POSIX - набор стандартов, описывающих интерфейсы между операционной системой и прикладной программой (Portable Operating System Interface);
SARIF - формат обмена результатами статического анализа на основе JSON для вывода инструментов статического анализа (Static Analysis Results Interchange Format).
4 Общие положения
4.1 Предотвращение появления и устранение уязвимостей программы может быть достигнуто путем реализации разработчиком ПО мер по разработке безопасного ПО, представленных в ГОСТ Р 56939.
4.2 При создании безопасного ПО разработчик ПО выполняет статический анализ в соответствии с разделами 5-9 в дополнение к положениям ГОСТ Р 56939.
4.3 Меры по разработке безопасного ПО, представленные в настоящем стандарте, выражены в форме требования, рекомендации или допустимого действия, предназначенных для поддержки достижения результатов реализации мер. Для этой цели в настоящем стандарте используют соответствующие глаголы "должен" ("обязан"), "следует" и "может", отражающие различия в обязательности между разными формами требований к реализации мер. Глагол "должен" ("обязан") применяют для изложения требования, выполнение которого обязательно для соответствия, "следует" - для выражения рекомендации среди других возможностей, "может" - для того, чтобы отразить направление допустимых действий в пределах ограничений настоящего стандарта.
4.4 Для соответствия требованиям настоящего стандарта разработчик ПО должен использовать в ходе разработки статический анализатор или набор статических анализаторов для поиска ошибок. Выявление критических ошибок в программе способствует идентификации уязвимостей, их устранению или разработке компенсирующих мер.
4.5 Статический анализ в рамках жизненного цикла ПО проводят в соответствии с требованиями раздела 5.
4.6 Методы и инструменты статического анализа должны соответствовать требованиям разделов 6-8.
4.7 Требования, предъявляемые к специалистам, проводящим статический анализ, - согласно разделу 9.
4.8 Проверку соответствия статического анализатора требованиям разделов 6-8 проводят согласно методике, приведенной в разделе 10.
4.9 При отсутствии применимых инструментов статического анализа (отсутствует поддержка используемого языка программирования, не поддерживаются используемые средства сборки ПО и т.п.), отвечающих всем требованиям разделов 6-8, следует использовать в жизненном цикле ПО инструменты, наиболее полно выполняющие данные требования. Приоритет следует отдавать инструментам, демонстрирующим лучшие ключевые показатели в соответствии с 8.4.
5 Требования к внедрению и порядку выполнения статического анализа
5.1 Внедрение статического анализа ПО в организации - разработчике ПО состоит из следующих этапов:
а) подготовительный этап:
1) выбор инструмента статического анализа;
2) подготовка сборочной среды ПО (для ПО, требующего сборки) и среды анализа ПО;
б) начальный этап:
1) настройка инструмента статического анализа для данного ПО;
2) выполнение первичного статического анализа исходного кода ПО;
3) разметка полученных результатов и формирование начальной базы предупреждений о потенциальных ошибках;
в) проведение регулярного статического анализа ПО.
5.2 На подготовительном этапе проведения статического анализа ПО осуществляют выбор инструмента или набора инструментов статического анализа для регулярного проведения анализа всего кода ПО в рамках жизненного цикла ПО в соответствии с требованиями разделов 7 и 8. Для этого должен быть выполнен анализ документации ПО, а также анализ исходного кода ПО для определения языков программирования, на которых написано ПО, параметров среды функционирования ПО. Для ПО, требующего сборки (трансляций кода, компоновки и т.п.), должен быть выполнен анализ документации системы сборки, инструментов сборки ПО и параметров среды их функционирования (операционные системы, процессорные архитектуры).
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.