Создание надежных и безопасных программ C++

  • Статья

В США публикации NISTIR 8397. Рекомендации по минимальному стандарту проверки программного обеспечения разработчика содержат отличные рекомендации по созданию надежного и безопасного программного обеспечения на любом языке программирования.

Этот документ следует той же структуре, что и NISTIR 8397. Каждый раздел:

  • В этой статье описано, как использовать продукты разработчика Майкрософт для C++ и других языков для удовлетворения потребностей в безопасности этого раздела и
  • предоставляет рекомендации для получения наибольшего значения в каждой области.

Моделирование угроз 2.1

Сводка

Моделирование угроз — это ценный процесс, особенно при применении таким образом, чтобы масштабироваться в соответствии с потребностями разработки и уменьшать шум.

Рекомендации

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

  • Обладайте твердым динамическим SDL, который позволяет ранней работе с командами разработчиков и прав доступа к подходу.
  • Применение моделирования угроз в целевом режиме. Примените моделирование угроз ко всем функциям, но тактическое начало с предоставляемых, сложных или критически важных функций. Регулярно применяйте его в рамках проверки продукта сверху вниз.
  • Раннее применение моделирования угроз (как и во всех требованиях к безопасности), когда по-прежнему есть возможность изменить дизайн. Кроме того, модели угроз служат входными данными для других процессов, таких как уменьшение поверхности атаки или проектирование для обеспечения безопасности. Модели угроз, созданные позже, лучше всего "опросы" для тестирования пера (тестирования на проникновение) или областей, требующих тестирования безопасности, таких как нечеткое. После создания базовой модели угроз планируйте продолжить итерацию по мере изменения поверхности атаки.
  • Используйте инвентаризацию активов и соответствие требованиям, чтобы соответствующим образом отслеживать продукты и отслеживать артефакты безопасности (включая модели угроз) вместе с ресурсами, к которым они применяются. Такой подход обеспечивает более эффективную автоматическую оценку рисков и фокус на усилиях по обеспечению безопасности на конкретных компонентах или функциях, которые изменяются.
  • В Azure средство моделирования угроз Майкрософт было обновлено в 2022 году для разработки Azure. Дополнительные сведения см. в разделе "Средство моделирования угроз Майкрософт" в Azure

Вспомогательные факторы и методики

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

Подход к разработке

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

  • Делает ли эта функция важным изменением в проектировании того, как мы предоставляем изоляцию клиентов в мультитенантной среде? В этом случае рассмотрите возможность выполнения полной модели угроз.
  • Разрешает ли новая функция отправки файлов? Если это так, возможно, что более уместно, это оценка безопасности веб-приложений.
  • Это изменение в первую очередь просто изменение функционального пользовательского интерфейса? Если да, возможно, ничего не требуется за пределами традиционных автоматизированных инструментов.

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

Инвентаризация продуктов

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

  • датчики (например, пассажирские железнодорожные и транспортные средства),
  • сети на основе автобусов, которые разговаривают с другими компонентами в автомобиле (например, CANBUS или PROFIBUS),
  • беспроводной/сотовой связи/Bluetooth для связи с клиентскими устройствами и облачными внутренними клиентами,
  • машинное обучение в облаке обратно в устройство или приложение управления парком,
  • другое.

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

Детализация и интеграция

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

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

Масштабировать

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

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

2.2 Автоматическое тестирование

Сводка

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

Атрибуты ключей

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

  • В первую очередь они должны запускаться на компьютере, который вносит изменения. Выполнение тестов проще всего выполнять в интегрированной среде разработки, которая используется для редактирования, или как скрипт в командной строке, так как разработчик вносит изменения.
  • Следующее место, где они должны выполняться, является частью процесса фиксации или слияния запроса на вытягивание.
  • Последнее место для выполнения тестов — это часть конвейера непрерывной интеграции и непрерывного развертывания (CI/CD) или сборки кандидата выпуска.

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

Непрерывное использование и обслуживание

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

Типы тестов, особенно модульные тесты

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

Visual Studio

