Как граф зависимостей распознаёт зависимости

Граф зависимостей может определить зависимости вашего проекта с помощью следующих методов.

Метод	Принцип работы
Статический анализ	Парсирование манифеста и блокировки файлов в вашем репозитории
**

          Dependabot Графовые задания** | Использует DependabotGitHub Actions рабочий процесс для генерации снимков зависимостей |

| | | | | Автоматическая сдача | Запускает встроенный GitHub Actions рабочий процесс для решения зависимостей во время сборки | | | API отправки зависимостей | Принимает данные зависимостей, которые вы предоставляете программно |

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

Статический анализ

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

Статический анализ может выявить:

• Прямые зависимости , явно определённые в манифесте или файле блокировки
• Косвенные зависимости — зависимости этих прямых зависимостей, также называемые «транзитивными зависимостями» — но только если они определены в манифесте или файле блокировки, а не если разрешены во время сборки

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

Автоматическая отправка зависимостей

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

В фоновом режиме автоматическая отправка зависимостей запускает GitHub Actions рабочий процесс, который генерирует полное дерево и загружает его с помощью API отправки зависимостей. Автоматическая подача зависимостей по умолчанию работает на GitHub-hosted runners и засчитывается в ваши GitHub Actions минуты. По желанию, вы можете выбрать запуск на самостоятельных бегунах или более крупные бегуны.

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

          Dependabot Графовые задания

          Dependabot Графовые задания используют специальный тип Dependabot заданий для создания снимка зависимостей и загрузки его в API подачи зависимостей. 
          Dependabot В настоящее время графовые задачи поддерживаются для зависимостей **Go** и **Python** .

Для поддерживаемых экосистем Dependabot графовые задания предоставляют:

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

Этот подход похож на автоматическое подчинение зависимости, но не требует оплаты за GitHub Actions несколько минут. Он также может получить доступ к конфигурациям для частных реестров, которые вы настроили для Dependabot.

          API отправки зависимостей
        

Вы можете вызвать их API отправки зависимостей в своём скрипте или рабочем процессе. Это полезно, если:

• Вам нужно указывать транзитивные зависимости, которые нельзя обнаружить из файлов блокировки.
• Вам нужно создать собственную логику или вы используете внешнюю систему CI/CD.

Зависимости передаются API отправки зависимостей в виде снимка. Это список зависимостей, связанных с SHA коммита и другими метаданными, отражающий текущее состояние вашего репозитория.

Если вы вызываете API в рабочем GitHub Actions процессе, вы можете использовать готовое действие для вашей экосистемы, которое автоматически собирает зависимости и отправляет их в API. В противном случае вы можете написать собственное действие или вызвать API из внешней системы.

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

Дополнительные сведения см. в разделе Использование API отправки зависимостей.

Приоритетность

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

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

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

   • Если есть несколько моментальных снимков вручную из разных детекторов, они сортируются по алфавиту по коррелятору и первому используемому.
   • Если есть два коррелятора с одинаковым детектором, разрешенные зависимости объединяются. Для получения дополнительной информации о корреляторах и детекторах см. Конечные точки REST API для отправки зависимостей.

2.        **
          Dependabot Графовые задания** имеют второй по значимости приоритет. Для экосистем, где Dependabot доступны графовые задания (сейчас Go и Python), они имеют приоритет над автоматической подачей зависимости.
   

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

4.        **Результаты** статического анализа используются, если другие данные недоступны.