Статус документа
Статус документа

ГОСТ Р 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]

Доступ к полной версии документа ограничен
Этот документ или информация о нем доступны в системах «Техэксперт» и «Кодекс».
Нужен полный текст и статус документов ГОСТ, СНИП, СП?
Попробуйте «Техэксперт: Лаборатория. Инспекция. Сертификация» бесплатно
Реклама. Рекламодатель: Акционерное общество "Информационная компания "Кодекс". 2VtzqvQZoVs