Я с вами согласен — для вашей ситуации сейчас это не приоритет. Но раз спросили мнение, разложу честно, потому что у CodeRabbit за этим «Critical» стоит реальная история.
В чём действительно риск. Теги в GitHub Actions изменяемы: actions/checkout@v6 — это указатель, который владелец репозитория может передвинуть на любой коммит. Атака не теоретическая: в марте 2025 был громкий инцидент с tj-actions/changed-files — скомпрометировали аккаунт мейнтейнера, передвинули все версионные теги на вредоносный коммит, и тысячи CI-пайплайнов начали сливать секреты в логи. SHA эту атаку закрывает полностью: хеш коммита подделать нельзя.
Почему для вас это пока не страшно. Три фактора снижают ваш риск почти до нуля:
- Ваши workflow почти целиком стоят на официальных действиях GitHub (
actions/checkout,setup-java,github-script) — их компрометация это событие масштаба «горит весь интернет», SHA-пиннинг вас в таком сценарии спасёт в последнюю очередь. Третьесторонних у вас немного:sbt/setup-sbt,jdx/mise-action,mikepenz/action-junit-report. - Dependabot уже даёт вам половину защиты: версии бампаются через PR, которые вы видите и вливаете руками — слепого автообновления нет.
- Радиус поражения — ваша собственная инфраструктура соло-проекта, а не цепочка поставок для тысяч потребителей.
Про удобство вы тоже правы, и это не только эстетика: actions/checkout@v6 читается, а actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 — нет. Хотя справедливости ради: при правильной настройке dependabot умеет работать и с SHA, оставляя комментарий # v6.1.2 рядом, так что обновления не превращаются в ручной труд.
Когда я бы передумал. Есть один сценарий, где это станет важным именно для вас: ваши release-workflow держат packages: write и публикуют артефакты движка, которые потребляют другие проекты. Если у @rabestro/dicechess-engine или Maven-артефакта появятся внешние потребители — скомпрометированный третьесторонний action в release.yaml сможет опубликовать отравленный пакет уже в их цепочку поставок. Вот тогда пиннинг (хотя бы третьесторонних действий в release-пайплайнах, не везде) станет оправданным, и делать его надо будет инструментом (pin-github-action или Renovate), один раз и по всем репозиториям.
Резюме: сейчас — оставляем теги, решение зафиксировано в disposition-комментарии PR. Триггер на пересмотр — внешние потребители пакетов. Это, кстати, хороший пример того, почему «Critical» от ревью-ботов стоит калибровать на контекст проекта: правило универсальное, а риск — нет.