Настройка и индивидуальная модификация задач сборки

Примечание

С 31 декабря 2022 г. расширение Microsoft Security Code Analysis (MSCA) прекращается. MSCA заменяется расширением Microsoft Security DevOps Azure DevOps. Следуйте инструкциям в разделе Настройка , чтобы установить и настроить расширение.

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

Задача сканера защиты от вредоносных программ

Примечание

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

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

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

В поле списка Type (Тип) на снимке экрана выбран тип Basic (Базовый). Выберите тип Пользовательский, чтобы указать аргументы командной строки для настройки проверки.

Защитник Windows использует клиент Центра обновления Windows для загрузки и установки сигнатур. Если обновление сигнатуры для агента сборки завершается сбоем, код ошибки HRESULT, скорее всего, поступает из Центра обновления Windows.

Дополнительные сведения об ошибках Центра обновления Windows и их устранении см. в разделе Коды ошибок Центра обновления Windows по компонентам и в статье TechNet Агент Центра обновления Windows — коды ошибок.

Сведения о настройке YAML для этой задачи см. в статье Параметры YAML для защиты от вредоносных программ

Задача BinSkim

Примечание

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

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

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

• Установите для конфигурации сборки параметр "Отладка", чтобы создавались отладочные PDB-файлы. BinSkim использует эти файлы для обратного сопоставления проблем, обнаруженных в выходных двоичных файлах, со строками исходного кода.
• Если вы не хотите исследовать документацию и создавать собственную командную строку, выполните следующее.
  • В раскрывающемся списке Type (Тип) выберите Basic (Базовый).
  • В списке Function (Функция) выберите Analyze (Анализировать).
• В поле Target (Целевой объект) введите один или несколько описателей для файла, каталога или шаблона фильтра. Эти описатели разрешаются на один или несколько анализируемых двоичных файлов.
  • При указании нескольких целевых объектов их следует разделять точкой с запятой (;).
  • Описатель может быть одиночным файлом, или же он может содержать подстановочные знаки.
  • Описатели для каталогов всегда должны оканчиваться на \*.
  • Примеры:

           *.dll;*.exe
           $(BUILD_STAGINGDIRECTORY)\*
           $(BUILD_STAGINGDIRECTORY)\*.dll;$(BUILD_STAGINGDIRECTORY)\*.exe;

• Если выбрать Command Line (Командная строка) в списке Type (Тип), необходимо запустить binskim.exe:
  • Убедитесь, что первые аргументы для binskim.exe — это команда analyze, за которой следует одна или несколько спецификаций путей. Каждый путь может быть либо полным путем, либо путем, заданным относительно исходного каталога.
  • При указании нескольких целевых путей их следует разделять пробелами.
  • Параметр /o или /output можно опустить. Выходное значение добавляется или заменяется автоматически.
  • Стандартные конфигурации командной строки приведены ниже.

           analyze $(Build.StagingDirectory)\* --recurse --verbose
           analyze *.dll *.exe --recurse --verbose

Примечание

В случае указания каталогов в качестве целевых объектов важно не забыть добавить в конце символ \*.

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

Сведения о настройке YAML для этой задачи см. в статье Параметры YAML для BinSkim

Задача сканера учетных данных

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

Доступны следующие варианты:

• Display Name (Отображаемое имя): имя задачи Azure DevOps. Значение по умолчанию — Run Credential Scanner (Запустить сканер учетных данных).
• Tool Major Version (Основной номер версии средства): доступны значения CredScan V2, CredScan V1. Мы рекомендуем клиентам использовать версию CredScan V2.
• Output Format (Выходной формат): возможные значения включают TSV, CSV, SARIF и PREfast.
• Tool Version (Версия инструмента): рекомендуется выбрать вариант Latest (Новейшая).
• Scan Folder (Сканируемая папка): папка репозитория, которую необходимо просканировать.
• Searchers File Type (Тип файла модуля поиска): параметры расположения файла модуля поиска, который применяется при сканировании.
• Suppressions File (Файл подавлений): JSON-файл, который может подавлять вывод сообщений о проблемах в выходном журнале. Дополнительные сведения о сценариях подавления см. в разделе "Вопросы и ответы" в этой статье.
• Verbose Output (Подробные выходные данные): повышает детализацию выводимых сообщений.
• Batch Size (Размер пакета): количество параллельных потоков, используемых при выполнении сканера учетных данных. Значение по умолчанию — 20. Допустимые значения — от 1 до 2 147 483 647.
• Match Timeout (Время ожидания соответствия): время в секундах, затрачиваемое на попытку получения совпадения в модуле поиска, прежде чем проверка прерывается.
• File Scan Read Buffer Size (Размер буфера чтения файла для сканирования): размер в байтах буфера, используемого при считывании содержимого. Значение по умолчанию — 524 288.
• Maximum File Scan Read Bytes (Максимальное количество считываемых при сканировании байтов): максимальное количество байтов, считываемых из файла во время анализа содержимого. Значение по умолчанию — 104 857 600.
• Control Options> (Параметры управления) Run this task (Запускать эту задачу): указывает, когда будет запускаться задача. Выберите Custom conditions (Пользовательские условия), чтобы задать более сложные условия.
• Version (Версия): версия задачи сборки в Azure DevOps. Этот параметр используется редко.