Visual Studio Test Explorer изначально поддерживает многие из самых популярных платформ тестирования C++ и имеет параметры установки расширений для дополнительных платформ. Эта гибкость полезна для выполнения подмножества тестов, охватывающих код, который вы работаете, и упрощает отладку сбоев тестов по мере их возникновения. Visual Studio также упрощает настройку новых наборов тестов для существующих проектов и предоставляет полезные инструменты, такие как CodeLens, чтобы упростить управление этими тестами. Дополнительные сведения о написании, запуске и управлении тестами C/C++ с помощью Visual Studio см. в статье "Запись модульных тестов для C/C++ — Visual Studio (Windows)".

В Azure и GitHub CI/CD

Тесты, выполняющие более глубокую проверку и выполняющиеся дольше, например статический анализ, обнаружение компонентов и т. д., являются хорошими кандидатами для тестирования запросов на вытягивание или непрерывного тестирования интеграции. Azure DevOps и GitHub Actions упрощают выполнение проверок автоматически и блокируют проверки кода, если проверка завершается ошибкой. Автоматическое принудительное применение помогает обеспечить безопасность всего кода на основе этих более строгих проверок. Проверка сборки Azure Pipelines и Azure DevOps описаны здесь:

2.3 Код на основе кода или статический анализ

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

Рекомендации Майкрософт рекомендует вам:

  • Включите статический анализ для всех программ C++ для входного исходного кода (перед компиляцией) и исполняемых двоичных файлов (после компиляции). "Включить" может означать выполнение анализа во время каждой сборки на компьютере разработчика или как отдельная сборка для проверки кода позже или как требование проверки.
  • Включение статического анализа в конвейеры CI в качестве формы тестирования.
  • Статический анализ по определению поставляется с ложными срабатываниями и быть готовым включить этот факт в цикл отзывов качества. Будьте быстрыми, чтобы включить все предупреждения с низким уровнем ложноположительных срабатываний заранее. Затем следует постепенно увеличивать число правил, для которых база кода компилирует предупреждение очистки, так как вы регулярно добавляете больше правил, которые помечают важные ошибки за счет постепенно более высоких ложных срабатываний (изначально до очистки базы кода для этих правил тоже).
  • Всегда используйте последние поддерживаемые версии Visual Studio и настройте среду разработки, чтобы быстро использовать последние выпуски исправлений, как только они становятся доступными, не откладывая на следующий этап разработки или цикл.

Ключевые средства следует учитывать и использовать следующие компоненты :

Примечания:

  • /analyze позволяет статическому анализу кода C++ во время компиляции определить критически важные уязвимости кода безопасности и надежности. Она должна быть включена на протяжении всей временной шкалы разработки программы C++. Начните с включения по крайней мере "Microsoft Native Recommended" по умолчанию в качестве минимального базового плана. Затем ознакомьтесь с документацией по указанию дополнительных правил, особенно правил основных рекомендаций C++ в соответствии с требованиями политик проектирования. Возможность статического анализа исходного кода доступна как в интегрированной среде разработки Visual C++, так и в средствах сборки командной строки.
  • /W4 и /WX должен быть включен везде, чтобы обеспечить чистую компиляцию кода на высоком уровне предупреждений (W4) и обрабатывать предупреждения как ошибки, которые должны быть исправлены (WX). Эти параметры позволяют находить неинициализированные ошибки данных, которые другие статические средства анализа не могут проверить, так как ошибки становятся видимыми только после того, как серверная часть компилятора выполняет межпросходный анализ и встраивание.
  • Двоичный анализ BinSkim гарантирует, что проекты обеспечивают широкий спектр функций безопасности. BinSkim создает PDF-файлы и другие выходные данные, которые упрощают проверку цепочки хранения и эффективно реагировать на вопросы безопасности. Корпорация Майкрософт рекомендует запустить средство BinSkim для анализа всех исполняемых двоичных файлов (.sys.dllили.exe) созданных или потребляемых программами. Руководство пользователя BinSkim содержит список поддерживаемых стандартов безопасности. Корпорация Майкрософт рекомендует устранить все проблемы, сообщаемые как "ошибки" инструментом BinSkim. Проблемы, сообщаемые как "предупреждения", должны оцениваться выборочно, так как разрешение их может иметь последствия для производительности или может не потребоваться.

