Национальный стандарт РФ ГОСТ Р 56939-2024 "Защита информации. Разработка безопасного программного обеспечения. Общие требования" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 24 октября 2024 г. N 1504-ст) (документ не вступил в силу)

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

5.1.1.2 Подготовка и планирование внедрения и улучшения процессов разработки безопасного ПО.

5.1.1.3 Определение области применения процессов разработки безопасного ПО.

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

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

5.1.2.3 Разрабатывать план развития процессов разработки безопасного ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.1.3.1, 5.1.3.2.

5.1.2.4 Разрабатывать план реализации процессов разработки безопасного ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.1.3.1, 5.1.3.2.

5.1.2.5 Определять область применения процессов разработки безопасного ПО.

5.1.3.1 Результаты анализа текущего статуса реализации процессов разработки безопасного ПО должны содержать следующие сведения:

- перечень процессов разработки безопасного ПО, реализованных и не реализованных разработчиком;

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

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

5.1.3.3 План развития процессов разработки безопасного ПО должен содержать порядок (очередность) внедрения процессов разработки безопасного ПО с учетом приоритетов разработчика и имеющихся ресурсов, планируемые изменения в организационно-штатной структуре разработчика, планируемые закупки необходимых инструментов, затраты на обучение и др.

П р и м е ч а н и е - План развития процессов разработки безопасного ПО может разрабатываться и быть представлен в системе управления задачами.

5.1.3.4 План реализации процессов разработки безопасного ПО должен содержать цели, сроки и этапы внедрения процессов разработки безопасного ПО; перечень необходимых ресурсов; информацию об ответственных за внедрение процессов сотрудниках.

П р и м е ч а н и е - План реализации процессов разработки безопасного ПО может разрабатываться и быть представлен в системе управления задачами.

5.1.3.5 Описание области применения процессов разработки безопасного ПО должно содержать состав ПО (версии, модули, компоненты, функциональные подсистемы и т.п.), в отношении которого должны быть реализованы процессы разработки безопасного ПО, с обоснованием выбора указанного состава ПО.

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

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

5.2.1.3 Создание условий для снижения количества возможных типовых ошибок и уязвимостей в разрабатываемом ПО.

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

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

5.2.2.2 Разрабатывать план обучения с учетом потребностей разработчика в части используемых средств и технологий разработки.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.1.

5.2.2.3 Проводить обучение сотрудников.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.2.

5.2.2.4 Вести учет обучения сотрудников.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.2, 5.2.3.3, 5.2.3.6.

5.2.2.5 Определить критерии пересмотра программ обучения (курсов, тренингов и т.п.).

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.2.3.1.

5.2.3.1 Результаты анализа существующих (доступных для анализа) практик, документов, обучающих курсов и тренингов по разработке безопасного ПО с точки зрения их применимости для обучения сотрудников разработчика.

5.2.3.2 План обучения, включающий:

- список сотрудников, направляемых на обучение;

- сроки прохождения обучения;

- наименование программы (курса, тренинга) обучения;

- ожидаемый результат обучения.

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

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

5.2.3.5 Критерии необходимости пересмотра программ обучения (курсов, тренингов и т.п.) должны содержать информацию о периодичности пересмотра (уточнения) программ обучения (курсов, тренингов и т.п.) или о событиях, при наступлении которых необходимо изменение программ обучения (курсов, тренингов и т.п.).

5.2.3.6 Артефакты реализации требований, подтверждающие осуществление повышения осведомленности сотрудников, должны содержать информацию о проведенных мероприятиях по повышению осведомленности сотрудников о возможных типовых угрозах, ошибках и уязвимостях в разрабатываемом ПО, механизмах их недопущения или минимизации вероятности их возникновения, порядке сопровождения ПО и управления жизненным циклом, а также о сотрудниках (подразделениях), для которых проводились мероприятия по повышению осведомленности.

5.3.1.1 Обеспечение безопасности ПО посредством предъявления к нему требований и управления требованиями в процессе изменения (разработки) ПО.

5.3.2.1 Разработать регламент управления требованиями безопасности ПО.

5.3.2.2 Предъявлять к ПО требования безопасности.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.1.

5.3.2.3 Вести учет предъявленных требований безопасности и контроль однозначности трактования и непротиворечивости набора требований безопасности ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.2.

П р и м е ч а н и е - Критерии однозначности трактования и непротиворечивости набора требований безопасности ПО определяются разработчиком экспертным методом.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.1, 5.3.3.2.

5.3.3.1 Регламент управления требованиями безопасности ПО должен включать следующие положения:

- порядок предъявления требований безопасности ПО;

- порядок предоставления требований безопасности ПО исполнителям;

- порядок отслеживания процесса предоставления, получения и выполнения требований безопасности ПО;

- критерии пересмотра требований безопасности ПО (периодически, при наступлении определенных событий).

5.3.3.2 Набор требований безопасности ПО должен содержать следующую информацию:

- идентификатор требования безопасности ПО;

- формулировку требования безопасности ПО;

- дату предъявления требований безопасности ПО;

- приоритет/важность требования безопасности ПО;

- предполагаемые сроки реализации;

- сведения о сотрудниках (подразделениях), предъявивших требования;

- сведения о сотрудниках (подразделениях), принявших требования к реализации.

5.3.3.3 Артефакты реализации требований, подтверждающие осуществление учета предъявленных требований безопасности ПО, должны включать, как минимум, следующую информацию:

- сведения о принятии требований к реализации, подтверждающие однозначность трактования и непротиворечивость набора требований безопасности ПО;

- текущий статус реализации требований;

- сведения об изменениях статуса реализации предъявленных требований безопасности ПО;

- сведения об изменениях предъявленных требований безопасности ПО.

П р и м е ч а н и е - Управление требованиями безопасности ПО рекомендуется осуществлять с использованием средств автоматизации (например, системы управления изменениями, системы управления задачами и т.п.).

5.3.3.4 Набор требований безопасности ПО, уточненный по результатам выполнения требований 5.3.2.4, должен содержать информацию об особенностях реализации требований безопасности ПО в процессе разработки ПО, принятых решениях по корректировкам требований безопасности ПО в процессе разработки.

