Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Замечание
С 31 декабря 2022 г. расширение Microsoft Security Code Analysis (MSCA) отключено. MSCA заменяется расширением Microsoft Security DevOps Azure DevOps. Следуйте инструкциям в Настройка для установки и настройки расширения.
В этой статье подробно описаны параметры конфигурации, доступные в каждой из задач сборки. Статья начинается с задач для средств анализа кода безопасности. Он завершается этапом постобработки.
Задача сканера вредоносных программ
Замечание
Для задачи сборки сканера защиты от вредоносных программ требуется агент сборки с включенным Защитником Windows. Размещенная среда Visual Studio 2017 и более поздних версий предоставляет такой агент. Задача сборки не будет выполняться в размещенном агенте Visual Studio 2015.
Хотя подписи не могут быть обновлены для этих агентов, подписи всегда должны быть меньше трех часов.
Сведения о конфигурации задачи показаны на следующем снимке экрана и тексте.
В списке "Тип " на снимке экрана выбран элемент "Базовый ". Выберите "Настраиваемый", чтобы предоставить аргументы командной строки, которые настраивают проверку.
Защитник Windows использует клиент Центра обновления Windows для скачивания и установки подписей. Если обновление подписи не удается на агенте сборки, код ошибки HRESULT, скорее всего, является результатом Windows Update.
Дополнительные сведения об ошибках Центра обновления Windows и их устранении см. в разделах коды ошибок центра обновления Windows по компонентам и в статье агента центра обновления Windows — коды ошибок.
Сведения о конфигурации YAML для этой задачи см. в наших параметрах YAML защиты от вредоносных программ
Задача BinSkim
Замечание
Прежде чем запустить задачу BinSkim, сборка должна соответствовать одному из следующих условий:
- Сборка создает двоичные артефакты из управляемого кода.
- У вас есть двоичные артефакты, зафиксированные для анализа с помощью BinSkim.
Сведения о конфигурации задачи отображаются на следующем снимке экрана и списке.
- Установите конфигурацию сборки на Debug, чтобы были созданы файлы отладки .pdb. BinSkim использует эти файлы для сопоставления проблем в выходных двоичных файлах обратно с исходным кодом.
- Чтобы избежать исследования и создания собственной командной строки:
- В списке "Тип " выберите "Базовый".
- В списке функций выберите "Анализ".
- В target введите один или несколько описателей для шаблона файла, каталога или фильтра. Эти спецификаторы преобразуются в один или несколько двоичных файлов для анализа.
- Несколько указанных целевых объектов должны быть разделены точкой с запятой (;).
- Описатель может быть одним файлом или содержать подстановочные знаки.
- Спецификации каталогов должны всегда заканчиваться \*.
- Примеры.
*.dll;*.exe
$(BUILD_STAGINGDIRECTORY)\*
$(BUILD_STAGINGDIRECTORY)\*.dll;$(BUILD_STAGINGDIRECTORY)\*.exe;
- Если в списке Тип выбрана Командная строка, необходимо выполнить binskim.exe:
- Убедитесь, что первыми аргументами для binskim.exe являются глагол анализировать, за которым следует одна или несколько спецификаций пути. Каждый путь может иметь полный путь или путь относительно исходного каталога.
- Несколько целевых путей должны быть разделены пробелом.
- Можно опустить параметр /o или /output . Выходное значение добавляется для вас или заменено.
- Стандартные конфигурации командной строки показаны следующим образом.
analyze $(Build.StagingDirectory)\* --recurse --verbose
analyze *.dll *.exe --recurse --verbose
Замечание
Конечный \* важен, если указать каталоги для целевого объекта.
Дополнительные сведения о аргументах командной строки BinSkim, правилах по идентификаторам или кодам выхода см. в руководстве пользователя BinSkim.
Сведения о конфигурации YAML для этой задачи см. в параметрах BinSkim YAML
Задача сканирования учетных данных
Сведения о конфигурации задачи отображаются на следующем снимке экрана и списке.
Доступные варианты:
- Отображаемое имя: имя задачи Azure DevOps. Значением по умолчанию является Run Credential Scanner.
- Основная версия средства: доступные значения включают CredScan версии 2, CredScan V1. Мы рекомендуем клиентам использовать версию CredScan версии 2 .
- Формат вывода: доступные значения: TSV, CSV, SARIF и PREfast.
- Версия инструмента. Рекомендуется выбрать "Последняя".
- Папка сканирования: папка репозитория для сканирования.
- Тип файла searchers: параметры поиска файла поиска, который используется для сканирования.
- Файл подавления: JSON-файл может подавлять проблемы в выходном журнале. Дополнительные сведения о сценариях подавления см. в разделе часто задаваемых вопросов этой статьи.
- Подробные выходные данные: понятны без объяснения.
- Размер пакета: количество параллельных потоков, используемых для запуска средства проверки учетных данных. Значение по умолчанию — 20. Возможные значения варьируются от 1 до 2 147 483 647.
- Время ожидания совпадения: количество времени в секундах для попытки поиска совпадения перед прекращением проверки.
- Размер буфера чтения файла: размер в байтах, используемый во время чтения содержимого. Значение по умолчанию — 524 288.
- Максимальное число байтов сканирования файлов: максимальное количество байтов для чтения из файла во время анализа содержимого. Значение по умолчанию — 104 857 600.
- Параметры> элемента управленияЗапустите эту задачу: указывает, когда будет выполняться задача. Выберите настраиваемые условия , чтобы указать более сложные условия.
- Версия: версия задачи сборки в Azure DevOps. Этот параметр часто не используется.
Сведения о конфигурации YAML для этой задачи см. в параметрах YAML сканера учетных данных
Задача Анализаторов Roslyn
Замечание
Прежде чем запустить задачу Roslyn Analyzers, сборка должна соответствовать следующим условиям:
- Определение сборки включает встроенную задачу сборки MSBuild или VSBuild для компиляции кода C# или Visual Basic. Задача анализаторов зависит от входных и выходных данных встроенной задачи для запуска компиляции MSBuild с включенными анализаторами Roslyn.
- Агент сборки, на котором выполняется эта задача сборки, установлен Visual Studio 2017 версии 15.5 или более поздней, чтобы он использовал компилятор версии 2.6 или более поздней.
Сведения о конфигурации задачи отображаются в следующем списке и заметке.
Доступные варианты:
- Набор правил. Значения : это обязательный SDL, рекомендуемый SDL или собственный настраиваемый набор правил.
- Версия анализаторов: рекомендуется выбрать последнюю версию.
- Файл подавления компилятора: текстовый файл со списком идентификаторов предупреждений, которые подавляются.
- Параметры> элемента управленияЗапустите эту задачу: указывает, когда будет выполняться задача. Выберите настраиваемые условия , чтобы указать более сложные условия.
Замечание
Анализаторы Roslyn интегрированы с компилятором и могут выполняться только в рамках компиляции csc.exe. Поэтому для этой задачи требуется команда компилятора, которая выполнялась ранее в сборке, для воспроизведения или повторного выполнения. Это воспроизведение или выполнение операции осуществляется с помощью запроса к Azure DevOps (ранее — Visual Studio Team Services) для получения журналов задач сборки MSBuild.
Нет другого способа надежного получения командной строки компиляции MSBuild из определения сборки. Мы рассмотрели добавление текстового поля свободной формы, чтобы пользователи могли вводить свои командные строки. Но тогда было бы трудно эти командные строки up-to-date согласовать и синхронизировать с основной сборкой.
Для пользовательских сборок требуется повторное выполнение всего набора команд, а не только команд компилятора. В таких случаях включение анализаторов Roslyn не является тривиальным или надежным.
Анализаторы Roslyn интегрируются с компилятором. Для вызова анализаторов Roslyn требуется компиляция.
Эта новая задача сборки реализована путем перекомпилирования проектов C#, которые уже созданы. Новая задача использует только задачи сборки MSBuild и VSBuild в том же определении или процессе сборки, что и исходная задача. Однако в этом случае новая задача использует их с включенными анализаторами Roslyn.
Если новая задача выполняется в том же агенте, что и исходная задача, выходные данные новой задачи перезаписывают выходные данные исходной задачи в папке источников . Хотя выходные данные сборки совпадают, рекомендуется запускать MSBuild, копировать выходные данные в промежуточный каталог артефактов, а затем запускать анализаторы Roslyn.
Дополнительные ресурсы для задачи Roslyn Analyzers см. в анализаторах на основе Roslyn.
Пакет анализатора установлен и используется этой задачей сборки на странице NuGet Microsoft.CodeAnalysis.FxCopAnalyzers.
Сведения о конфигурации YAML для этой задачи см. в параметрах YAML для анализаторов Roslyn.
Задача TSLint
Дополнительные сведения о TSLint см. в репозитории TSLint GitHub.
Замечание
Как вы, возможно, знаете, на домашней странице репозитория TSLint на GitHub говорится, что TSLint будет устаревать в какой-то момент в 2019 году. Корпорация Майкрософт изучает ESLint как альтернативную задачу.
Для получения информации о конфигурации YAML для этой задачи ознакомьтесь с нашими параметрами YAML TSLint
Задача "Публикация журналов анализа безопасности"
Сведения о конфигурации задачи отображаются на следующем снимке экрана и списке.
- Имя артефакта: любой строковый идентификатор.
- Тип артефакта: в зависимости от выбранного варианта можно публиковать журналы на сервере Azure DevOps или в общий файл, доступный агенту сборки.
- Средства. Вы можете сохранить журналы для определенных инструментов или выбрать все средства , чтобы сохранить все журналы.
Сведения о конфигурации YAML для этой задачи см. в параметрах YAML для публикации журналов безопасности
Задача "Отчет о безопасности"
Сведения о конфигурации отчета безопасности показаны на следующем снимке экрана и списке.
- Отчеты: выберите любой формат из консоли Pipeline, TSV-файла и HTML-файла. Для каждого выбранного формата создается один файл отчета.
- Средства. Выберите средства в определении сборки, для которых требуется сводка обнаруженных проблем. Для каждого выбранного инструмента может быть опция выбора, отображать только ошибки или как ошибки, так и предупреждения в итоговом отчете.
- Дополнительные параметры. Если для одного из выбранных средств нет журналов, можно записать предупреждение или ошибку. Если вы регистрируете ошибку, задача проваливается.
- Папка базовых журналов: можно настроить папку базовых журналов, в которой находятся журналы. Но этот параметр обычно не используется.
Дополнительные сведения о конфигурации YAML для этой задачи см. в разделе "Параметры отчета безопасности YAML"
Задача после анализа
Сведения о конфигурации задачи отображаются на следующем снимке экрана и списке.
- Средства. Выберите средства в определении сборки, для которых требуется условно внедрить разрыв сборки. Для каждого выбранного средства можно выбрать, следует ли прерывать ошибки только или в обоих ошибках и предупреждениях.
- Отчет. При необходимости можно записать результаты, которые вызывают разрыв сборки. Результаты записываются в окно консоли Azure DevOps и файл журнала.
- Дополнительные параметры. Если для одного из выбранных средств нет журналов, можно записать предупреждение или ошибку. Если вы регистрируете ошибку, задача проваливается.
Сведения о конфигурации YAML для этой задачи см. в параметрах YAML для post Analysis
Дальнейшие действия
Сведения о конфигурации на основе YAML см. в руководстве по настройке YAML.
Если у вас есть дополнительные вопросы о расширении анализа кода безопасности и предлагаемых средствах, ознакомьтесь со страницей часто задаваемых вопросов.