В Azure и GitHub CI/CD корпорация Майкрософт рекомендует всегда включать исходный код и двоичный статический анализ в сценариях CI/CD выпуска. Выполните анализ источника немедленно на компьютере локального разработчика или по крайней мере для каждого запроса фиксации или извлечения, чтобы поймать исходные ошибки как можно раньше и свести к минимуму общие затраты. Ошибки двоичного уровня, как правило, возникают медленнее, поэтому может быть достаточно выполнить двоичный анализ в менее частых сценариях предварительной обработки и cd (таких как ночные или еженедельные сборки).

2.4 Проверка закодированных секретов

Сводка

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

Проблема.

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

Предотвращение

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

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

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

  • Периодически поворачивайте свои секреты и всякий раз, когда они могли быть предоставлены. Возможность смены и повторного развертывания секретов свидетельствует о безопасной системе. В частности, отсутствие этой возможности является еще более сильным свидетельством неизбежной уязвимости.
  • Не поддавайтесь общей логике разработчика, что "мои тестовые учетные данные не создают риск". На практике они почти всегда делают.
  • Рассмотрите возможность отходить от секретов (например, паролей, ключей носителя) полностью в предпочтениях решений на основе RBAC/identity в качестве хорошего инженерного решения, которое может полностью обойти неуправляемое управление секретами.

Обнаружение

Устаревшие компоненты продукта могут содержать скрытые секретные секреты в исходном коде. Иногда секреты настольных компьютеров разработчиков могут ползать в удаленную ветвь и объединяться в ветвь выпуска, утечка секретов непреднамеренно. Чтобы обнаружить секреты, которые могут скрываться в исходном коде, можно использовать средства, которые могут сканировать код для жестко закодированных секретов:

Исправление

Если учетные данные находятся в исходном коде, немедленно необходимо сделать недопустимый открытый ключ и выполнить анализ рисков на основе воздействия. Даже если системе нужно оставаться на работе, можно включить диспетчер секретов для исправления, выполнив следующие действия:

  1. Если исправление позволяет переключиться на управляемые удостоверения или требуется удалить диспетчер секретов, например Azure Key Vault (AKV), сначала сделайте это. Затем повторно разверните обновленный идентификатор или ключ.
  2. Отмените предоставленный секрет.
  3. Выполните аудит или оценку риска потенциального ущерба из-за компрометации.

Чтобы защитить криптографические ключи и другие секреты, используемые облачными приложениями и службами, используйте Azure Key Vault с соответствующей политикой доступа.

Если воздействие компрометирует определенные данные клиента или ЛИЧНЫЕ данные, может потребоваться другие требования к соответствию или отчетности.

Удалите недопустимые секреты из исходного кода и замените их альтернативными методами, которые не предоставляют секреты непосредственно в исходном коде. Ищите возможности для устранения секретов, где это возможно, с помощью таких средств, как Azure AD. Вы можете обновить методы проверки подлинности, чтобы воспользоваться преимуществами управляемых удостоверений с помощью Azure Active Directory. Используйте только утвержденные хранилища для хранения секретов, таких как Azure Key Vault (AKV). Дополнительные сведения см. в разделе:

Azure DevOps (AzDO)

Пользователи AzDO могут сканировать свой код с помощью GitHub Advanced Security для Azure DevOps (GHAzDO). GHAzDO также позволяет пользователям предотвратить секретные воздействия, включив push-защиту на своих репозиториях, перехватив потенциальные последствия до утечки. Дополнительные сведения об обнаружении жестко закодированных секретов в коде в Azure DevOps см. в статье "Проверка секретов для расширенной безопасности Github для Azure DevOps " в каждой из следующих ссылок:

В GitHub

Сканирование секретов доступно на GitHub.com в двух формах:

  • Оповещения о сканировании секретов для партнеров. Выполняется автоматически во всех общедоступных репозиториях. Все строки, которые соответствуют шаблонам, предоставленным партнерами по проверке секретов, передаются непосредственно соответствующему партнеру.
  • Оповещения проверки секретов для пользователей. Вы можете включить и настроить дополнительную проверку для репозиториев, принадлежащих организациям, использующей GitHub Enterprise Cloud, и иметь лицензию на GitHub Advanced Security. Эти средства также поддерживают частные и внутренние репозитории.

