Rate this post

В современном мире разработки игнорировать безопасность зависимостей — значит сознательно идти навстречу инцидентам. Каждый новый пакет NuGet, который вы добавляете в проект, потенциально может содержать уязвимости.
Поэтому автоматизация проверки зависимостей — это не просто «хорошая практика», а необходимый минимум безопасности, без которого нельзя выпускать надёжный продукт.

В этой статье показано, как добавить обязательный этап проверки безопасности (security-scan) в файл .gitlab-ci.yml любого .NET-проекта, используя стандартные инструменты из комплекта .NET SDK.

Добавляем этап Security Scan в .gitlab-ci.yml

Ниже приведён YAML-фрагмент, который можно напрямую включить в ваш CI/CD-конвейер:

security-scan:
stage: security-scan
image: mcr.microsoft.com/dotnet/sdk:8.0
before_script:
- dotnet tool install --global dotnet-outdated-tool
script:
# Step 1: Check for known vulnerabilities in packages. This is mandatory.
- echo "Searching for KNOWN vulnerabilities in packages..."
- dotnet list package --vulnerable --include-transitive

# Step 2: Check for outdated packages. Important for maintenance and security.
- echo "Checking for outdated (non-secure) packages..."
- dotnet-outdated
allow_failure: true
only:
- main
- develop
- merge_requests

Подробный разбор: первая линия защиты вашего проекта

stage: security-scan

Проверка безопасности вынесена в отдельный этап, чтобы подчеркнуть её значимость.
Такой подход гарантирует, что сканирование выполняется регулярно — обычно после сборки и тестов.

image: mcr.microsoft.com/dotnet/sdk:8.0

Использование официального Docker-образа .NET SDK от Microsoft обеспечивает доступ к актуальным CLI-инструментам, необходимым для надёжного анализа и отчётности.

before_script

Этот блок подготавливает окружение для сканирования.

Команда

dotnet tool install --global dotnet-outdated-tool

устанавливает утилиту dotnet-outdated-tool.
Хотя основная проверка уязвимостей выполняется встроенным инструментом, этот пакет помогает отслеживать устаревшие зависимости — важная часть поддержания «гигиены» проекта.
Игнорирование обновлений со временем превращается в технический долг и повышает риски безопасности.

script

Здесь выполняются команды, которые фактически защищают ваш код.

  • Шаг 1: Поиск известных уязвимостей
    Команда dotnet list package --vulnerable анализирует все зависимости (включая транзитивные) и выводит список небезопасных пакетов.

  • Шаг 2: Проверка устаревших пакетов
    Команда dotnet-outdated показывает зависимости, которые больше не актуальны или потенциально уязвимы.

allow_failure: true

Этот параметр позволяет конвейеру продолжить работу, даже если найдены проблемы.
Это удобный компромисс на этапе внедрения — разработчики получают отчёт, но процесс сборки не блокируется.
Однако, если проект связан с конфиденциальными данными или продакшн-системами, рекомендуется установить значение false, чтобы запретить слияние кода с уязвимостями.

only

Этот блок задаёт, для каких веток выполняется проверка — main, develop и merge requests.
Так вы можете выявить риски ещё до попадания потенциально опасного кода в основную ветку.

Заключение

Представленная конфигурация — это не «опция» и не «дополнение», а базовый стандарт безопасности для любого .NET-проекта.
Она автоматически выполняет две ключевые задачи:

  1. Находит активные угрозы — пакеты с известными уязвимостями.

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

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