ГОСТ Р 56939—2016
П р и м е ч а н и е — Уязвимость программы может быть результатом ее разработки без учета требований по
обеспечению безопасности информации или результатом наличия ошибок проектирования ипи реализации.
3.20 функциональное тестирование программы: Вид работ по исследованию программы,
направленный на выявление отличий между ее реально существующими и требуемыми свойствами.
3.21 фаззинг-тестированио программы: Вид работ по исследованию программы, направлен
ный на оценку ее свойств и основанный на передаче программе случайных или специально сформиро
ванных входныхданных, отличныхотданных, предусмотренныхалгоритмом работы программы.
3.22 экспертиза исходного кода программы: Видработповыявлениюнедостатков программы
(потенциально уязвимых конструкций) в исходном коде программы, основанный на анализе исходного
кода программы в режиме, не предусматривающем реального выполнения кода.
3.23 электронный документ: Документ, выполненный программно-техническим средством на
электронном носителе.
П р и м е ч а н и е — Адаптировано из ГОСТ 2.001.
3.24
элемент конфигурации: Объект конфигурации, выполняющий законченную функцию.
[ГОСТ РИСО 10007—2007, статья 3.5]
4 Общие положения
4.1 Предотвращение появления и устранение уязвимостей программы может быть достигнуто
путем реализацииразработчиком программного обеспечения(ПО) мер поразработкебезопасного ПОв
процессахжизненного цикла ПО, установленных ГОСТ Р ИСО/МЭК12207.
4.2 Меры по разработке безопасного ПО, представленные в настоящем стандарте, выражены в
форме требования, рекомендации или допустимого действия, предназначенныхдля поддержкидости
жения результатов реализации мер. Для этой цели в настоящем стандарте используют вспомогатель
ные глаголы «должен», «следует» и «может», чтобы подчеркнуть различие между разными формами
требований к реализации мер. Глагол «должен» использовандля выражения условия, требуемогодля
соответствия, «следует» — для выражения рекомендации средидругих возможностей, «может» — для
того, чтобы отразить направление допустимых действий в пределах ограничений настоящего
стандарта.
4.3 РазработчикПО долженопределить идокументировать цели организациив областисоздания
безопасного ПО и меры поразработкебезопасного ПО. реализация которых направлена надостижение
поставленных целей.
4.4 Для соответствия требованиям настоящего стандарта разработчик ПО должен обеспечить
реализацию и проводить внутренние проверки мер по разработке безопасного ПО. приведенных в
разделе 5 (базовый набор мер по разработке безопасного ПО), в процессах жизненного цикла ПО,
установленных ГОСТ Р ИСО/МЭК 12207, а также работать над улучшением процессов, связанных с
разработкой безопасного ПО.
4.5 При невозможности реализации в среде разработки ПО отдельных мер из базового набора
мер по разработке безопасного ПО разработчик ПО может разрабатывать и реализовывать иные
(компенсирующие) меры по разработкебезопасного ПО. обеспечивающиедостижение целей иполуче
ние результатов, соответствующих базовому наборумер поразработке безопасного ПО.
4.6 ЕслиразработчикПОпланируетпроведениеоценкиПОвсоответствиис
ГОСТ Р ИСО/МЭК 15408-1, ГОСТ Р ИСО/МЭК 15408-2. ГОСТ Р ИСО/МЭК 15408-3, то подготовку ПО к
оценке можно осуществлять в рамкахдействующих процессов, в которых реализованы меры по разра
ботке безопасного ПО, путем выполнениядополнительных мер. В таблицеА. 1приложения А отображе
на взаимосвязь мер по разработке безопасного ПО. установленных настоящим стандартом, и
требованийдоверия кбезоласностипоГОСТР ИСО/МЭК 15408-3, которую можноиспользоватьпри под
готовкеПО коценке поГОСТРИСО/МЭК15408-1, ГОСТР ИСО/МЭК 15408-2, ГОСТР ИСО/МЭК 15408-3.
4.7 Разработчик ПО должен предусмотреть выделение ресурсов, необходимых для реализации
мер по разработке безопасного ПО. иобеспечить реализацию этих мер.
4.8 РазработчикПО долженпроводитьвнутренние проверки выполнения мер поразработкебезо
пасного ПО. позволяющие установить, что реализуемые меры соответствуюттребованиям настоящего
стандарта.
4