GitHub предоставляет известные шаблоны секретов для партнеров и пользователей, которые можно настроить в соответствии с вашими потребностями. Дополнительные сведения см. в следующем разделе:

Примечание.

GitHub Advanced Security для Azure DevOps предоставляет те же секреты, что и сканирование зависимостей, а также решения для сканирования кода CodeQL, уже доступные для пользователей GitHub, и изначально интегрирует их в Azure DevOps для защиты Azure Repos и Pipelines.

Дополнительные ресурсы

2.5 Запуск с помощью проверок и защиты, предоставляемых языком и ОС

Сводка

Двоичная защита выполняется путем применения элементов управления безопасностью во время компиляции. К ним относятся устранение рисков, которые:

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

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

Корпорация Майкрософт предоставляет набор средств, относящихся к проектам C++, чтобы помочь разработчикам создавать и отправлять более безопасный и безопасный код. Разработчики C++ также должны соответствовать стандартам безопасности, общим для языков, создающих исполняемый код. Корпорация Майкрософт поддерживает BinSkim— общедоступный двоичный средство проверки OSS, которое помогает применять многие средства защиты, описанные в этом разделе. Дополнительные сведения о BinSkim см . в руководстве пользователя Bskim | GitHub

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

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

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

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

Использование безопасных методов разработки, языковых версий, платформ и API

Код должен использовать методологии разработки, языковые версии, платформы, API и т. д., чтобы свести к минимуму риск путем обеспечения безопасности и простоты в C++, включая:

  • Сведения о создании современного, безопасного и согласованного кода C++ см . в руководстве по библиотеке поддержки C++, которая соответствует рекомендациям и позволяет избежать распространенных ошибок.
  • Ознакомьтесь с реализацией Microsoft GSL для функций и типов, которые вы предлагаете использовать в основных рекомендациях C++.
  • Безопасные для ресурсов контейнеры C++, защита переполнения памяти библиотеки среды выполнения C++: предпочитайте std::vector и std::stringкоторые являются ресурсобезопасными. Если необходимо использовать данные C, используйте безопасные версии функций CRT, которые предназначены для предотвращения повреждения памяти из-за неправильного использования буфера и неопределенного поведения языка.
  • Библиотека SafeInt защищает от целочисленного переполнения математических операций и операций сравнения.

Использование безопасных зависимостей

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

Максимальное повышение качества кода и эффективность реагирования на безопасность

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

  • /ZH:SHA_SHA256 в Visual C++ — гарантирует, что алгоритм шифрования используется для создания всех хэшей исходного файла PDB.
  • /Zi, /ZI (Отладочный формат информации) в Visual C++ — помимо публикации срезаных символов для сбора данных о сбоях и других сценариев общедоступного использования, убедитесь, что сборки создают и архивируют частные ДВОИЧНЫе файлы для всех выпущенных двоичных файлов. Средства двоичного анализа требуют полных символов, чтобы проверить, было ли включено множество мер безопасности во время компиляции. Частные символы критически важны в ответе на безопасность, а также снижение затрат на отладку и расследование, когда инженеры гонки для оценки и ограничения ущерба при возникновении эксплойтов.
  • /SOURCELINK в компоновщике Visual C++ — включение файла Sourcelink в PDB: исходная ссылка — это система, которая не зависит от языка и системы управления версиями, обеспечивая отладку исходного кода для двоичных файлов. Отладка источника значительно повышает эффективность диапазона предварительных проверок безопасности и реагирования на инциденты после выпуска.

Включение ошибок компилятора для предотвращения проблем во время разработки кода

Компиляция должна включать проверки компилятора безопасности в качестве критических ошибок, например:

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

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

Предотвращение раскрытия конфиденциальной информации

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

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

  • /Qspectre — Устранение атак на стороне канала спекулятивного выполнения. Вставка барьерных инструкций, которые помогают предотвратить раскрытие конфиденциальных данных, созданных спекулятивным выполнением. Эти меры должны быть включены для кода, который хранит конфиденциальные данные в памяти и работает через границу доверия. Корпорация Майкрософт всегда рекомендует измерять влияние производительности на соответствующие тесты при включении устранения рисков Spectre из-за возможности внедрения проверок среды выполнения в критически важных для производительности блоков или циклов. Эти пути кода могут отключить устранение рисков с помощью spectre(nomitigation) declspec модификатора. Проекты, которые позволяют /Qspectre также ссылаться на библиотеки, которые также компилируются с этими средствами устранения рисков, включая библиотеки среды выполнения Майкрософт.

