Bamboo

Только Data Center — Atlassian Cloud не отдаёт эндпоинт, который читает эта проба. Читает GET /rest/applinks/1.0/manifest — тот же manifest Application Links, что отдаёт любой продукт Atlassian Data Center — анонимный эндпоинт, поэтому используется он, а не /rest/api/2/serverInfo.

targets:
  - id: bamboo-main
    product: bamboo
    address: https://bamboo.example.com

Аутентификация

Опционально — manifest читается без credentials. none, basic и bearer тоже принимаются, если вы всё же хотите аутентифицироваться.

Проверка личности вендора

<typeId> из manifest сверяется с тем, что ожидает product: bamboo (bamboo). Если по адресу на самом деле оказалась Jira или Confluence, проба громко откажет вместо того, чтобы записать это как неверный факт — см. Jira, Confluence, Bitbucket — соседние продукты с той же конвенцией manifest.

Записываемые поля

• version
• extra.buildNumber, extra.typeId — typeId будет равен bamboo

Сопоставление с CVE

Сверяется с NVD и БДУ ФСТЭК, если настроен блок cve:. Начиная с 2.2, cve.atlassian.path добавляет собственные данные Atlassian по каждому релизу — включая CVE сторонних зависимостей, которых записи NVD по Atlassian не перечисляют, — и для релиза, который в них есть, их вердикт решает в пределах собственной ветки релиза. См. Собственные данные вендоров → Atlassian.

Резолвер жизненного цикла

Пока не подключён — и, в отличие от других продуктов из этого списка без резолвера, это не потому, что у endoflife.date нет подходящего календаря: endoflife.date/bamboo существует и содержит реальные данные по циклам, подтверждено через endoflife.date/api/bamboo.json. В registry.go для этого продукта просто указано resolver: "", без комментария «confirmed 404», который есть у соседних проб Atlassian — похоже на пробел в самой enodia, а не на намеренное «календаря не существует». enodia всё равно отслеживает version и buildNumber независимо от этого; неопределённой остаётся только ось lifecycle, пока это не подключат в апстриме.