Сведения о настройке YAML для этой задачи см. в статье Параметры YAML для сканера учетных данных

Задача анализаторов Roslyn

Примечание

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

• Определение сборки включает встроенную задачу сборки MSBuild или VSBuild для компиляции кода C# или Visual Basic. Задача анализаторов полагается на входные и выходные данные встроенной задачи для выполнения компиляции MSBuild с включенными анализаторами Roslyn.
• В агенте сборки, выполняющем эту задачу сборки, установлена Visual Studio 2017 версии 15.5 или выше, так что в нем применяется компилятор версии 2.6 или более новой.

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

Доступны следующие варианты:

• Ruleset (Набор правил): возможны значения SDL Required (Обязательные SDL), SDL Recommended (Рекомендуемые SDL), или же можно указать собственный пользовательский набор правил.
• Analyzers Version (Версия анализаторов): рекомендуется выбрать вариант Latest (Новейшая).
• Compiler Warnings Suppressions File (Файл подавления предупреждений компилятора): текстовый файл со списком идентификаторов предупреждений, вывод которых будет подавляться.
• Control Options> (Параметры управления) Run this task (Запускать эту задачу): указывает, когда будет запускаться задача. Выберите вариант Custom conditions (Пользовательские условия), чтобы задать более сложные условия.

Примечание

• Анализаторы Roslyn интегрированы в компилятор и могут выполняться только в рамках компиляции с помощью исполняемого файла csc.exe. Поэтому для данной задачи требуется воспроизвести или запустить заново команду запуска компилятора, выполненную ранее в ходе сборки. Такое воспроизведение или запуск производятся посредством запроса к Azure DevOps (ранее называвшемуся Visual Studio Team Services) для получения журналов задачи сборки MSBuild.

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

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

• Анализаторы Roslyn интегрированы в компилятор. Чтобы произошел вызов анализаторов Roslyn, должна произойти компиляция.

  Эта новая задача сборки реализуется посредством повторной компиляции уже построенных проектов C#. Новая задача использует лишь задачи сборки MSBuild или VSBuild в той же сборке или том же определении сборки, что и исходная задача. Однако в данном случае новая задача выполняет их при включенных анализаторах Roslyn.

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

Дополнительные ресурсы по задаче анализаторов Roslyn см. в статье об анализаторах на основе Roslyn.

Пакет анализатора, который установлен и используется этой задачей сборки, можно найти на странице NuGet Microsoft.CodeAnalysis.FxCopAnalyzers.

Сведения о настройке YAML для этой задачи см. в статье Параметры YAML для анализаторов Roslyn

Задача TSLint

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

Примечание

Как вы, вероятно, знаете, на домашней странице репозитория TSLint на GitHub указано, что с 2019 года TSLint считается устаревшим. Корпорация Майкрософт рассматривает возможность использования ESLint в качестве альтернативной задачи.

Сведения о настройке YAML для этой задачи см. в статье Параметры YAML для TSLint

Задача публикации журналов анализа безопасности

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

• Artifact Name (Имя артефакта): любой строковый идентификатор.
• Artifact Type (Тип артефакта): в зависимости от выбранного варианта можно публиковать журналы на Azure DevOps Server или в общем файле, доступном агенту сборки.
• Tools (Средства): можно выбрать сохранение журналов отдельных средств или же выбрать вариант All Tools (Все средства), чтобы сохранять все журналы.

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

Задача "Отчет о безопасности"

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

• Reports (Отчеты): выберите любые из форматов (Pipeline Console (Консоль конвейера), TSV File (Файл TSV) или HTML File (Файл HTML)). Для каждого выбранного формата создается по одному файлу отчета.
• Tools (Средства): выберите средства в вашем определении сборки, для которых нужно получить сводку по обнаруженным проблемам. Для каждого выбранного средства можно выбрать отображение в сводном отчете только ошибок или же как ошибок, так и предупреждений.
• Advanced Options (Дополнительные параметры): если для одного из выбранных средств журналы отсутствуют, можно выбрать запись в журнал предупреждения либо ошибки. В случае регистрации в журнале ошибки задача завершается со сбоем.
• Base Logs Folder (Базовая папка журналов): позволяет настроить базовую папку журналов, в которой будут располагаться журналы. Этот параметр обычно не используется.

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

Задача пост-анализа

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

• Tools (Средства): выберите в определении сборки средства, для которых необходимо вставлять прерывание построения по условию. Для каждого выбранного средства можно выбрать прерывание только по ошибкам или же как по ошибкам, так и по предупреждениям.
• Report (Отчет): можно выбрать запись тех результатов, которые приводят к прерыванию построения. Результаты записываются в окно консоли Azure DevOps и в файл журнала.
• Advanced Options (Дополнительные параметры): если для одного из выбранных средств журналы отсутствуют, можно выбрать запись в журнал предупреждения либо ошибки. В случае регистрации в журнале ошибки задача завершается со сбоем.

Сведения о настройке YAML для этой задачи см. в статье Параметры YAML для пост-анализа

Дальнейшие действия

Сведения о конфигурации на основе YAML см. в Руководстве по конфигурации YAML.

Если у вас возникнут дополнительные вопросы о расширении Security Code Analysis и о предлагаемых средствах, ознакомьтесь со страницей "Вопросы и ответы".