2.6 Тестовые случаи Черного ящика

Сводка

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

Отношение к другим разделам

Эти типы тестов на основе требований полезны для проверки допущений, сделанных в модели угроз, и покрытия потенциальных угроз, как описано в этом разделе. Эти тесты полезны для тестирования интеграции между отдельными компонентами продукта, особенно теми, которые находятся через границы доверия, как описано в модели угроз. Варианты тестирования black box также полезны для тестирования всех типов пограничных вариантов для проверки ввода пользователем. Тестирование известных пограничных случаев и случаев ошибок полезно. Нечеткое также полезно для тестирования менее очевидных случаев.

Автоматизация и регрессия

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

Аварийные дампы

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

Сведения о начале отладки тестов см. в разделе "Отладка модульных тестов" с помощью обозревателя тестов — Visual Studio (Windows)

В Azure

Azure DevOps также может помочь управлять этими тестами и проверять их с помощью планов тестирования. Эти тесты можно использовать для подтверждения с помощью ручной проверки и запуска автоматических тестов, связанных с требованиями к продукту. Дополнительные сведения о планах тестирования Azure и их использовании для автоматического тестирования см. здесь:

2.7 Тестовые случаи на основе кода

Сводка

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

Типы и отношение к другим разделам

Распространенные типы тестовых случаев на основе кода:

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

Эти тесты основаны на внутреннем коде, написанном, в то время как тесты black box основаны на внешних функциональных требованиях продукта.

Цель

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

Visual Studio

Средства обозревателя тестов в Visual Studio позволяют быстро выполнять эти тесты и быстро получать отзывы о скоростях передачи или сбоях и расположениях сбоев. Многие платформы тестирования также поддерживают функции CodeLens, чтобы увидеть состояние теста в расположении самого теста, что упрощает добавление и обслуживание набора тестов. Обозреватель тестов также упрощает управление этими тестами, позволяя группам тестов, настраиваемым спискам воспроизведения тестов, фильтрации, сортировке, поиску и т. д.

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

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

Дополнительные сведения об этих средствах см. в разделе "Тестирование покрытия кода" в Visual Studio (Windows)

В Azure

Azure DevOps также может помочь отслеживать результаты покрытия кода для всего продукта в рамках процесса конвейера сборки. Дополнительные сведения см. в статье "Обзор покрытия кода " Azure Pipelines".

2.8 Исторические тестовые случаи

Сводка

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

Ключевые качества и отношение к другим разделам

Так как они проверяют регрессию ошибок, эти тесты должны быть быстрыми и простыми для выполнения, чтобы они могли выполняться вместе с примерами тестирования на основе кода и способствовать общему охвату кода продукта. Наряду с этим, использование реальных примеров от клиентов для вдохновения новых тестовых случаев является отличным способом улучшить охват и качество тестов.

Visual Studio

Visual Studio позволяет легко добавлять тесты в набор при внесении изменений в исправление ошибки, а также быстро запускать тесты и покрытие кода, чтобы обеспечить рассмотрение всех новых случаев. Ссылка на идентификатор ошибки из системы отслеживания проблем в коде, где вы пишете тест, является хорошим способом подключения тестов регрессии к соответствующим проблемам. Предпочитаете использовать azure Boards и тестовые планы вместе с Visual Studio:

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

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

В конечном итоге интеграция этих тестов в область модульного тестирования, которая должна охватывать раздел кода, помогает организовать набор тестов и упростить управление. С помощью группирования тестов обозревателя тестов можно эффективно отслеживать тесты, принадлежащие вместе. Дополнительные сведения см. в разделе "Запуск модульных тестов с помощью обозревателя тестов " Visual Studio (Windows)

2.9 Нечеткое

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

Руководство

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

Отношение к другим разделам

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

