ГОСТ Р 56939-2024
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Защита информации
РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Общие требования
Information protection. Secure software development. General requirements
ОКС 35.020
Дата введения 2024-12-20
1 РАЗРАБОТАН Федеральной службой по техническому и экспортному контролю (ФСТЭК России), Акционерным обществом "Лаборатория Касперского" (АО "Лаборатория Касперского"), Федеральным государственным бюджетным учреждением науки Институт системного программирования им.В.П.Иванникова Российской академии наук (ИСП РАН), Акционерным обществом "Информационные технологии и коммуникационные системы" (АО "ИнфоТеКС"), Акционерным обществом "Позитив Текнолоджиз" (АО "Позитив Текнолоджиз"), Обществом с ограниченной ответственностью "РусБИТех-Астра" (ООО "РусБИТех-Астра"), Акционерным обществом "Сбербанк-Технологии" (АО "Сбер-Тех"), Обществом с ограниченной ответственностью Научно-технический центр "Фобос-НТ" (ООО НТЦ "Фобос-НТ"), Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Акционерным обществом "Научно-производственное объединение "Эшелон" (АО НПО "Эшелон")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 24 октября 2024 г. № 1504-ст
4 ВЗАМЕН ГОСТ Р 56939-2016
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Настоящий стандарт направлен на достижение целей, связанных с предотвращением появления, выявлением и устранением недостатков, в том числе уязвимостей, в программном обеспечении, и содержит общие требования, предъявляемые к разработчикам и производителям программного обеспечения при реализации процессов разработки безопасного программного обеспечения.
Настоящий стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного программного обеспечения (ПО) и устранением выявленных недостатков, в том числе уязвимостей, ПО.
Настоящий стандарт предназначен для разработчиков и производителей ПО, а также для организаций, выполняющих оценку соответствия процессов разработки ПО положениям настоящего стандарта.
Примечание - В настоящем стандарте разработчики и производители ПО обозначены термином "разработчик(и)".
Настоящий стандарт предусматривает применение в комплексе с другими национальными стандартами по разработке безопасного ПО, в которых раскрываются вопросы внедрения и оценки соответствия положениям настоящего стандарта, задаются требования к отдельным технологиям, применяемым в процессах разработки.
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
ГОСТ Р 50922 Защита информации. Основные термины и определения
ГОСТ Р 58412 Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
В настоящем стандарте применены термины по ГОСТ Р 50922, а также следующие термины с соответствующими определениями:
3.1 безопасное программное обеспечение: Программное обеспечение, разработанное в ходе реализации совокупности процессов (мер), направленных на предотвращение появления и устранение недостатков программы.
3.2 динамический анализ кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе кода программы в режиме непосредственного исполнения (функционирования) кода.
3.3 документация разработчика программного обеспечения: Совокупность программных и иных документов, предназначенных для организации и проведения работ по созданию программного обеспечения и/или подтверждения соответствия требованиям настоящего стандарта.
Примечание - К программным относятся документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. К иным документам относятся документы, не относящиеся к программным, и содержащие сведения, подтверждающие соответствие требованиям настоящего стандарта.
3.4
инструментальное средство: Компьютерная программа, используемая как средство разработки, тестирования, анализа, производства или модификации других программ или документов на них. [ГОСТ Р 51904-2002, пункт 3.17] |
3.5 интерфейс программного обеспечения: Способ взаимодействия между программами или между программами и пользователями. 3.6 компонент программного обеспечения: Составная часть (программный модуль) программного обеспечения, выполняющая определенную функцию. 3.7 |
компьютерная атака: Целенаправленное несанкционированное воздействие на информацию, на ресурс автоматизированной информационной системы или получение несанкционированного доступа к ним с применением программных или программно-аппаратных средств. [ГОСТ Р 51275-2006, пункт 3.11] |
3.8 недостаток программы: Любое несоответствие программы заданным требованиям или любая ошибка, допущенная в ходе проектирования или реализации программы, которая в случае ее неисправления может являться причиной невозможности выполнения требуемых функциональных возможностей или уязвимости программы. 3.9 |
поверхность атаки: Множество подпрограмм (функций, модулей) программного обеспечения, обрабатывающих данные, поступающие посредством интерфейсов, напрямую или косвенно подверженных риску атаки. [адаптировано из ГОСТ Р 56498-2015, пункт 3.1.7] |
3.10 пользователь (программного обеспечения): Лицо, применяющее программное обеспечение. 3.11 |
программа: Данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма. [ГОСТ 19781-90, статья 1] |
3.12 |
программное обеспечение: Совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ. [ГОСТ 19781-90, статья 2] |
3.13 |
программный модуль (модуль программного обеспечения): Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память. [ГОСТ 19781-90, статья 15] |
3.14 сборка программного обеспечения: Процесс построения из исходного кода программ программных модулей, готовых к выполнению или интерпретации, и/или библиотек. 3.15 |
сборочная среда: Совокупность программных и аппаратных средств, служб связи, интерфейсов, форматов данных, протоколов, стандартов, обеспечивающих преобразование исходного кода программ в программные модули в соответствии с представленными метаданными и с учетом зависимостей программного модуля. [Адаптировано из ГОСТ Р 54593-2011, пункт 3.13] |
3.16 система сборки программного обеспечения: Совокупность программных средств и конфигурационных файлов, которая позволяет выполнить сборку конкретного экземпляра конкретной программы. 3.17 |
среда разработки программного обеспечения: Интегрированная система, включающая в себя аппаратные средства, программное обеспечение, программно-аппаратные средства, процедуры и документы, необходимые для разработки программного обеспечения. [ГОСТ Р 51904-2002, пункт 3.62] |
3.18 статический анализ исходного кода программы: Вид работ по инструментальному исследованию программы, основанный на анализе исходных текстов программы с использованием специализированных инструментальных средств (статических анализаторов) в режиме, не предусматривающем исполнения кода, и выполняемый для определения свойств программы; в частности, статический анализ применяется для выявления потенциальных ошибок в программе.
Примечание - Термины "анализ исходных текстов" и "анализ исходного кода" взаимозаменяемы в силу устоявшейся профессиональной терминологии.
3.19 управление конфигурацией программного обеспечения: Скоординированные действия, направленные на формирование и контроль конфигурации программного обеспечения.
3.20 уязвимость программы: Недостаток программы, который может быть использован для реализации угроз безопасности информации.
Примечание - Уязвимость программы может быть результатом ее разработки без учета требований по обеспечению безопасности информации, вследствие наличия ошибок проектирования или реализации или в результате применения небезопасных инструментальных средств и языков программирования, имеющих ошибки проектирования, реализации или конфигурирования.
3.21 функциональное тестирование программы: Вид работ по исследованию программы, направленный на выявление отличий между ее реально существующими и требуемыми свойствами.
3.22 фаззинг-тестирование программы: Вид работ по исследованию программы, основанный на передаче программе случайных или специально сформированных входных данных, отличных от данных, предусмотренных алгоритмом работы программы.
3.23 экспертиза исходного кода программы: Вид работ по выявлению недостатков программы в исходном коде программы, направленный на оценку ее свойств и основанный на анализе исходного кода программы в режиме, не предусматривающем реального выполнения кода.
4.1 Основной целью разработки безопасного ПО является:
- выявление недостатков, в том числе уязвимостей, в разрабатываемом ПО;
- снижение количества недостатков, в том числе уязвимостей ПО;
- снижение ущерба от невыявленных уязвимостей ПО;
- оперативное устранение выявляемых уязвимостей в ПО.
4.2 В настоящем стандарте общие требования к разработке безопасного ПО представлены в виде описания процессов, реализация которых направлена на достижение цели разработки безопасного ПО.
4.3 Поскольку модель жизненного цикла ПО зависит от специфики, масштаба, сложности ПО и условий, в которых ПО создается и функционирует, приведенные в настоящем стандарте процессы намеренно не связываются с конкретной моделью жизненного цикла ПО. По тексту стандарта процессы могут быть соотнесены с обобщенными этапами жизненного цикла ПО (например, с этапом эксплуатации), что дает разработчику гибкость реализации процессов и используемых подходов, таких как изложенных в ГОСТ Р ИСО/МЭК 12207.
4.4 Методика оценки соответствия реализации процессов разработки безопасного ПО установленным настоящим стандартом требованиям является предметом рассмотрения отдельного национального стандарта.
4.5 Внедрение и реализация процессов разработки безопасного ПО подразумевают непосредственное участие руководства разработчика и выделение необходимых ресурсов.
4.6 Процессы разработки безопасного ПО реализуются комплексом организационных и технических мероприятий.
4.7 Условия реализации процессов разработки безопасного ПО выражены в форме следующих понятий: требование, рекомендация или допустимое действие. С целью подчеркнуть различие между разными формами условий для реализации процессов разработки безопасного ПО в настоящем стандарте используются вспомогательные глаголы "должен", "следует" "рекомендуется" и "может". Глаголы "должен" и "следует" - для выражения условия, требуемого для соответствия требованию; "рекомендуется" - для выражения рекомендации по реализации, "может" - для того чтобы отразить возможные направления допустимых действий.
4.8 Процессы разработки безопасного ПО изложены в виде следующей структуры: наименование процесса (наименование соответствующего подраздела раздела 5), цели, требования к реализации, артефакты реализации требований (пункты соответствующих подразделов).
4.9 Пункт "Цели" включает формулировки целей реализации процесса разработки безопасного ПО.
4.10 Пункт "Требования к реализации" включает формулировки требований к реализации процесса разработки безопасного ПО.
4.11 Пункт "Артефакты реализации требований" включает формулировки наименования артефактов, подтверждающих выполнение требований к реализации процессов разработки безопасного ПО, и их содержание. Под артефактами реализации требований в настоящем стандарте понимается любая информация (документы, отчеты, файлы, журналы, результаты работы инструментов, процессов), сохраненная в любом виде (электронном, физическом), на основании которой возможно подтвердить реализацию соответствующих требований.
4.12 Наиболее общими для большинства рассматриваемых процессов артефактами реализации требований разработчика в настоящем стандарте являются регламенты. В общем случае регламент осуществления процесса разработки безопасного ПО должен содержать информацию об обязанностях сотрудников и их ролях при реализации соответствующих процессов, а также информацию, непосредственно относящуюся к особенностям реализации процесса. Требований к оформлению регламентов не предъявляется. Регламенты, относящиеся к различным процессам разработки безопасного ПО, могут быть оформлены как самостоятельные документы в электронном или физическом виде или объединены в рамках общего документа (например, в виде руководства по разработке безопасного ПО).
4.13 При разработке ПО средой разработки ПО должны быть обеспечены контроль версий разрабатываемого ПО, непрерывная интеграция разрабатываемого ПО, управление задачами, в том числе по отслеживанию ошибок в коде ПО. Процессы разработки безопасного ПО необходимо интегрировать с применяемыми в среде разработки ПО системами в целях обеспечения регулярности и своевременности проверок кода, прослеживаемости устранения выявленных ошибок.
Примечание - Под непрерывной интеграцией здесь понимается автоматизация внесений изменений кода ПО (модулей ПО, компонентов ПО) от нескольких разработчиков в единый проект ПО.