5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

5.4.2.1 Разработать регламент управления конфигурацией в рамках жизненного цикла ПО.

5.4.2.2 Определить перечень элементов конфигурации, подлежащих отслеживанию в рамках управления конфигурацией ПО.

5.4.2.3 Контролировать реализацию изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

5.4.3.1 Регламент управления конфигурацией ПО должен содержать:

- порядок формирования перечня элементов ПО (компонентов, модулей и т.п.), документации на ПО, подлежащих отслеживанию в рамках жизненного цикла ПО;

- порядок идентификации ПО (версий ПО, модулей ПО), документации для отслеживаемых элементов.

5.4.3.2 Перечень элементов конфигурации, подлежащих отслеживанию в рамках управления конфигурацией ПО.

5.4.3.3 Артефакты реализации требований, подтверждающие реализацию управления изменениями ПО, документации на ПО в рамках управления конфигурацией ПО, должны отображать факты изменения ПО (модулей ПО), документации на ПО.

5.5.1.1 Обеспечение управления недостатками ПО.

5.5.1.2 Обеспечение управления запросами на изменение ПО.

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

5.5.2.1 Разработать регламент управления недостатками ПО.

5.5.2.2 Разработать регламент управления запросами на изменение ПО.

5.5.2.3 Контролировать реализацию изменений, связанных с недостатками ПО.

5.5.2.4 Контролировать реализацию запросов на изменение в рамках жизненного цикла ПО.

5.5.2.5 Использовать средства автоматизации для управления недостатками и запросами на изменение разрабатываемого ПО.

П р и м е ч а н и е - В качестве средств автоматизации рекомендуется использовать системы управления изменениями, системы управления задачами, системы контроля версий и т.п. При этом рекомендуется обеспечивать взаимосвязь (перекрестные ссылки) между такими системами при исправлении недостатков.

5.5.3.1 Регламент управления недостатками ПО должен содержать:

- порядок идентификации недостатков ПО;

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

5.5.3.2 Регламент управления запросами на изменение ПО должен содержать:

- порядок идентификации запросов на изменение ПО;

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

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

- уникальный идентификатор недостатка ПО;

- описание недостатка ПО;

- версию ПО (модуля ПО, компонента ПО), к которому относится недостаток ПО;

- приоритет выполнения действий с недостатком ПО;

- текущий статус обработки изменений, связанных с недостатками ПО.

5.5.3.4 Артефакты реализации требований, подтверждающие реализации управления запросами на изменение ПО, должны содержать следующую информацию:

- уникальный идентификатор запроса на изменение ПО;

- краткую характеристику запроса на изменение ПО;

- версию ПО (модуля ПО, компонента ПО), к которому относится запрос на изменение;

- приоритет выполнения действий с запросом на изменение ПО;

- текущий статус обработки запроса на изменение ПО.

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.

5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.2.

5.6.2.2 Выполнить первичное проектирование архитектуры ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.1, 5.6.3.1.

5.6.2.3 Установить критерии необходимости уточнения архитектуры ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.6.3.3.

5.6.3.1 Требования к принципам проектирования архитектуры ПО должны содержать информацию, позволяющую на начальном этапе проектирования ПО получить представление о принятых подходах и принципах проектирования архитектуры ПО (например, инкапсуляция, уникальность, разделение задач, применение заимствованных компонентов и т.п.), в том числе с точки зрения безопасности ("нулевое доверие", "протоколирование событий", "резервное копирование", "формирование перечня недопустимых событий", "приоритетное использование языков с безопасной моделью памяти" и т.п.).

5.6.3.2 Описание архитектуры ПО должно включать, как минимум, следующую информацию:

- назначение ПО и сценарии его использования;

- описание среды функционирования;

- ограничения и указания по применению;

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

5.6.3.3 Критерии необходимости уточнения архитектуры ПО должны содержать информацию о периодичности пересмотра (уточнения) архитектуры ПО в процессе разработки ПО или о событиях, при наступлении которых необходимо уточнять архитектуру ПО.

5.6.3.4 Архитектура ПО, уточненная по результатам выполнения требований 5.6.2.4, должна содержать информацию об особенностях реализации ПО в процессе разработки ПО, принятых решениях по корректировкам архитектурных решений в процессе разработки, в том числе связанных с безопасностью, и причинах, их вызвавших.

5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.

5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.

5.7.2.1 Выполнить первичное моделирование угроз для ПО (разработать модель угроз ПО); для выявленных угроз безопасности информации составить перечень мер по их нейтрализации (снижению вероятности возникновения).

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.

5.7.2.2 Выполнить первичное описание поверхности атаки.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.

5.7.2.6 При уточнении описания поверхности атаки выполнять анализ поверхности атаки методом идентификации интерфейсов ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.

П р и м е ч а н и е - Используемые методы анализа сетевых интерфейсов способствуют получению информации об узлах сети, именах устройств, IP-адресах, операционных системах, запущенных программах и службах, именах пользователей, группах и открытых портах и могут включать анализ локальных и сетевых интерфейсов взаимодействия пользователя с ПО (модулями ПО, компонентами ПО) и взаимодействий модулей (компонентов) ПО между собой, средой функционирования и внешними объектами при их наличии.

5.7.2.7 Уточнять перечень целей (функциональных подсистем, модулей (компонентов) ПО и их интерфейсов) для проведения дальнейших исследований безопасности ПО (например, фаззинг-тестирования) с учетом уточненной архитектуры ПО, результатов моделирования угроз и выполнения анализа поверхности атаки для разработанного кода ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.7.3.1, 5.7.3.3, 5.7.3.4.

5.7.3.1 Модель угроз должна включать совокупность угроз безопасности, актуальных для разрабатываемого ПО.

Каждая угроза безопасности представляется в виде совокупности свойств (характеристик), включающей, как минимум, краткое описание угрозы, предполагаемый объект воздействия и возможные последствия реализации угрозы.