При использовании обоих санитизаторов, таких как Sanitizer (ASan) и нечеткое:

  • Сначала запустите обычные тесты с помощью санитизаторов, чтобы узнать, есть ли проблемы, то после того, как код санитизатор-очистка запуска нечетко.
  • Для C или C++существуют компиляторы, которые автоматизируют внедрение утверждений среды выполнения и метаданных, которые позволяют ASan. При компиляции для ASan результирующий двоичный файл связывается с библиотекой среды выполнения, которая может точно диагностировать 15+ категорий ошибок безопасности памяти с нуля ложных срабатываний. Для C или C++ при наличии источника используйте LibFuzzer, для которого сначала необходимо включить ASan.
  • Для библиотек, написанных на Java, C#, Python, Rust и т. д., используйте платформу AFL++.

Ключевые качества

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

Azure и GitHub CI/CD

Измените сборки для поддержки непрерывного создания исполняемых файлов, использующих LibFuzzer или AFL++. Вы можете добавить дополнительные вычислительные ресурсы, необходимые для нечетких служб, таких как OSS-Fuzz или OneFuzz.

2.10 Сканирование веб-приложений

Сводка

В области Microsoft Visual C++ в Windows рекомендуется:

  • Предпочитайте TypeScript, JavaScript и ASP.NET для веб-приложений.
  • Не записывайте веб-расширения в C++. Корпорация Майкрософт не рекомендует ActiveX.
  • Когда код компилируется в Emscripten/WASM, он больше не применяется к C++ и другим средствам.
  • Корпорация Майкрософт предоставляет RESTler, нечеткий REST API с отслеживанием состояния.

Обзор и ключевые качества

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

  • Каталоги всех веб-приложений в сети, включая новые и неизвестные, и масштабируется от нескольких приложений до тысяч.
  • Глубокое сканирование версий программного обеспечения, служб SOAP и REST API, используемых мобильными устройствами.
  • Вставка примитивов безопасности в разработку и развертывание приложений в средах DevOps. Эти примитивы работают с обходчиком.
  • Обнаружение вредоносных программ.

2.11 Проверка включенных компонентов программного обеспечения

Сводка

Обработайте код C++ так же, как код, написанный на других языках программирования, и примените любые средства анализа композиции программного обеспечения (SCA) и анализа происхождения (OA), принятые вашей компанией в код C++. Рабочие процессы и сканирование безопасности должны быть разработаны как часть систем CI/CD (непрерывная интеграция и непрерывная доставка).

Вышестоящей обороны

Чтобы снизить риск атак на вышестоящие зависимости, сторонние источники и компоненты должны храниться на управляемом предприятием ресурсе, против которого выполняются средства SCA и OA.

  • Средства должны проверять и оповещать при обнаружении уязвимостей (включая общедоступные базы данных), таких как: Главная | CVE
  • Запустите статический анализ всех компонентов программного обеспечения, включенных в приложение или репозиторий, чтобы определить уязвимые шаблоны кода.

Защита зависимостей

Выполните и сохраните аудит зависимостей, чтобы убедиться, что все такие вхождения учитываются и охватываются средствами SCA и OA.

  • Компоненты должны регулярно проверяться и обновляться до последних проверенных версий.
  • Зависимости веб-канала пакетов.
  • Средства SCA/OA охватывают и проверяют все зависимости пакетов, поступающие из одного веб-канала.

SBOM

Создайте SBOM (счет за программное обеспечение материалов) с описанием всех зависимостей продукта, таких как:

  • источник (например, URL-адрес (универсальный указатель ресурсов))
  • версия
  • согласованность (например, хэш источника SHA-256) и других средств проверки согласованности, таких как детерминированные сборки.
  • Требовать и проверять файлы SBOM в зависимостях программного обеспечения или создаваться в рамках сборки, включая OSS (программное обеспечение с открытым исходным кодом).
  • Корпорация Майкрософт стандартизирована и рекомендует SPDX (Обмен данными пакета программного обеспечения) версии 2.2 или более поздней | Linux Foundation в качестве формата документа SBOM.
  • Детерминированность сборки можно использовать для независимой создания битовых идентичных двоичных файлов и предоставления независимых проверок целостности:
    • Первая или сторонняя аттестация воспроизводимости
    • Другие методы, такие как двоичная подпись через надежный источник сертификата, также могут обеспечить некоторые гарантии целостности двоичных файлов.

Дополнительные ресурсы

Решения Майкрософт включают следующие рекомендации и продукты: