7.2.4. Поддержка жизненного цикла (ALC)
7.2.4. Поддержка жизненного цикла (ALC) 
|
ALC_CMC.4
|
Поддержка генерации, процедуры приемки и автоматизация
|
|
Управление конфигурацией - один из способов увеличения доверия к тому, что ОО соответствует ФТБ. УК устанавливает это посредством предъявления требований к организационному порядку и управлению процессами усовершенствования и модификации ОО и связанной с ним информации. Системы УК реализуются для того, чтобы удостовериться в целостности частей ОО, подвергающихся контролю со стороны этих систем, путем отслеживания любых изменений, а также обеспечения санкционированности всех изменений.
|
|
|
Зависимости:
|
ALC_CMS.1 Охват УК ОО;
ALC_DVS.1 Идентификация мер безопасности;
|
|
ALC_LCD.1
|
Определенная разработчиком модель жизненного цикла.
|
|
Элементы действий разработчика
|
|
|
ALC_CMC.4.1D
|
Разработчик должен предоставить ОО и маркировку для ОО.
|
|
ALC_CMC.4.2D
|
Разработчик должен предоставить документацию УК.
|
|
ALC_CMC.4.3D
|
Разработчик должен использовать систему УК.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_CMC.4.1C
|
ОО должен быть помечен уникальной маркировкой.
|
|
ALC_CMC.4.2C
|
В документации УК должно содержаться описание метода, используемого для уникальной идентификации элементов конфигурации (в том числе файлов исходного кода, ресурсных файлов, файлов документации).
|
|
ALC_CMC.4.3C
|
В системе УК должны быть уникальным образом идентифицированы все элементы конфигурации.
|
|
ALC_CMC.4.4C
|
В системе УК должны быть предусмотрены такие автоматизированные меры, при применении которых в элементы конфигурации могут быть внесены только санкционированные изменения.
|
|
ALC_CMC.4.5C
|
Система УК должна поддерживать производство ОО автоматизированными средствами.
|
|
ALC_CMC.4.6C
|
Документация УК должна включать в себя план УК.
|
|
ALC_CMC.4.7C
|
В плане УК должно быть описание того, каким образом система УК используется для разработки ОО.
|
|
ALC_CMC.4.8C
|
План УК должен содержать описание процедур, используемых для приемки модифицированных или вновь созданных элементов конфигурации.
|
|
ALC_CMC.4.9C
|
В свидетельствах должно быть продемонстрировано, что все элементы конфигурации сопровождаются системой УК.
|
|
ALC_CMC.4.10C
|
В свидетельствах должно быть продемонстрировано, что система УК функционирует в соответствии с планом УК.
|
|
Элементы действий оценщика
|
|
|
ALC_CMC.4.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_CMC.4.1C - ALC_CMC.4.10C.
|
|
Работы оценки
Оценщик должен выполнить действия в соответствии с пунктом 12.2.4 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
|
|
|
ALC_CMS.4
|
Охват УК отслеживания проблем
|
|
Компонент ALC_CMS.4 содержит требование о том, что недостатки безопасности должны быть включены в список элементов конфигурации и, следовательно, должны находиться под УК в соответствии с требованиями УК семейства ALC_CMC "Возможности УК". Согласно этому требованию должно обеспечиваться сопровождение не только детальной информации о возникавших ранее недостатках и методах их устранения, но и об имеющихся в настоящий момент недостатках безопасности.
Включение недостатков безопасности в контроль системы УК не позволяет пропустить или проигнорировать сообщения о недостатках защиты, давая возможность разработчику отслеживать недостатки безопасности вплоть до их устранения.
|
|
|
Зависимости:
|
отсутствуют
|
|
Элементы действий разработчика
|
|
|
ALC_CMS.4.1D
|
Разработчик должен представить список элементов конфигурации для ОО.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_CMS.4.1C
|
Список элементов конфигурации должен включать следующее: сам ОО; свидетельства оценки, необходимые по требованиям доверия к безопасности; представление реализации; сведения о недостатках безопасности и стадии их устранения.
|
|
ALC_CMS.4.2C
|
Элементы конфигурации должны быть уникально идентифицированы в списке элементов конфигурации.
|
|
ALC_CMS.4.3C
|
Для каждого значимого для ФБО элемента конфигурации в списке элементов конфигурации должен быть указан разработчик.
|
|
Элементы действий оценщика
|
|
|
ALC_CMS.4.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_CMS.4.1C - ALC_CMS.4.3C.
|
|
Работы оценки
Оценщик должен выполнить действия в соответствии с пунктом 12.3.4 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
|
|
|
ALC_DEL.1
|
Процедуры поставки
|
|
Требования к поставке предусматривают такие средства и процедуры системы контроля и распространения, которые конкретизируют меры, необходимые для обеспечения доверия к тому, что безопасность ОО поддерживается во время передачи ОО пользователю.
|
|
|
Зависимости:
|
отсутствуют.
|
|
Элементы действий разработчика
|
|
|
ALC_DEL.1.1D
|
Разработчик должен задокументировать процедуры поставки ОО или его частей потребителю.
|
|
ALC_DEL.1.2D
|
Разработчик должен использовать процедуры поставки.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_DEL.1.1C
|
Документация поставки должна содержать описание всех процедур, необходимых для поддержания безопасности при распространении версий ОО потребителю.
|
|
Замечания по применению:
|
|
|
В процедурах поставки должны затрагиваться следующие вопросы:
а) обеспечение точного соответствия между ОО, полученным потребителем, и прошедшим оценку ОО;
б) избежание/обнаружение какой-либо подделки актуальной версии ОО;
в) предотвращение поставки фальсифицированной версии ОО;
г) избежание нежелательной утечки информации о распространении ОО потребителю; возможны случаи, при которых потенциальным нарушителям не следует знать о том, когда и каким образом поставляется ОО;
д) избежание/обнаружение перехвата ОО во время поставки;
е) избежание задержки поставки или невыполнения поставки ОО.
|
|
|
Элементы действий оценщика
|
|
|
ALC_DEL.1.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_DEL.1.1C.
|
|
Работы оценки
Оценщик должен выполнить действия в соответствии с пунктом 12.4.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
|
|
|
ALC_DVS.1
|
Идентификация мер безопасности
|
|
Безопасность разработки связана с физическими, процедурными, организационными и другими мерами безопасности, которые могут применяться в среде разработки для защиты ОО и его частей. К этому относится и физическая защита места разработки и любые процедуры, связанные с отбором персонала, занимающегося разработкой.
|
|
|
Зависимости:
|
отсутствуют.
|
|
Элементы действий разработчика
|
|
|
ALC_DVS.1.1D
|
Разработчик должен представить документацию по безопасности разработки.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_DVS.1.1C
|
Документация по безопасности разработки должна содержать описание всех физических, процедурных, организационных и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки.
|
|
ALC_DVS.1.2C
|
Для противодействия угрозам разработчик должен принять и задокументировать меры защиты, включающие:
|
|
а) обеспечение контроля физического доступа к средствам вычислительной техники, используемым на стадии разработки и тестирования ОО;
б) выделение сегментов вычислительных сетей, в которых располагаются средства вычислительной техники, используемые на стадии разработки ОО специализированных банковских приложений (специализированного ПО) финансовых организаций;
в) выделение сегментов вычислительных сетей, в которых располагаются средства вычислительной техники, используемые на стадии тестирования ОО специализированных банковских приложений (специализированного ПО) финансовых организаций;
г) организацию и контроль изоляции и информационного взаимодействия сегмента разработки, сегмента тестирования и сегментов вычислительных сетей, в которых располагаются средства вычислительной техники, используемые для реализации банковских технологических процессов, технологических процессов финансовой организации;
д) управление доступом к ресурсам, средствам разработки и тестирования ОО специализированных банковских приложений (специализированного ПО) финансовых организаций, в том числе исходным файлам;
е) регистрацию и контроль действий с исходными файлами ОО специализированных банковских приложений (специализированного ПО) финансовых организаций;
ж) организацию антивирусной защиты;
з) контроль использования коммуникационных портов средств вычислительной техники.
|
|
|
Элементы действий оценщика
|
|
|
ALC_DVS.1.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_DVS.1.1C.
|
|
ALC_DVS.1.2E
|
Оценщик должен подтвердить, что меры безопасности применяются и направлены на снижение вероятности возникновения в ОО уязвимостей и других недостатков.
|
|
Работы оценки
Оценщик должен выполнить действия в соответствии с пунктом 12.5.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
|
|
|
ALC_FLR.2
|
Процедуры сообщений о недостатках
|
|
В процедурах устранения недостатков следует описать методы реагирования на все типы выявленных недостатков. Об этих недостатках могут сообщить разработчик ОО, пользователи ОО, другие стороны, знакомые с ОО. Некоторые недостатки не могут быть исправлены немедленно. Не исключено, что недостаток вообще не может быть исправлен, и необходимо применить другие (например, процедурные) меры. В представленной документации следует охватывать процедуры по обеспечению исправлений в местах эксплуатации, а также предоставлять информацию о недостатках, для которых исправление отложено или невозможно (с описанием того, что следует делать в этой ситуации).
|
|
|
Зависимости:
|
отсутствуют.
|
|
Элементы действий разработчика
|
|
|
ALC_FLR.2.1D
|
Разработчик должен предоставить процедуры устранения недостатков, предназначенные для заявителей (разработчиков, производителей) ОО.
|
|
ALC_FLR.2.2D
|
Разработчик должен установить процедуру получения и отработки всех сообщений пользователей о недостатках безопасности и запросов на исправление этих недостатков.
|
|
ALC_FLR.2.3D
|
Разработчик должен предоставить руководство по устранению недостатков, предназначенное для пользователей ОО.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_FLR.2.1C
|
Документация процедур устранения недостатков должна содержать описание процедур по отслеживанию всех ставших известными недостатков безопасности в каждом релизе ОО.
|
|
ALC_FLR.2.2C
|
Процедуры устранения недостатков должны содержать требование представления описания сути и последствий каждого недостатка безопасности, а также состояния процесса исправления этого недостатка.
|
|
ALC_FLR.2.3C
|
Процедуры устранения недостатков должны содержать требование к тому, что для каждого недостатка безопасности должны быть идентифицированы корректирующие действия.
|
|
ALC_FLR.2.4C
|
Документация процедур устранения недостатков должна содержать описание методов, используемых для предоставления пользователям ОО информации о недостатках, материалов исправлений и руководства по внесению исправлений.
|
|
ALC_FLR.2.5C
|
Процедуры устранения недостатков должны описывать средства, посредством которых разработчик получает от пользователей ОО сообщения и запросы о предполагаемых недостатках безопасности в ОО.
|
|
ALC_FLR.2.6C
|
Процедуры обработки ставших известными недостатков безопасности должны обеспечить, чтобы любые ставшие известными недостатки были исправлены, а для пользователей ОО выпущены процедуры по исправлению.
|
|
ALC_FLR.2.7C
|
Процедуры обработки ставших известными недостатков безопасности должны обеспечить такие защитные меры, чтобы любые исправления этих недостатков не приводили к появлению новых недостатков.
|
|
ALC_FLR.2.8C
|
Руководство по устранению недостатков должно описывать средства, посредством которых пользователи ОО могут сообщать разработчикам о любых предполагаемых недостатках безопасности в ОО.
|
|
Элементы действий оценщика
|
|
|
ALC_FLR.2.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_FLR.2.1C - ALC_FLR.2.8C.
|
|
Работы оценки
Оценщик должен выполнить действия в соответствии с пунктом 12.6.2 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
|
|
|
ALC_FPU_EXT.1
|
Процедуры обновления программного обеспечения
|
|
Элементы действий разработчика
|
|
|
ALC_FPU_EXT.1.1D
|
Разработчик должен разработать и реализовать технологию обновления ОО для [выбор:
обновление, направленное на устранение уязвимостей ОО;
иное обновление, оказывающее влияние на безопасность ОО;
обновление, не оказывающее влияния на безопасность ОО
].
|
|
ALC_FPU_EXT.1.2D
|
Разработчик должен разработать и поддерживать регламент обновления программного обеспечения.
|
|
ALC_FPU_EXT.1.3D
|
Разработчик должен разработать и реализовать процедуру уведомления потребителей о выпуске обновлений ОО, основанную на [назначение: способы уведомления].
|
|
ALC_FPU_EXT.1.4D
|
Разработчик должен разработать и реализовать процедуру предоставления обновлений потребителям ОО, основанную на [назначение: способы предоставления обновлений].
|
|
ALC_FPU_EXT.1.5D
|
Разработчик должен разработать и реализовать процедуру предоставления обновлений оценщику для проведения внешнего контроля, основанную на [назначение: способы предоставления обновлений для контроля].
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_FPU_EXT.1.1C
|
Документация ОО должна содержать описание технологии выпуска обновлений ОО.
|
|
ALC_FPU_EXT.1.2C
|
Документация ОО должна содержать регламент обновления ОО, включающий:
а) идентификацию типов выпускаемых обновлений;
б) описание процедуры уведомления потребителей о выпуске обновлений;
в) описание процедуры предоставления обновлений потребителям;
г) описание содержания эксплуатационной документации на выпускаемые обновления;
д) [назначение: иная информация].
|
|
ALC_FPU_EXT.1.3C
|
Регламент обновления ОО должен предусматривать включение в эксплуатационную документацию на выпускаемые обновления описания следующих процедур:
а) процедуры получения обновления;
б) процедуры контроля целостности обновления;
в) типовой процедуры тестирования обновления;
г) процедуры установки и применения обновления;
д) процедуры контроля установки обновления;
е) процедуры верификации (проверки) применения обновления.
|
|
ALC_FPU_EXT.1.4C
|
Документация процедуры предоставления обновлений для проведения внешнего контроля должна содержать:
а) описание процедуры предоставления обновлений для внешнего контроля;
б) требования к предоставлению и содержанию методики тестирования обновления разработчиком;
в) требования к оформлению и предоставлению результатов тестирования обновления разработчиком;
г) [назначение: иная информация].
|
|
Элементы действий оценщика
|
|
|
ALC_FPU_EXT.1.1E
|
Оценщик должен подтвердить, что информация, предоставленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированных материалов, изложенным в ALC_FPU_EXT.1.1C - ALC_FPU_EXT.1.4C.
|
|
ALC_FPU_EXT.1.2E
|
Оценщик должен проверить, что процедура предоставления обновлений для проведения внешнего контроля позволяет организовать и проводить их внешний контроль.
|
|
Замечания по применению:
|
|
|
В качестве типов обновлений рассматриваются: обновления, направленные на устранение уязвимостей ОО; иные обновления, оказывающие влияние на безопасность ОО; обновления, не оказывающие влияния на безопасность ОО.
|
|
|
ALC_LCD.1
|
Определенная разработчиком модель жизненного цикла
|
|
Модель жизненного цикла объединяет в себе процедуры, инструментальные средства и методы, используемые для разработки и сопровождения ОО. Аспекты процесса, которые могут быть охвачены такой моделью, включают методы проектирования, процедуры просмотра, средства управления проектом, процедуры управления изменениями, методы тестирования и процедуры приемки. Эффективная модель жизненного цикла позволит включить аспекты процесса разработки и сопровождения в общую структуру управления, которая устанавливает обязанности и контролирует ход процессов.
Важно, чтобы модель разработки и сопровождения ОО была установлена как можно раньше в жизненном цикле ОО.
|
|
|
Зависимости:
|
отсутствуют.
|
|
Элементы действий разработчика
|
|
|
ALC_LCD.1.1D
|
Разработчик должен установить модель жизненного цикла, используемую при разработке и сопровождении ОО.
|
|
ALC_LCD.1.2D
|
Разработчик должен представить документацию по определению жизненного цикла.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_LCD.1.1C
|
Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО.
|
|
Замечания по применению:
|
|
|
Модель жизненного цикла ОО должна содержать следующие стадии:
1) проектирование;
2) создание и тестирование;
3) приемка и ввод в действие;
4) сопровождение и модернизация.
|
|
|
ALC_LCD.1.2C
|
Модель жизненного цикла должна обеспечить необходимый контроль за разработкой и сопровождением ОО.
|
|
Замечания по применению:
|
|
|
На каждой стадии жизненного цикла формируется собственный набор свидетельств доверия, по результатам оценки которых может быть принято решение о полноте и корректности реализации требований к обеспечению ИБ, предъявляемых к ОО.
В качестве документированных материалов рекомендуется рассматривать:
а) регламенты, используемые для организации деятельности по обеспечению ИБ на этапах жизненного цикла ОО;
б) документированные результаты выполнения деятельности по обеспечению ИБ на этапах жизненного цикла ОО.
|
|
|
Элементы действий оценщика
|
|
|
ALC_LCD.1.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_LCD.1.1C и ALC_LCD.1.2C.
|
|
Работы оценки
Оценщик должен выполнить действия в соответствии с пунктом 12.7.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
|
|
|
ALC_LCD_EXT.3
|
Определенные разработчиком сроки поддержки
|
|
Зависимости:
|
отсутствуют.
|
|
Элементы действий разработчика
|
|
|
ALC_LCD_EXT.3.1D
|
Заявитель, разработчик, производитель должны установить в совместной декларации срок [назначение: срок], в течение которого они обязуются выполнять все необходимые действия по поддержке ОО, направленные на обеспечение поддержания сертификата соответствия ОО требованиям безопасности информации.
|
|
ALC_LCD_EXT.3.2D
|
Заявитель, разработчик, производитель должны обеспечить представление совместной декларации о сроке поддержки ОО вместе с заявкой на сертификацию ОО.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_LCD_EXT.3.1C
|
Декларация о сроке поддержки ОО должна содержать план поддержки ОО на весь задекларированный срок, включающий описание всех предпринимаемых действий по обеспечению поддержания сертификата соответствия ОО требованиям безопасности информации.
|
|
ALC_LCD_EXT.3.2C
|
Декларация о сроке поддержки ОО должна содержать сведения о поддерживаемой версии ОО.
|
|
Элементы действий оценщика
|
|
|
ALC_LCD_EXT.3.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_LCD_EXT.3.1C и ALC_LCD_EXT.3.2C.
|
|
ALC_TAT.1
|
Полностью определенные инструментальные средства разработки
|
|
Данные требования связаны с выбором инструментальных средств, используемых для разработки, анализа и реализации ОО. Они направлены на предотвращение использования плохо определенных, несогласованных или неверных инструментальных средств для разработки ОО. Это относится, в частности, к языкам программирования, документации, стандартам реализации и некоторым другим частям ОО, например, вспомогательным динамическим библиотекам.
Полностью определенными называют инструментальные средства, которые полно и четко описаны. Например, принято считать полностью определенными языки программирования и системы автоматизации проектирования (САПР), которые основаны на стандартах, изданных органами по стандартизации. Для средств, разработанных самими разработчиками ОО, потребуется проведение дополнительных исследований для установления того, являются ли они полностью определенными.
|
|
|
Зависимости:
|
ADV_IMP.1 Подмножество реализации ФБО.
|
|
Элементы действий разработчика
|
|
|
ALC_TAT.1.1D
|
Разработчик должен идентифицировать каждое инструментальное средство, используемое для разработки (производства) ОО.
|
|
ALC_TAT.1.2D
|
Разработчик должен задокументировать выбранные опции инструментальных средств разработки (производства), обусловленные реализацией.
|
|
Элементы содержания и представления документированных материалов
|
|
|
ALC_TAT.1.1C
|
Все инструментальные средства разработки (производства), используемые для реализации, должны быть полностью определены.
|
|
ALC_TAT.1.2C
|
В документации по инструментальным средствам разработки (производства) должны быть однозначно определены значения всех языковых конструкций, используемых в реализации.
|
|
ALC_TAT.1.3C
|
В документации по инструментальным средствам разработки (производства) должны быть однозначно определены значения всех опций, обусловленных реализацией, методы, приемы и правила эксплуатации средств разработки (производства) при создании (производстве) ОО.
|
|
ALC_TAT.1.3C
|
Должны иметься и поддерживаться лицензии (права) на все инструментальные средства разработки.
|
|
Элементы действий оценщика
|
|
|
ALC_TAT.1.1E
|
Оценщик должен подтвердить, что информация, представленная заявителем в документированных материалах, удовлетворяет всем требованиям к содержанию и представлению документированной информации, изложенным в ALC_TAT.1.1C - ALC_TAT.1.4C.
|
|
Работы оценки
1. Оценщик должен выполнить действия в соответствии с пунктом 12.8.1 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 18045 "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий".
2. Оценщик должен исследовать представленную документацию инструментальных средств разработки, чтобы сделать заключение о том, что для представления реализации представлено четкое и полное описание синтаксиса и детальное описание семантики каждой из языковых конструкций. В документации инструментальных средств разработки (например, в спецификациях языка программирования и в руководствах пользователя) должны быть охвачены все конструкции, используемые в представлении реализации ОО, и для каждой такой конструкции должно быть предоставлено четкое и однозначное определение предназначения и результата выполнения этой конструкции.
3. Оценщик должен исследовать представленную документацию инструментальных средств разработки, чтобы сделать заключение о том, что в ней описаны языковые конструкции, определяющие связи функциональных объектов по управлению. В качестве таких языковых конструкций могут выступать прямые вызовы функций с передачей фактических параметров, а также косвенные вызовы функций по указателю, по значениям полей записей, массивов и т.п.
4. Оценщик должен исследовать представленную документацию инструментальных средств разработки, чтобы сделать заключение о том, имеются ли в определении языка программирования проблемные конструкции, которые могут быть применены к информационным объектам. В качестве таких проблемных конструкций могут выступать, например, преобразование информационного объекта из одного типа данных в другой, использование псевдонимов (альтернативных имен, которые позволяют ссылаться на одну и ту же часть памяти различными способами), указателей (ссылок) на произвольные области памяти, использование стека для передачи фактических параметров между функциональными объектами, динамическое выделение памяти информационным объектам и т.п.
Оценщик должен исследовать представленную документацию инструментальных средств разработки, с тем чтобы определить проблемные конструкции, которые могут вносить уязвимости в ОО или в среду функционирования ОО.
|
|