П р и м е ч а н и е - При составлении перечня угроз безопасности и их описания рекомендуется учитывать положения ГОСТ Р 58412, а также угрозы безопасности информации Банка данных угроз безопасности информации ФСТЭК России, других источников (например, методологии STRIDE, Open Web Application Security Project (OWASP), DREAD и пр.). В модели угроз рекомендуется указывать использованную при моделировании методологию, в том числе в случае ее собственной разработки.

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

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

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

5.7.3.5 Модель угроз, уточненная по результатам выполнения требований 5.7.2.4, должна дополнительно (в случае применимости) содержать угрозы безопасности ПО, актуальные для выполненных изменений.

5.7.3.6 Описание поверхности атаки, уточненное по результатам выполнения требований 5.7.2.5, должно включать перечень функциональных подсистем, модулей (компонентов) ПО и их интерфейсов, составляющих поверхность атаки, актуальных для разработанного кода ПО.

5.7.3.7 Перечень целей, уточненный по результатам выполнения требований 5.7.2.7, для проведения дальнейших исследований безопасности ПО должен содержать описание функциональных подсистем, модулей (компонентов) ПО, их интерфейсов, для которых предполагаются дальнейшие исследования в части безопасности при реализации других процессов разработки безопасного ПО.

5.8.1.1 Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.

5.8.2.1 Принять и использовать в процессе разработки кода ПО регламент оформления исходного кода и безопасного кодирования для используемых разработчиком языков программирования.

П р и м е ч а н и е - Под безопасным кодированием здесь и далее понимаются практики разработки ПО в соответствии с предъявляемыми в указанном выше регламенте требованиями по безопасности.

5.8.2.2 Учитывать при разработке регламента оформления исходного кода и безопасного кодирования примеры опасных и безопасных конструкций для используемых в ПО языков программирования.

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

5.8.2.4 При разработке ПО рекомендуется использовать программные средства автоматической проверки правил кодирования.

П р и м е ч а н и е - Допускается реализовывать проверку правил кодирования средствами компиляции или статического анализа.

5.8.3.1 Регламент оформления исходного кода и безопасного кодирования должен содержать:

- информацию о способах оформления исходного кода (например, способы выбора наименований переменных, функций, классов и т.п.; стиль отступов при оформлении логических блоков; способы ограничения логических блоков; правила использования пробелов при оформлении логических и арифметических выражений; стиль комментариев и правила документирования кода; ограничения [например, размер строк кода по горизонтали, строк в модуле и т.п.)];

- перечень запрещенных способов кодирования, конструкций и т.п. (например, указание паролей в исходном коде ПО в явном виде, использование "магических чисел" и т.п.);

- примеры опасных и безопасных конструкций для используемых языков программирования;

- область применения правил кодирования;

- порядок проверки выполнения правил кодирования для вносимых изменений в исходный код ПО;

- рекомендации разработчиков языков программирования по использованию стандартов кодирования (языков программирования, в том числе собственной разработки), принятые разработчиком ПО.

5.9.1.1 Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.

5.9.2.1 Разработать регламент проведения экспертизы исходного кода ПО.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.9.3.1.

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

5.9.3.1 Регламент проведения экспертизы исходного кода ПО должен содержать следующие сведения:

- обязанности сотрудников и их роли при проведении экспертизы исходного кода ПО;

- базовые требования к экспертизе (количество участников; области кода, подлежащего экспертизе; используемые инструменты и т.д.);

- описание основных проверок (например, сценариев, шаблонов, чек-листов) проведения экспертизы исходного кода ПО.

5.9.3.2 Результаты экспертизы кода должны содержать следующие сведения:

- информацию о проанализированных модулях (компонентах) ПО;

- перечень необходимых изменений;

- вопросы к частям кода, экспертиза которых затруднена и требует дополнительных разъяснений;

- предложения по улучшению.

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

5.10.2.1 Разработать регламент проведения статического анализа исходного кода ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2.

5.10.2.2 Определить инструменты статического анализа для каждого используемого в ПО языка программирования.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.10.3.1.

5.10.2.3 Определить конфигурацию и параметры настройки инструментов статического анализа.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2.

5.10.2.4 Проводить статический анализ с использованием инструментов статического анализа с регистрацией всех предупреждений о потенциальных ошибках, полученных по результатам работы инструментов статического анализа.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2, 5.10.3.3.

5.10.2.5 Осуществлять пересмотр конфигурации и параметров настройки инструментов статического анализа при выполнении установленных событий (изменениях в правилах сборки, применяемых статических анализаторах, получении информации об уязвимостях и т.п.).

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2, 5.10.3.3.

5.10.2.6 Осуществлять повторный статический анализ ПО после устранения ранее выявленных ошибок и уязвимостей; внесения изменений в ходе разработки в исходные тексты ПО; изменения используемых версий компиляторов, сред выполнения (для компилируемого в промежуточное представление или интерпретируемого кода), обновлений используемых инструментов статического анализа.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.10.3.1, 5.10.3.2.

5.10.3.1 Регламент проведения статического анализа исходного кода ПО должен содержать следующие сведения:

- обязанности сотрудников и их роли при проведении статического анализа;

- критерии выбора инструментов статического анализа;

- критерии выбора ПО (модулей ПО, компонентов ПО, функциональных подсистем ПО), подлежащих проведению статического анализа;

- правила обработки срабатываний средств статического анализа;

- типы и критичность ошибок (уязвимостей), выявляемых статическим анализатором, подлежащих устранению, и приоритеты устранения ошибок (уязвимостей);

- периодичность проведения статического анализа или события, при наступлении которых необходимо выполнять повторный статический анализ;

- критерии пересмотра конфигурации и параметров настройки инструментов статического анализа.

5.10.3.2 Перечень инструментов статического анализа должен включать наименования инструментов статического анализа, их версии и информацию о соответствии используемым языкам программирования.

5.10.3.3 Конфигурации и параметры настройки инструментов статического анализа должны обеспечивать выполнение требований регламента проведения статического анализа в части выявления типов и критичности ошибок (уязвимостей), периодичности проведения статического анализа или событий, при наступлении которых необходимо выполнять повторный статический анализ.

5.10.3.4 Отчеты по результатам проведения статического анализа должны включать:

- срабатывания инструментов статического анализа;

- результаты анализа (разметки) выявленных ошибок (срабатываний статического анализатора).

5.10.3.5 Конфигурации и параметры настройки инструментов статического анализа, уточненные по результатам выполнения требований 5.10.2.5, должны обеспечивать выполнение требований регламента проведения статического анализа в части выполнения критериев их пересмотра.

5.11.1.1 Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.

5.11.2.1 Разработать регламент проведения динамического анализа кода ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3.

5.11.2.2 Определить инструменты динамического анализа и фаззинг-тестирования, порядок их применения.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1.

5.11.2.3 Определить перечень модулей (компонентов) ПО, которые необходимо подвергнуть динамическому анализу, включая фаззинг-тестирование.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1, 5.11.3.2.

5.11.2.4 Определить сценарии проведения тестирования для каждого исследуемого модуля (компонента) ПО средствами динамического анализа, включая инструменты проведения фаззинг-тестирования.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1, 5.11.3.2, 5.11.3.3.

5.11.2.5 Проводить динамический анализ с использованием инструментов динамического анализа.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.

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

5.11.2.6 Проводить повторный динамический анализ модулей (компонентов) ПО с целью контроля устранения ошибок.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.

5.11.2.7 Проводить фаззинг-тестирование.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.

5.11.2.8 При проведении фаззинг-тестирования использовать тестовые коллекции входных данных, подлежащие дальнейшим мутациям, для каждого из подвергаемых фаззинг-тестированию модуля (компонента) ПО (при использовании инструментов выполнения фаззинг-тестирования, использующих коллекции входных данных), вызывающие использование различных функциональных возможностей тестируемого модуля (компонента) ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.2, 5.7.3.1, 5.7.3.3, 5.7.3.4, 5.11.3.1, 5.11.3.2, 5.11.3.3, 5.11.3.4.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.11.3.1, 5.11.3.5, 5.11.3.6.

5.11.3.1 Регламент проведения динамического анализа кода ПО должен содержать следующие сведения:

- обязанности сотрудников и их роли при проведении динамического анализа и фаззинг-тестирования;

- критерии выбора инструментов динамического анализа, включая инструменты проведения фаззинг-тестирования;

- критерии выбора методов и способов динамического анализа;

- критерии выбора модулей (компонентов) ПО, которые необходимо подвергнуть динамическому анализу, включая фаззинг-тестирование;

- правила обработки срабатываний средств динамического анализа, требующих обработки (аварийная остановка, зависание и т.п.);

- процедуры устранения найденных средствами динамического анализа ошибок;

- периодичность проведения динамического анализа или события, при наступлении которых необходимо выполнять повторный динамический анализ (критерии проведения повторного динамического анализа);

- периодичность проведения фаззинг-тестирования и критерии его завершения.

5.11.3.2 Перечень инструментов динамического анализа, включая инструменты проведения фаззинг-тестирования, должен включать:

- наименования инструментов динамического анализа, их версии и их соответствие исследуемым модулям (компонентам) ПО;

- параметры эксплуатации инструментов динамического анализа (для платформ, языков программирования и т.п.).

5.11.3.3 Перечень модулей (компонентов) ПО, которые необходимо подвергнуть динамическому анализу, включая фаззинг-тестирование, отвечающий требованиям регламента проведения динамического анализа, должен включать:

- наименование модуля (компонента) ПО;

- идентификатор модуля (компонента) ПО.

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

- идентификатор модуля (компонента) ПО;

- наименование используемого инструмента;

- параметры настройки инструмента;

- критерии запуска и остановки тестирования.

5.11.3.5 Отчеты по результатам проведения динамического анализа должны включать:

- срабатывания инструментов динамического анализа;

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

5.11.3.6 Отчеты по результатам проведения фаззинг-тестирования должны включать:

- сведения о результатах работы инструментов фаззинг-тестирования (длительность проведения фаззинг-тестирования, количество аварийных завершений работы ПО, количество найденных путей выполнения и др.);

- результаты анализа (обработки) аварийных завершений работы ПО, выявленных при проведении фаззинг-тестирования.

5.12.1.1 Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, обусловленных небезопасными преобразованиями кода.

5.12.2.1 Разработать регламент использования системы безопасной сборки ПО.

5.12.2.2 Для разрабатываемого ПО должна быть зафиксирована информация о системе сборки ПО и сборочной среде.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.12.3.1.

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

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

5.12.3.1 Регламент использования системы безопасной сборки ПО должен содержать, как минимум, следующие сведения:

- обязанности сотрудников и их роли при выполнении сборки ПО;

- критерии выбора инструментов сборки ПО;

- критерии приемки результатов сборки;

- порядок регистрации событий, генерируемых инструментами сборки ПО.

5.12.3.2 Информация о сборочной среде должна содержать:

- описание особенностей функционирования сборочной среды;

- перечень программных инструментов, применяемых в системе сборки ПО, их версий и конфигураций.

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

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

5.13.2.1 Разработать регламент обеспечения безопасности сборочной среды.

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

5.13.2.3 Разработать схему сборочной среды.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.13.3.2.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.13.3.1, 5.13.3.2.

5.13.2.5 Обеспечивать хранение результатов сборки ПО в выделенном хранилище - хранилище результатов сборки ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.13.3.1, 5.13.3.2.

5.13.2.6 Обеспечивать повторяемость сборки ПО (если применимо).

П р и м е ч а н и е - Под повторяемостью сборки имеется в виду обеспечение предсказуемости результатов сборок, обеспечение полного бинарного соответствия результатов повторных сборок не требуется.

5.13.2.7 Обеспечивать управление доступом к среде сборки ПО и хранилищу результатов сборки ПО на основе ролей пользователей.

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

5.13.3.1 Регламент обеспечения безопасности сборочной среды должен содержать, как минимум, следующие сведения:

- обязанности сотрудников и их роли при проведении сборок ПО;

- порядок регистрации событий безопасности при реализации сборок ПО в журналах аудита;

- сроки хранения журналов аудита;

- описание мер безопасности, необходимых для реализации в сборочной среде.

5.13.3.2 Информация о безопасности сборочной среды должна содержать:

- описание ожидаемых результатов сборки ПО;

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

5.13.3.3 Схематическое изображение сборочной среды должно содержать:

- элементы сборочной среды (серверы, узлы, виртуальные узлы, элементы среды контейнеризации и т.п.);

- связи между элементами сборочной среды, позволяющие отследить порядок (очередность) выполнения сборочных действий;

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

П р и м е ч а н и е - При изображении сборочной среды в графическом виде рекомендуется использовать стандартизированные графические нотации (UML, IDEF, С4 и т.п.).

5.13.3.4 Журналы аудита процессов сборки ПО должны содержать следующую информацию:

- дату и время начала и завершения сборки ПО;

- информацию о версии собираемого ПО (модуля ПО, компонента ПО);

- информацию об используемой конфигурации сборки ПО;

- информацию о шагах сборки ПО;

- информацию о событиях безопасности в соответствии с регламентом обеспечения безопасности сборочной среды.

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

П р и м е ч а н и е - При разработке и реализации регламента доступа к исходному коду ПО рекомендуется руководствоваться принципами минимизации привилегий и разделения полномочий.

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

5.14.1.1 Обеспечение управления доступом к исходному коду и его целостности.

5.14.2.1 Разработать регламент доступа к исходному коду ПО и обеспечения его целостности.

П р и м е ч а н и е - При разработке и реализации регламента доступа к исходному коду ПО рекомендуется руководствоваться принципами минимизации привилегий и разделения полномочий.

5.14.2.2 Осуществлять управление доступом к исходному коду ПО на основе выбранной модели управления доступом.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.14.3.1.

5.14.2.3 Осуществлять контроль целостности собственного исходного кода.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.14.3.1, 5.14.3.2.

5.14.3.1 Регламент доступа к исходному коду ПО и обеспечения его целостности должен содержать следующие сведения:

- обязанности сотрудников, их права и роли при разработке ПО;

- правила хранения исходного кода ПО, включая правила резервного копирования исходного кода ПО;

- правила внесения изменений (модификации, добавления, удаления) в исходный код ПО;

- критерии выбора способов и инструментов контроля целостности ПО;

- критерии выбора модулей (компонентов) ПО, подлежащих контролю целостности;

- описание процедуры контроля целостности исходного кода ПО.

5.14.3.2 Описание модели управления доступом к исходному коду ПО должно включать:

- перечень сотрудников, их права и обязанности при разработке ПО;

- описание выбранной модели управления доступом и используемых инструментов управления доступом.

5.14.3.3 Результаты выполнения контроля целостности собственного исходного кода должны обеспечивать соответствие требованиям регламента доступа к исходному коду ПО и обеспечения его целостности и позволять сделать однозначный вывод о целостности собственного исходного кода.

5.15.1.1 Обеспечение безопасного использования секретов.

П р и м е ч а н и е - В данном подразделе под секретами понимаются данные в любом виде, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т.п.), в том числе путем применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.

5.15.2.1 Разрабатывать регламент использования секретов.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.

5.15.2.2 Использовать секреты.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.15.3.1.

5.15.2.3 Проверять код и конфигурационные файлы ПО на предмет включения секретов для вносимых изменений в ПО.

П р и м е ч а н и е - Допускается реализовывать проверку безопасности используемых секретов средствами статического или композиционного анализа.

5.15.2.4 Для хранения, управления и предоставления секретов использовать систему управления секретами.

5.15.3.1 Регламент использования секретов может содержать следующие сведения:

- обязанности сотрудников и их роли при использовании секретов;

- основные принципы использования секретов;

- зоны ответственности подразделений и сотрудников в части использования секретов;

- порядок предоставления доступа к секретам;

- типы секретов, сроки их эксплуатации, действия при компрометации;

- порядок формирования и хранения секретов;

- порядок ротации секретов;

- требования к системам хранения секретов.

5.15.3.2 Описание реализации процедуры использования секретов может включать следующие сведения:

- порядок подписи исполняемого кода ПО (например, с использованием цифровых сертификатов);

- порядок подписи исходного кода (например, с использованием цифровых сертификатов).

5.16.1.1 Создание условий для снижения рисков наследования уязвимостей и недекларированных возможностей при использовании заимствованного кода в коде ПО разработчика.

5.16.2.1 Разработать регламент композиционного анализа.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.

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

5.16.2.2 Формировать перечень зависимостей ПО.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.16.3.1.

5.16.2.3 Контролировать и актуализировать перечень зависимостей ПО в соответствии с регламентом композиционного анализа на предмет наличия известных уязвимостей.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.16.3.1, 5.16.3.2.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.16.3.1, 5.16.3.2.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.16.3.1, 5.16.3.2, 5.16.3.3, 5.16.3.4, 5.16.3.5.

5.16.3.1 Регламент композиционного анализа должен содержать следующие сведения:

- обязанности сотрудников и их роли при проведении композиционного анализа;

- правила отслеживания уязвимостей для заимствованных компонентов, участвующих в сборке ПО;

- правила проведения анализа заимствованных компонентов на предмет наличия известных уязвимостей;

- правила принятия компенсирующих и защитных мер по противодействию выявленным угрозам безопасности в цепочке поставки сторонних компонентов;

- периодичность проведения композиционного анализа в соответствии с установленными практиками сборки ПО.

5.16.3.2 Перечень зависимостей ПО должен включать следующие сведения:

- перечень модулей (компонентов) заимствованного ПО с указанием их версий;

- источник (поставщик) модулей (компонентов) заимствованного ПО.

5.16.3.3 Результаты контроля актуальности перечня зависимостей ПО должны включать следующие сведения:

- описание процедуры контроля перечня зависимостей ПО и его актуализации;

- описание инструментов контроля актуальности перечня зависимостей ПО;

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

5.16.3.4 Результаты анализа заимствованных компонентов должны содержать следующие сведения:

- сведения о наличии/отсутствии известных уязвимостей в заимствованных компонентах;

- сведения о критичности выявленных уязвимостей в заимствованных компонентах.

5.16.3.5 Результаты применения корректирующих воздействий по устранению уязвимостей в зависимостях ПО могут содержать:

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

5.17.2.1 Осуществлять контроль зависящих от сторонних поставщиков элементов разработки (процессов; компонентов инфраструктуры разработки ПО, зависящих от сторонних поставщиков; компонентов, являющихся частью разрабатываемого ПО, которые поставляются или заимствуются от сторонних поставщиков).

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.12.3.2, 5.16.3.2.

5.17.2.2 Осуществлять контроль договорных обязательств со сторонними поставщиками.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.17.3.1.

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

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.17.3.1.

П р и м е ч а н и е - Результаты выявления указанных элементов инфраструктуры разработчика рекомендуется использовать для дальнейшего принятия мер для нейтрализации потенциальных угроз безопасности.

5.17.2.4 Осуществлять контроль использования предсобранного поставщиком ПО (кода, для которого отсутствуют исходные тексты).

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1.

5.17.2.5 Осуществлять анализ кода ПО, полученного через цепочки поставок, на предмет внедрения вредоносного программного обеспечения.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.17.3.1, 5.17.3.3.

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

- описание внутренних процессов, зависящих от сторонних поставщиков;

- описание компонентов инфраструктуры разработки ПО, зависящих от сторонних поставщиков;

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

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

- перечень поставщиков с указанием поставляемых продуктов (услуг);

- сведения о заключенных договорах со сторонними поставщиками, включающие информацию о поставляемых продуктах (услугах), сроках начала и окончания договоров, иную информацию.

5.17.3.3 Сведения о критичных и вероятных с точки зрения внедрения недекларированных возможностей элементах инфраструктуры (компонентах инфраструктуры разработки ПО, зависящих от сторонних поставщиков) должны содержать следующую информацию:

- перечень элементов инфраструктуры разработчика, воздействие на которые может повлиять на возникновение недекларированных возможностей в ПО;

- информацию о поставщиках продуктов (услуг) для указанных в перечне элементов инфраструктуры разработчика.

5.17.3.4 Результаты контроля использования предсобранного поставщиком ПО должны содержать информацию, позволяющую определить наличие предсобранных поставщиком ПО компонентов и осуществить их идентификацию (по свойствам файлов, контрольным суммам файлов и т.п.).

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

5.18.1.1 Контроль полноты реализованных функциональных возможностей, обнаружение и исправление ошибок с использованием технологий функционального тестирования.

5.18.2.1 Разработать план функционального тестирования.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.3.3.2, 5.6.3.1, 5.7.3.1, 5.7.3.3.

5.18.2.2 Проводить функциональное тестирование, по результатам тестирования разрабатывать отчеты о выполненном функциональном тестировании.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.18.3.1.

5.18.2.3 При проведении функционального тестирования выполнять тестирование на уровне модулей (компонентов), подсистем, всего ПО в целом.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.18.3.1.

5.18.2.4 Регистрировать ход проведения тестирования.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.18.3.1.

5.18.2.5 Организовывать процесс исправления выявленных в ходе тестирования ошибок с использованием системы управления ошибками.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.18.3.2, 5.18.3.3.

5.18.3.1 План функционального тестирования должен содержать следующие сведения:

- обязанности сотрудников и их роли при проведении функционального тестирования;

- описание тестового стенда (тестовой среды);

- описание сценариев тестирования для каждой функциональной возможности ПО, включающее формулировку функциональных требований, выполняемые действия по оценке, ожидаемые результаты тестирования и критерии успешного прохождения проверок;

- критерии выполнения повторного тестирования;

- критерии завершения и остановки тестирования.

5.18.3.2 Отчет по результатам функционального тестирования должен содержать, как минимум, следующую информацию:

- описание тестируемого ПО (версии ПО/модулей (компонентов) ПО, номера (идентификаторы) сборок ПО/модулей (компонентов) ПО, системные требования к тестируемому ПО) и его среды функционирования для каждого выполненного сценария тестирования;

- перечень выполненных сценариев тестирования и последовательность их выполнения;

- перечень выполненных действий и ограничений (описание отдельных аспектов, которые не проверялись);

- описание полученных результатов, перечень обнаруженных и исправленных ошибок;

- выводы по результатам тестирования.

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

5.18.3.3 Журналы функционального тестирования должны содержать, как минимум, следующую регистрационную информацию:

- дату и время выполнения тестовых операций (запуск и завершение сценария тестирования);

- результат выполнения сценария тестирования;

- изменения тестируемого ПО (состава и содержания модулей ПО, компонентов ПО, функциональных подсистем ПО и т.п.);

- возникновение любых сбоев и ошибок.

5.18.3.4 Сведения системы управления ошибками должны содержать, как минимум, регистрационную информацию о выявленных ошибках:

- дату и время тестирования, при котором была выявлена ошибка;

- тестовый сценарий;

- идентификационную информацию о модуле (компоненте) ПО, в котором выявлена ошибка;

- категорию ошибки;

- принятое решение;

- информацию о подтверждении факта наличия ошибки от разработчика;

- информацию об исправлении ошибки.

5.19.1.1 Подтверждение того, что поверхность атаки, модель угроз и архитектура ПО содержат необходимую информацию.

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

5.19.2.1 Проводить нефункциональное тестирование в отношении ПО (модулей ПО, компонентов ПО) в объемах, определяемых разработчиком.

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

- сетевых взаимодействий ПО;

- локальных интерфейсов взаимодействия ПО;

- производительности функционирования ПО;

- операций, выполняемых с высокими привилегиями;

- работы с конфиденциальными данными;

- корректности выполнения файловых операций;

- реализации защищенности бинарных файлов;

- реализации системы управления секретами;

- реализации безопасности сетевых протоколов;

- работы системы развертывания продукта;

- реализации мер по устранению или снижению критичности угроз, выявленных при моделировании угроз;

- возможности нарушения логики работы программы;

- безопасности реализации механизмов аутентификации и авторизации;

- безопасности обработки данных, полученных от потенциального нарушителя;

- безопасности реализации клиентской и серверной частей ПО.

5.19.2.2 Разработать регламент нефункционального тестирования.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.

5.19.2.3 Проводить нефункциональное тестирование с целью выявления локальных и сетевых интерфейсов взаимодействия с ПО (модулями ПО, компонентами ПО) пользователя и взаимодействий модулей (компонентов) ПО между собой, средой функционирования и внешними объектами.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.19.3.1.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.19.3.1.

5.19.2.5 Осуществлять корректировку описания поверхности атаки, модели угроз и архитектуры ПО по результатам выполнения нефункционального тестирования.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3, 5.19.3.2, 5.19.3.3.

5.19.3.1 Регламент нефункционального тестирования должен содержать следующие сведения:

- критерии выбора версий ПО (модулей ПО, компонентов ПО), подлежащих нефункциональному тестированию, и определения периодичности тестирования;

- перечень используемых для нефункционального тестирования методов и средств;

- обязанности сотрудников и их роли при проведении нефункционального тестирования;

- описание типовых сценариев тестирования;

- описание возможностей и мотивации потенциального нарушителя в соответствии с результатами моделирования угроз разрабатываемого ПО;

- описание типовых сценариев проведения компьютерных атак для основных сценариев работы ПО (модулей ПО, компонентов ПО).

5.19.3.2 Отчет по результатам нефункционального тестирования должен содержать следующую информацию:

- краткое описание тестируемого ПО и его инфраструктуры развертывания;

- описание выполненных сценариев тестирования и последовательности их выполнения;

- набор целей (модулей ПО, компонентов ПО) тестирования;

- перечень выполненных действий и ограничений (описание отдельных аспектов, которые не проверялись);

- результаты нефункционального тестирования (снимки экрана (скриншоты), рабочие файлы инструментов нефункционального тестирования и т.п.);

- выводы, включающие следующую информацию: найденные недостатки (уязвимости) программ, средства и методы их выявления, результаты оценки опасности уязвимостей, описание возможных последствий эксплуатации уязвимостей, рекомендации по устранению найденных уязвимостей.

5.19.3.3 Результаты сравнения архитектуры ПО, модели угроз и описания поверхности атаки с полученными фактическими результатами, перечень необходимых изменений в указанных артефактах реализации требований (при необходимости).

5.20.1.1 Организация приемки ПО с целью недопущения недостатков кода ПО перед его предоставлением пользователям.

5.20.2.1 Разработать регламент приемки ПО.

5.20.2.2 Осуществлять анализ степени влияния на безопасность ПО неустраненных ошибок. Информация о неустраненных ошибках выпускаемого ПО должна быть зафиксирована (например, в системе управления изменениями, системе отслеживания ошибок и т.п.).

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.9.3.2, 5.20.3.1, 5.10.3.4, 5.11.3.5, 5.16.3.5, 5.18.3.2.

5.20.2.3 Разработать регламент обеспечения целостности ПО, передаваемого пользователям.

5.20.2.4 Обеспечивать возможность проверки пользователями целостности ПО.

5.20.3.1 Регламент приемки ПО должен содержать следующие сведения:

- обязанности сотрудников и их роли при проведении приемки ПО;

- описание типовых сценариев приемки ПО перед предоставлением его пользователям.

5.20.3.2 Результаты анализа влияния на безопасность ПО неустраненных ошибок должны включать следующие сведения:

- перечень выявленных несоответствий;

- принятые решения по устранению несоответствий;

- принятые решения по результатам анализа о влиянии на безопасность ПО неустраненных ошибок.

5.20.3.3 Регламент обеспечения целостности ПО, передаваемого пользователям, должен содержать:

- перечень мер, реализуемых разработчиком ПО с целью обеспечения возможности проверки целостности ПО пользователями;

- порядок применения мер по обеспечению возможности проверки целостности ПО пользователями;

- порядок информирования пользователей ПО о механизмах проверки целостности ПО.

5.20.3.4 Результаты проверки выполнения мер по обеспечению целостности ПО.

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

5.21.2.1 Разработать регламент безопасной поставки ПО пользователям.

5.21.2.2 Фиксировать версии поставляемого пользователям ПО и соответствующей поставляемой документации.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.21.3.1.

5.21.2.3 Организовать хранение копий версий поставляемого пользователям ПО и соответствующей поставляемой документации.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.21.3.1.

5.21.2.4 Поставлять ПО вместе с эксплуатационной документацией, содержащей, как минимум, описание штатного функционирования ПО, параметров настроек (конфигураций) ПО и среды функционирования, действий по установке и настройке средства, как с точки зрения штатного функционирования, так и с точки зрения обеспечения безопасности.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.21.3.1.

5.21.3.1 Регламент безопасной поставки ПО пользователям должен содержать следующие сведения:

- обязанности сотрудников и их роли при осуществлении безопасной доставки ПО;

- процедуры хранения копий версий поставляемого пользователям ПО;

- процедуры снятия копий (тиражирования) поставляемого пользователям ПО;

- процедуры поставки ПО (обновлений ПО, включая обновления безопасности, предназначенных для устранения недостатков, в том числе уязвимостей);

- процедуры проверки подлинности ПО (обновлений ПО) пользователем.

5.21.3.2 Сведения о версии поставляемого пользователям ПО должны быть зафиксированы в поставляемой документации (в электронном виде или на физическом носителе).

5.21.3.3 Сведения о месте хранения копий (подлинников, дубликатов) версий поставляемого пользователям ПО (инсталляционных пакетов, дистрибутивных носителей) должны быть зафиксированы в документации (в электронном виде или на физическом носителе), например в регламенте безопасной поставки ПО.

5.21.3.4 Сведения о поставляемой эксплуатационной документации на ПО должны быть зафиксированы (в электронном виде или на физическом носителе), например в регламенте безопасной поставки ПО, в паспорте (формуляре) ПО.

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

5.22.2.1 Разработать регламент технической поддержки.

5.22.2.2 Организовать работу службы технической поддержки.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.22.3.1.

5.22.2.3 Разработать процедуру оповещения пользователей о выпуске обновлений (включая обновления безопасности) и необходимости их установки.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.22.3.1.

5.22.2.4 Организовывать обучение специалистов службы технической поддержки работе с поставляемым ПО, особенностям его установки и функционирования, ограничениям и указаниям по эксплуатации.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.22.3.1.

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

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.22.3.1.

5.22.3.1 Регламент технической поддержки должен содержать следующие сведения:

- обязанности сотрудников и их роли при оказании технической поддержки;

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

- используемые инструменты;

- описание процедуры взаимодействия службы технической поддержки с пользователями (способы получения обращений пользователей, процесс обработки поступающих сообщений и др.);

- описание процедур оповещения пользователей о выпуске обновлений (включая обновления безопасности) и необходимости их установки;

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

- информацию об обучении сотрудников службы технической поддержки.

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

5.22.3.3 Артефакты реализации требований, подтверждающие наличие внедренных процессов оповещения пользователей, должны содержать информацию об используемых каналах взаимодействия с пользователями при выпуске обновлений (включая обновления безопасности) и необходимости их установки.

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

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

5.23.1.1 Обеспечение выявления и устранения уязвимостей при эксплуатации ПО.

5.23.2.1 Разработать регламент реагирования на информацию об уязвимостях.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.

5.23.2.2 Осуществлять обработку поступающих запросов от пользователей (через службу технической поддержки, по иным каналам взаимодействия) с последующим анализом ошибок функционирования на предмет наличия уязвимостей (в случае получения таких запросов).

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.23.3.1.

5.23.2.3 При обработке поступающих запросов и при последующем анализе использовать средства автоматизации (например, систему управления изменениями, систему отслеживания ошибок, систему управления задачами и т.п.).

5.23.2.4 Осуществлять анализ информации о найденных уязвимостях в ПО на предмет подтверждения наличия/отсутствия уязвимостей и принимать решение о необходимости их устранения по результатам оценки.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.23.3.2.

5.23.2.5 Осуществлять оценку актуальности и критичности уязвимости с точки зрения безопасности ПО (в случае получения информации об уязвимости ПО из внешнего источника) и принимать решение о необходимости ее устранения по результатам оценки.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.23.3.3.

5.23.3.1 Регламент реагирования на информацию об уязвимостях должен содержать:

- обязанности сотрудников и их роли при реагировании на информацию об уязвимостях ПО;

- правила реагирования на информацию об уязвимостях;

- правила оценки актуальности и критичности уязвимости с точки зрения безопасности ПО;

- периодичность проведения поиска известных (подтвержденных) уязвимостей в общедоступных источниках информации об уязвимостях ПО.

5.23.3.2 Артефакты реализации требований, подтверждающие получение и обработку запросов от пользователей, должны содержать следующие сведения:

- информацию о запросах пользователей об ошибках (уязвимостях) ПО (дата, время запроса, идентификатор пользователя, статус запроса);

- результат анализа ошибок функционирования на предмет наличия уязвимостей.

5.23.3.3 Артефакты реализации требований, подтверждающие выполнение анализа информации о найденных уязвимостях в ПО, должны содержать следующие сведения:

- информацию о результатах тестирования ПО на предмет применимости информации об уязвимости ПО;

- проект (шаблон) ответа пользователям на запросы пользователей об ошибках (уязвимостях) ПО (о применимости информации о найденных уязвимостях);

- решение по результатам анализа информации о найденных уязвимостях в ПО.

5.23.3.4 Артефакты реализации требований, подтверждающие выполнение оценки актуальности и критичности уязвимости с точки зрения безопасности, должны содержать следующие сведения:

- информацию об оценке актуальности уязвимости;

- информацию об оценке уровня критичности уязвимости ПО;

- решение по результатам анализа актуальности и критичности уязвимости.

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

5.24.2.1 Разработать регламент поиска ошибок и уязвимостей в ПО при его эксплуатации.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.6.3.1, 5.7.3.1, 5.7.3.3.

5.24.2.2 Актуализировать информацию об уязвимостях ПО из открытых источников на регулярной основе на всем протяжении срока действия его технической поддержки: выполнять поиск в открытых источниках информации об уязвимостях самого ПО и его сторонних компонентов.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.16.3.2, 5.24.3.1.

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

5.24.2.3 Проводить проверки кода ПО и настроек конфигураций ПО на регулярной основе на всем протяжении срока действия его технической поддержки с целью поиска ошибок и уязвимостей.

Артефакты реализации требований, учитываемые при выполнении требования, представлены в 5.24.3.1.

П р и м е ч а н и я

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

2 Проверки кода ПО и настроек конфигураций ПО при его эксплуатации могут выполняться как собственными силами разработчика, так и с привлечением сторонних организаций и исследователей, в том числе в рамках публичных программ поиска уязвимостей за вознаграждение (программ багбаунти).

5.24.2.4 Оценивать выявленные ошибки на предмет наличия уязвимостей.

5.24.3.1 Регламент поиска ошибок и уязвимостей в эксплуатирующемся ПО должен содержать:

- обязанности сотрудников и их роли при поиске ошибок и уязвимостей в эксплуатирующемся ПО;

- правила поиска известных (подтвержденных) уязвимостей в общедоступных источниках информации об уязвимостях ПО, его программных компонентов и сред его функционирования;

- состав проводимых проверок и периодичность их проведения на протяжении всего срока действия технической поддержки ПО для каждой версии ПО.

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

5.25.1.1 Недопущение реализации угроз безопасности, связанных с эксплуатацией неподдерживаемой версии ПО.

5.25.2.1 Разработать регламент вывода ПО из эксплуатации.

5.25.2.2 Информировать пользователя о планах прекращения технической поддержки ПО (версии ПО) и своевременно уведомлять об этом.

5.25.3.1 Регламент вывода ПО из эксплуатации должен содержать описание условий, при которых ПО (версию ПО) необходимо выводить из эксплуатации, обязанности сотрудников и их роли при осуществлении вывода ПО из эксплуатации ПО и порядок оповещения пользователей о планах прекращения технической поддержки ПО (версии ПО).